AI for Engineering Teams / Shadow AI in Engineering Teams: Risks, Costs, and How to Regain Control

Engineering leaders have a lot on their plates, but there's one thing that typically falls through the cracks: shadow AI. That’s when your developers use tools nobody signed off on, such as personal ChatGPT accounts, unauthorized Copilot subscriptions, or third-party LLM API calls hardcoded straight into production code. All of this happens outside your visibility or approval. Most VP-level engineering leaders already sense it's happening on their teams. What they don't know is how much.

In this article, we'll walk through the three core risks every engineering leader should know about and three key steps to mitigate them.

Shadow AI shows up as unauthorized API keys embedded in microservices, personal Copilot subscriptions running on company laptops, and autonomous agents making calls to external models your security team has never reviewed. Usually, it's a feature of organizational drift, spreading gradually across many people and teams, rather than one rogue developer doing something they shouldn't.

The pattern tends to accelerate as AI moves from an assistant to an autonomous system. It often starts small, for example, a developer pasting code snippets into a chat interface to get a quick answer. Over time, that same developer writes a wrapper that calls GPT-4 directly from a continuous integration (CI) pipeline. Then they share the wrapper with a teammate. Three months later, a dozen teams are running workloads from an account that no one in finance or security even knows exists. That's shadow AI at enterprise scale.

It also shows up in subtler ways. Developers bring in third-party AI code review tools that process your codebase, AI-powered Slack plugins with access to engineering channels, or browser extensions that quietly send clipboard content to external servers. Add it all up, and the footprint is usually larger than most leaders initially assume.

Shadow AI creates three distinct risk categories for engineering organizations. There's risk and legal exposure from unapproved data processing, cost unpredictability from ungoverned AI spend, and code quality and IP risk from unreviewed AI-generated code reaching production. Each requires a different response.

Compliance and legal exposure

When proprietary code, internal architecture documentation, or customer data gets processed by an external LLM, you have a data governance problem. Most free-tier and consumer-facing AI products have historically used user inputs to improve their models, though policies vary by provider and tier. Engineers working on regulated systems (fintech, healthcare, defense) who paste production data into an unapproved tool can trigger violations of GDPR, HIPAA, or SOC 2. Legal teams are still catching up on what exposure actually looks like, which means the risk falls to engineering leaders.

Cost unpredictability

Consider three engineering squads, each running autonomous agents with external APIs, and each paying through personal accounts or departmental credit cards. The finance team has no visibility into any of it. AI credits get consumed without attribution, without budgets, and without anyone tracking whether the spend is actually producing value. It's surprisingly easy for a quick experiment to cost thousands of dollars before anyone realizes it needs to be reported or escalated.

Code quality and IP risk

AI-generated code that bypasses your review process carries hidden risk. Security vulnerabilities in LLM-generated code are well-documented: The model doesn't know your security posture, your dependency requirements, or your internal APIs. Beyond quality, there are open questions about the IP ownership of code generated by models trained on open-source corpora. If a developer uses an unapproved tool to generate a core module, the IP status of that code is legitimately unclear.

The most effective approach to detecting shadow AI involves combining several signals rather than relying on one. Repository scanning, network egress analysis, developer surveys, and billing anomaly review each surface a different part of the problem. Put together, they tell you what's running, where it came from, and what need drove people to use it in the first place.

The diagram below shows how these signals come together:

Start with your codebase. Search for API key patterns matching major LLM providers, things like sk- prefixes for OpenAI keys, Anthropic's key formats, or Google AI Studio tokens. Tools like TruffleHog or Gitleaks can inspect your Git history and surface secrets that were committed and later removed. You'll likely find things that surprise you.

Review your egress traffic logs for connections to known AI provider endpoints, such as api.openai.com, api.anthropic.com, generativelanguage.googleapis.com, and api.cohere.ai. This helps you catch API usage that leaves no trace in code, like browser-based tools, direct API calls from developer machines, or third-party integrations. Your network team can typically run this analysis in a few hours over a rolling 30-day window.

Run anonymized developer surveys, framing them as an inventory exercise, not an investigation. Ask developers which AI tools they're using, which tasks they use them for, and what gaps they're trying to fill. Anonymous responses yield more honest data and signal that the conversation is open, helping reduce the adversarial dynamic that tends to push tools further underground.

Pull billing data across all corporate accounts and cards your team might use. Unexpected charges from OpenAI, Anthropic, or AWS Bedrock that aren't tied to an approved project are a signal worth chasing down. Cross-reference this with your finance team quarterly, if not monthly.

Detection tells you where you stand, but it doesn't fix what's driving the behavior in the first place.

Blanket restrictions usually make things worse. Engineers who can't access AI tools they find genuinely useful find workarounds, which end up being harder to detect than the original behavior. The effective path is structured enablement: Start with an honest inventory of what's in use, fast-track approval for the tools developers already rely on, create a tiered data policy, and build in visibility from day one so ungoverned spend can't accumulate again.

Build an honest inventory first

Before you write a single rule, document what's actually in use. Combine your detection findings with survey results to build a realistic picture of the AI tooling used across your teams. You might find that 80% of shadow AI usage clusters around a handful of tools, which makes the path to an approved list much cleaner.

Fast-track the tools developers already use

The fastest way to kill adoption of an AI policy is to hand engineers a list of tools they didn't ask for and tell them everything else is banned. Instead, take the most-used tools from your inventory, run them through a security and compliance review, and fast-track approval for the ones that pass. Involve a few respected engineers in the review process, because they'll advocate for the outcome.

Apply a tiered data policy

A tool that processes only public documentation carries a different risk profile from one that processes production code or customer data. A tiered policy is easier for engineers to apply than a binary approved/not-approved list.

Shadow AI isn't going away on its own, and treating it as an occasional cleanup task rather than an ongoing practice is how most organizations end up back at square one within a year. Detection, policy, and adoption all matter, but none of them stick without visibility that persists.

That's where Air Governance, part of JetBrains Air, comes in. It gives engineering leaders centralized governance of AI tool usage across teams, including analytics, access management, model and agent policy controls, and cost attribution. Once spend and usage are tied to real accounts and real teams, it becomes much harder for shadow AI to quietly pile up again.

Learn more about JetBrains Air or get started with Air Teams.