Shadow AI and Agent Sprawl
Shadow AI is any AI tool, assistant, or agent operating inside an organization without having gone through security review — an employee using a personal AI account for work, a team that bought an agent platform without telling anyone, a developer running a coding agent the organization does not provide. Agent sprawl is the related but distinct problem of sanctioned agents multiplying faster than anyone is tracking them. Shadow AI is about agents nobody approved. Sprawl is about approved agents nobody is counting.
What is shadow AI?
Shadow AI is the AI equivalent of shadow IT: technology adopted by employees or teams for productivity, preference, or convenience, outside the process that would normally assess it for risk. In practice it takes a handful of recognizable forms. An employee uses a personal AI subscription for work because the corporate one is slower or more restricted. A developer prefers a different coding agent to the one the organization licenses. A business unit buys an agent platform on a departmental card without a security review. A team wires an agent into a production workflow as a quick fix and never revisits it.
None of that is malicious, and treating it as though it were misreads the problem. Shadow AI is overwhelmingly a productivity story rather than a misconduct one, which is exactly why blocking is a weak response and discovery is a strong one. The organization is not dealing with people trying to evade governance; it is dealing with people solving their own problems faster than governance can keep up.
What makes it a security problem is not intent, it is invisibility. An unreviewed agent still has credentials, still connects to tools and data, and still takes actions — it simply does all of that without anyone having assessed whether it should.
What’s the difference between shadow AI and agent sprawl?
The two get used interchangeably and shouldn’t be, because they call for different responses.
Shadow AI is a sanctioning problem. There is an approval process, and these agents didn’t go through it. The fix is discovery followed by a decision: bring the agent into the sanctioned estate, or remove it.
Agent sprawl is a scale problem. These agents did go through approval, or were built by teams entitled to build them, and there are now simply more of them than the security team has a current picture of. Duplicate agents doing the same work in three departments. Agents built for a project that ended six months ago and never switched off. Sub-agents spawned by other agents. The fix isn’t sanctioning, it’s continuous inventory and ownership.
The reason to keep them separate: an organization can close the shadow AI gap completely and still have a sprawl problem, because every agent in the estate went through review at a point in time and none of them are being re-examined. Both end in the same place — a security team governing what it thinks is deployed rather than what actually is — but they get there by different routes.
What is a rogue AI agent?
“Rogue AI agent” is used loosely and is worth pinning down, because it is often applied to two situations that have almost nothing in common.
The first is an agent operating outside sanctioned tooling — which is shadow AI, described above, and is a governance gap rather than a behavioral one. The second is a sanctioned agent behaving outside its intended scope: taking actions nobody specified, accumulating access it was never scoped for, continuing to run after its task should have ended. That is a behavioral problem, and it happens to fully approved agents with perfectly correct paperwork.
The distinction matters because the detection method differs. Finding agents nobody approved is a discovery problem. Finding approved agents behaving in ways nobody intended requires knowing what “intended” looked like in the first place, which is a question about posture and behavior rather than about inventory.
How do you detect shadow AI and unsanctioned agents?
Three approaches are common, and the first two are the ones most organizations try first.
Employee surveys. Cheap, fast, and useful as a conversation starter. They rely on people knowing that what they are using counts as an AI agent, remembering everything they’ve connected, and having a reason to be thorough. They tend to surface the obvious and miss the incidental.
Gateways and traffic inspection. More rigorous, and genuinely effective for what passes through them. The limitation is structural: a gateway sees what crosses its boundary. Tool types that don’t produce outbound traffic through that boundary — notably skills, which are defined inside the agent’s own configuration — don’t show up. A gateway scoped to one protocol covers that protocol well and is silent on everything else.
Reading the agent’s own configuration. Rather than asking people what they run or watching what crosses a network boundary, this means detecting agents from the artifacts they leave in the environments they actually live in: code repositories, endpoints, cloud accounts, and the harness configuration that defines what each agent is and what it can reach.
In practice, these are complementary rather than competing, and the evidence for combining them is fairly blunt. In one engagement, a French biotech company discovered 327% more agents than its CTO and security team expected. In another, a British bank had already run employee surveys and deployed MCP gateways for its developers, and still had significantly more tool connections surfaced than its own proactive efforts had captured — concentrated in the tool types that gateways alone don’t cover.
Why a complete inventory still isn’t enough
This is the part most discovery advice stops short of. A finished inventory is a list, and a list of agents answers exactly one question: how many are there. It doesn’t tell you which of them matters.
Three different things get flattened together when discovery output is treated as the goal:
- Architecture shows how an agent is built — its harness, its model, its structure.
- Configuration shows what it can do — its tools, credentials, permissions, and data access.
- Behavior shows what it actually does when it works.
Most teams that complete a discovery exercise have the first, some of the second, and none of the third. That’s why a count on its own doesn’t change many decisions: two agents can be architecturally identical and configured identically while representing entirely different risk, because one of them is exercising capabilities the other never touches.
What makes an inventory operationally useful is the connections rather than the entries — each agent joined up to its owner, its identity, the model behind it, the tools and data it reaches, the permissions it carries, the work it does, and the outcomes it produces. That’s a graph rather than a spreadsheet, and it’s the difference between knowing an agent exists and being able to answer a question about it. The practical test: if your inventory can’t tell you who owns a given agent and what would break if you turned it off, it isn’t finished, however complete the count is.
What are the risks of shadow AI?
The concrete risks divide into three groups.
Data and IP exposure. An unsanctioned agent processing company data does so under whatever terms its account carries, not the enterprise agreement. One identity platform found an employee using an AI assistant without an enterprise license, with the account email linked to a competitor — exposing both customer data and company IP through a route neither endpoint nor network controls had surfaced. That case is worth noting for what it actually was: an insider threat discovered through agent visibility, not through a traditional insider-threat program.
Compliance and audit failure. Frameworks like the EU AI Act, NIST AI RMF, and ISO 42001 assume the organization can produce an accurate account of the AI systems it operates. An inventory that is materially incomplete doesn’t just fail an audit, it invalidates every risk decision layered on top of it.
Unmanaged cost. Unsanctioned and forgotten agents spend money. Developer agents running side projects on company tokens, duplicate agents doing the same work in parallel, agents still executing long after their task completed. This is the same instrumentation gap seen from a financial angle rather than a security one, and it’s covered in agent cost governance.
Common questions
Isn't shadow AI just shadow IT with a new name?
The pattern is the same and the exposure isn't. Unsanctioned SaaS is a place data can sit. An unsanctioned agent is something that acts — it holds credentials, connects to tools, and takes actions across systems on its own initiative. The discovery problem is also harder, because a SaaS application is a recognizable thing with a login and a bill, while an agent can be fifty lines of configuration in a repository that no procurement process ever touched.
Do you need a definition of "agent" before you can build an inventory?
Yes, and it's the step most inventories skip. Without one, different teams count different things and the resulting number means nothing. A workable definition is deliberately low: an LLM reasoning core connected to at least one tool. That covers a single-tool copilot and a complex multi-agent architecture under the same rule, which matters because most organizations run both without a clean line between them. A narrower definition produces a tidier inventory that leaves out most of what's actually deployed.
How often should an agent inventory be refreshed?
Continuously, in the sense that a point-in-time count starts decaying immediately. Agents get created by people who are entitled to create them, sub-agents get spawned by other agents, and tool connections change without the agent's original configuration being touched. An inventory refreshed quarterly is a reasonable compliance artifact and a poor operational one.
Should unsanctioned agents just be blocked?
Blocking is available and it's usually the wrong first move. Employees adopt these tools because they work, so blocking without an alternative pushes the same activity somewhere less visible. Discovery first, then a decision per agent: sanction it, replace it with a supported equivalent, or remove it. The sanctioned-versus-unsanctioned divide is growing mainly because developer tool preferences diverge from what organizations provide, and that gap closes faster through provision than prohibition.
