What is agent sprawl?
Agent sprawl is the condition in which an organization's AI agents outpace its capacity to govern and account for them. Agents reach production without a named owner or an approval record, and their running cost cannot be traced back to anyone. The agents themselves usually work. It is the estate around them that does not.
The word borrows from urban planning, and the analogy is precise enough to be useful. Sprawl is not caused by building too much. It is caused by building without a plan for the roads and the records, so growth outruns the infrastructure that makes it livable. Applied to enterprise AI, the buildings are agents and the missing infrastructure is an inventory and an approval path, plus a way to trace cost and behavior back to an owner.
That distinction matters more than it first appears, because most treatments of the subject describe agent sprawl as a volume problem and imply that the remedy is fewer agents. That framing produces the wrong institutional response, usually a moratorium or a review board. The more accurate framing is that agent sprawl describes a gap between two growth rates, agent count and governance capacity. Close the gap and a large estate is an asset. Leave it open and a small one is a liability.
Gartner has put numbers on both sides of that gap. It expects the average global Fortune 500 enterprise to be running more than 150,000 agents by 2028, up from fewer than 15 in 2025, and reports that only 13 percent of organizations believe they have the right agent governance in place today. The first figure is the growth rate. The second is the governance capacity. Agent sprawl is the distance between them, and on those numbers the distance is widening for almost everyone. Source: Gartner, April 2026.
Why counting agents tells you nothing. Four hundred agents with named owners, approval records, and cost attribution is an agent estate. Twelve agents without them is agent sprawl. The number on its own carries no information about whether an organization has a problem, which is why the useful diagnostics test for missing controls instead.
What causes agent sprawl?
Agent sprawl is caused by agent creation becoming faster and cheaper than agent governance. No organization decides to let its agents go ungoverned; sprawl emerges from five separate mechanisms, and each needs a different remedy.
The build barrier fell before the governance barrier moved
Launching a production agent used to take engineering support and dedicated infrastructure. Now it just takes a browser and a login. Governance processes were built for that old, slow, gated way of deploying, and they never caught up. So the approval step quietly became optional in practice, long before anyone decided it should be.
Agents arrive with platforms the organization already licenses
This mechanism is the one most often missed, and it is what makes agent sprawl structurally different from earlier waves of technology sprawl. Agent-building capability now ships inside tooling the enterprise has already bought. A team with an existing cloud or data platform subscription can create agents without a new purchase or a new vendor, so no procurement event occurs to trigger a security review.
Every agent platform keeps its own inventory
Most large enterprises run agents on more than one platform, each with its own console and its own list. The consequence is that "we have an agent registry" is frequently true and still insufficient, because there are several and none is authoritative. Cross-platform coverage is where a governance program most often discovers it has been measuring a fraction of its estate.
Agents are created but almost never retired
Agent estates pile up because someone owns the job of creating an agent, but nobody owns the job of shutting one down. A pilot a team stopped using rarely gets switched off, it just sits there, still holding its credentials, its data access, and its running costs. Over a few quarters, a big chunk of a sprawling agent estate isn't agents misbehaving, its agents doing nothing at all, quietly burning money while still holding live permissions.
Duplication is invisible without a shared catalog
Two teams solving similar problems will build similar agents, and neither will know. There is no malice and no incompetence in this, only the absence of a place to look first. Duplication is the most reliably detectable symptom of agent sprawl and usually the first one an inventory surfaces.
How do you know if you have agent sprawl?
Agent sprawl is diagnosed by testing for missing controls rather than by counting agents. These five tests can each be run inside a week without new tooling, and each one isolates a specific gap rather than a general sense that things are getting away from you.
What are the risks and costs of agent sprawl?
The risks of agent sprawl fall into five categories: an unmapped attack surface, unprovable compliance, duplicated spend, a wider blast radius when an agent misbehaves, and the opportunity cost of a scaling program that leadership halts. Security is the sharpest of these; the others are what more often stall an AI program before any incident occurs.
- Expanded and unmapped attack surface. Every agent holds credentials and reaches into systems and data. An agent nobody has inventoried is an access path nobody is monitoring, and agents that inherit broad permissions from the user or service account that created them can act well outside their intended scope.
- Unprovable compliance. In a regulated function, an action taken by an agent carries the same obligations as the same action taken by an employee. If an organization cannot reconstruct what an agent did, on what data, under whose authority, it does not have a documentation gap. It has an unevidenced control, which is generally treated as a failed one.
- Compounding duplicated spend. Duplicated agents mean duplicated build effort, then duplicated inference and infrastructure cost every day afterwards. Because that spend is variable and distributed, it rarely appears as a line item anyone owns, which is precisely why it persists.
- Wider blast radius on failure. When an ungoverned agent behaves unexpectedly, containment is slow because the first questions have no ready answers: what else does this agent touch, what depends on its output, and who can stop it. Time spent establishing that is time the behavior continues.
- Blocked scale, which is usually the largest cost. Once leadership loses confidence that the agent estate is under control, the reflex is to restrict new deployment. The program stops midway, having paid for the agents and not yet collected the return, and teams route around the restriction with unsanctioned tools, which converts the original problem into a worse one.
How is agent sprawl different from shadow AI and SaaS sprawl?
Shadow AI describes provenance and agent sprawl describes governance. Shadow AI asks who deployed an agent and whether anyone approved it. Agent sprawl asks whether any agent, sanctioned or not, has an owner of record, an approval trail, and attributable cost.
These terms are used interchangeably and they should not be. Each names a different failure, and conflating them leads teams to apply a control that does not address what they actually have.
| Term | What it describes | The core question | Primary control |
|---|---|---|---|
| Agent sprawl | Agents growing faster than the governance capacity around them | Are our agents inventoried, owned, and accountable? | Inventory, promotion gating, runtime attribution |
| Shadow AI | AI deployed outside sanctioned channels, without IT or security awareness | Who put this here, and did anyone approve it? | Discovery, sanctioned alternatives, policy |
| AI sprawl | Proliferation of AI tools and point solutions generally, agents included | How many overlapping AI tools are we paying for? | Portfolio rationalization |
| Model sprawl | Many models in use with no standard for selection, versioning, or evaluation | Which model is this running on, and why that one? | Model catalog and evaluation standard |
| Tool sprawl | Agents wired to overlapping external tools and APIs with no shared gateway | What can our agents actually reach? | A single audited tool gateway |
| SaaS sprawl | Accumulated overlapping software subscriptions | What are we licensed for and who uses it? | License and spend management |
Scroll the table horizontally to see all columns.
The most consequential of these distinctions is the first pair. A fully sanctioned agent, built by the platform team with executive sponsorship, is not shadow AI and can still be part of agent sprawl if it has no owner of record, no approval trail, and no attributable cost. This is why organizations that have completed a shadow AI discovery exercise are often surprised to find a sprawl problem remaining: they answered the provenance question and left the governance question open.
The difference from SaaS sprawl is one of consequence rather than category. SaaS sprawl accumulates passive subscriptions, while agent sprawl accumulates active systems that take actions and hold data access. An unused software license wastes money. An unused agent wastes money and retains live credentials and the standing permission to act.
How do enterprises fix agent sprawl?
Enterprises fix agent sprawl by closing the governance gap rather than by reducing agent count, through six controls applied in sequence: discover, register, consolidate, gate, instrument, and retire.
The order matters, which is unusual for a list of recommendations. Each control produces the input the next one needs, and organizations that begin at step four or five commonly find they are governing a subset of their agents without knowing which subset.
The six controls, in order
Two things are deliberately missing from this approach: a freeze on creating new agents, and a central review board every team has to line up for. Both would cut down the number of agents, sure, but neither genuinely fixes the underlying governance gap. And both push teams to quietly use tools outside the approved system instead, turning a sprawl problem into an even harder shadow AI problem.
How these six controls line up with Gartner's six steps
Gartner published its own six steps for managing agent sprawl in April 2026, and buyers now arrive at vendor conversations holding that list. The vocabulary differs. The substance overlaps almost entirely. The mapping below exists so the two can be read side by side in a governance review without anyone having to translate.
| Gartner step | Closest control above |
|---|---|
| Establish agent governance and policies | Gate the route to production, where policy becomes a condition of shipping instead of a document |
| Build a centralized agent inventory | Discover, then register |
| Define agent identity, permissions and lifecycle | Register holds the permission record; retire supplies the end state |
| Develop AI information governance | Register records what data each agent can reach, and instrument watches what it does with it |
| Monitor and remediate agent behavior | Instrument at runtime |
| Foster a culture of responsible AI usage | No direct equivalent, because this is a program practice rather than a control. Consolidation is the nearest thing to it: reuse only becomes the default once teams can find what already exists |
Scroll the table horizontally to see all columns.
Which category of tooling provides these controls
The six controls do not map neatly onto a single product category, which is a common source of confusion during vendor evaluation. Agent management platforms typically cover registration, promotion, and runtime observability together. Identity governance tools address the credential and permission side, treating agents as non-human identities. AI observability and FinOps tools address cost attribution and telemetry. Cloud and data platform consoles cover the agents built on their own stack, which is useful and is also the origin of the cross-platform gap described earlier. Most enterprises assemble coverage from more than one of these, and the practical question is less which category to buy from than which of the six controls is currently missing.