AI Agent Sprawl: The Enterprise Governance Crisis

Twelve months ago the question in every enterprise AI programme was "can we build an agent that actually works?" Today the question is "how many agents do we already have, who owns them, and what are they doing with our data?" Almost none of our clients can answer that question with any confidence. That gap between deployment velocity and governance capacity is what the industry has started calling agent sprawl, and it is the single biggest operational risk we see across the enterprise AI estates we audit in 2026.

This is our field view of what agent sprawl actually looks like inside a Fortune 1000 estate, why the usual SaaS-governance playbook does not translate cleanly, and the operating model we implement when we are asked to bring an out-of-control agent population back under control.

What agent sprawl actually looks like

The pattern is remarkably consistent. A platform team ships a well-governed agent framework. Six months later the CIO's office asks for an inventory. The platform team confidently produces a list of eleven agents. A cross-functional survey finds one hundred and forty. A subsequent network-level audit finds three hundred and sixty, most of them built directly on vendor SDKs by product teams, marketing operations, sales enablement, and individual power users on the finance team who discovered they could build a "just a small helper" using their approved copilot licence.

None of this is malicious. The productivity wins are real, the tooling is genuinely accessible, and the enterprise's own message all year has been "adopt AI faster." The result is a fragmented population of agents with the following properties in common:

• No shared registry. No single system knows every agent's name, owner, purpose, permissions, upstream models, downstream tools, or the data it touches.
• Inconsistent identity. Some agents act as a service account, some as the invoking user, some as a shared team credential nobody has rotated in a year.
• Overlapping function. Three separate agents in three departments summarise the same CRM records in three different ways, each with a slightly different retention policy and a different failure mode.
• Silent tool access. Agents wired to Slack, email, calendars, cloud storage, and internal APIs through connectors nobody in security has reviewed.
• Zero shared observability. When something goes wrong the incident cannot be traced because half the agents log to the vendor console and the other half log nowhere.
• Nobody accountable at retirement. When the original builder leaves, the agent keeps running against production systems with credentials that outlive the person who provisioned them.

Any one of these issues is manageable. In combination, they create an audit surface that no CISO or general counsel will sign off on once they see the picture clearly. The uncomfortable truth in most 2026 estates is that leadership has approved AI transformation programmes whose actual population of live agents is an order of magnitude larger than what the programme officially owns.

Why the SaaS governance playbook does not translate

The instinct in most enterprises is to point the existing SaaS governance apparatus at the problem. That does not work, for reasons worth being blunt about.

• Agents are not applications. An agent is a bundle of a model, a prompt, a set of tools, an identity, and a memory. It behaves non-deterministically. Cataloguing it as a single line item in a SaaS register misses the entire risk surface.
• Approval gates lag creation velocity. A determined product manager can spin up an agent in an afternoon. A SaaS approval cycle takes six weeks. The gap is where sprawl lives.
• Tool access is dynamic. Traditional access reviews assume static permissions. Agents acquire tools at runtime through registries like MCP. Your registered agent from last quarter may have doubled its capability surface since then without anyone approving anything.
• Behavioural drift is invisible. A SaaS app behaves the same today as yesterday. An agent's behaviour drifts when the model provider silently updates a version, when a prompt is edited, when a new tool is added, or when its context window fills with a poisoned document.

Agent governance has to be built for the properties agents actually have, not the properties enterprises wish they had.

The operating model we implement

When we are engaged to fix an agent sprawl problem, we implement a five-layer operating model. It is deliberately unglamorous. The point is to give the organisation a defensible answer to every question the board, the regulator, and the security team will eventually ask.

1. A canonical agent registry

Every agent in the enterprise, wherever it runs, gets a record. The record includes owner, business purpose, data classifications touched, models used, tools authorised, identity used, hosting environment, retirement criteria, and last review date. Discovery is active — network egress logs, connector-side inventories from every AI vendor in the estate, and directory scans across the code and prompt repositories — not just voluntary disclosure. Voluntary disclosure alone will always undercount by a factor of ten.

2. Identity per agent

Every agent gets its own machine identity, scoped to the minimum tools and data it needs. No shared service accounts. No agents acting as the invoking human unless there is an explicit compliance reason. Identity issuance is tied to registry entry — if it is not in the registry, it cannot get a credential; if the credential is revoked, it cannot act.

3. A shared control plane for tools

Tool access flows through a single internal gateway rather than direct connectors from each agent to each downstream system. The gateway enforces per-agent scopes, per-tool rate limits, PII redaction where required, and audit-grade logging of every tool invocation. This is where the equivalent of an LLM gateway meets the equivalent of an API gateway, and it is where most of the actual security value lives.

4. Continuous behavioural monitoring

Every agent's inputs, outputs, tool calls, and errors are streamed to a shared observability plane. Automatic detectors flag prompt injection attempts, sudden shifts in tool-call patterns, unusual data volumes, and behaviour drift after a model version change. This is not an academic capability — it is how incidents get caught before they become disclosures.

5. A lifecycle with a real end

Every agent has an owner, a review cadence, and explicit retirement criteria written at creation time. Ownership transfers when people leave. Agents that fail a review are decommissioned, not renewed by default. The registry tracks retired agents so their credentials can be verifiably killed and their historical activity can still be audited.

The organisations that get through the next two years without an agent-related incident will not be the ones that deployed the fewest agents. They will be the ones that treated the agent population as a first-class inventory from day one.

Where to start this quarter

Most enterprises we talk to are somewhere between "we know we have a problem" and "we are afraid to look." A useful first quarter looks like this: run a real discovery exercise across every AI vendor console, MCP server, connector platform, and network egress log to get an honest agent count; assign an accountable owner to every agent above a materiality threshold; kill or quarantine every agent whose owner cannot be found; issue per-agent identities to the survivors; and route their tool access through a single reviewable gateway. That is enough to move an organisation from "the answer is unknowable" to "the answer exists and we own it." Everything else — sophisticated behavioural monitoring, formal lifecycle policy, board-level reporting — can be built on top of that foundation once the foundation actually exists.

Agent sprawl is not a future problem. In every estate we have audited this year, it is already a present one. The organisations that treat it as an inventory-and-identity problem now will be the ones that can safely say yes to the next wave of agentic capability. The organisations that keep deploying without a registry will be the ones explaining to a regulator, in eighteen months, why three hundred and sixty autonomous agents were operating against production data with credentials nobody had reviewed.