Five years ago it was a SaaS sprawl. Every team picked its own project management tool, its own file storage, its own analytics dashboard, and IT found out about most of it during a security audit, not before. Enterprises spent years and real budget clawing that back into something governed.
That problem is happening again, faster, and with much higher stakes.
Agent-builder tools have gotten easy enough that any team with a Friday afternoon and mild curiosity can stand up an agent. Sales builds one to draft outreach. Ops builds one to triage tickets. Someone in finance connects an agent-builder to a spreadsheet and a Slack channel and calls it automation. Each one gets its own credentials, its own ad hoc access to whatever system that team could plug it into, and its own logic that nobody outside that team has reviewed.
This looks like innovation from inside each team. From the center, it looks like an org accumulating dozens of ungoverned actors with real permissions, and almost nobody tracking what any of them can actually do.
Why this is worse than SaaS sprawl
SaaS sprawl was a data problem. An unsanctioned tool meant data sitting somewhere IT did not know about, exposed to whatever security posture that vendor happened to have. Bad, but bounded. The data sat there. Someone eventually found it, and the damage was contained to what had leaked.
Agent sprawl is not a data problem. It is an action problem, and that distinction changes everything about how dangerous it is.
A rogue SaaS tool stores your customer list somewhere it shouldn't be. A rogue agent can email that customer list, or worse, act on it.
A shadow spreadsheet sits quietly until someone stumbles on it. A shadow agent is actively doing things, right now, on a schedule, with credentials nobody is watching.
SaaS sprawl generally requires a human to actually misuse the exposed data for real damage to happen. Agent sprawl removes that human step entirely. The agent is already taking the action.
An unsanctioned tool is a liability sitting still. An unsanctioned agent is a liability in motion. This is the same gap that shows up when enterprise AI agents are evaluated only on reasoning quality, with nobody checking whether the agent had any business holding the access it used to act.
How it actually happens
Nobody sets out to create agent sprawl. It accumulates through a series of individually reasonable decisions:
A team gets access to an agent-builder platform, often through a low-friction free tier or a departmental budget nobody scrutinizes closely.
Someone connects it to a real system, an email account, a CRM, a shared drive, because that is what makes the agent useful.
The agent works, so it gets expanded. More triggers, more integrations, more scope, added incrementally, each addition small enough that nobody flags it for review.
Six months later, that team has an agent with standing access to three systems, running on a service account someone set up once and has not looked at since, doing something nobody outside the team could fully describe if asked.
Multiply that by every team in the org that has discovered agent-builder tools, and the result is not a handful of agents to govern. It is dozens, each with its own access footprint, its own logic, its own blast radius, built by people who were solving a local problem and had no reason to think about the aggregate risk they were contributing to. This is the same fragmentation that sits underneath most enterprise AI infrastructure failures, just multiplied across every team building independently instead of concentrated in one broken integration.
What this actually costs an enterprise
The visible cost is the one everyone worries about first: an agent does something it should not, sends the wrong information to the wrong person, takes an action based on stale or wrong data, and there is no clear owner or audit trail to explain why. That is real, and it happens. This risk compounds specifically in workflows built on live employment and income data, where an agent acting on stale or unverified information does not just produce a bad output, it produces a wrong financial decision.
The less visible cost compounds faster. Consider what centralized security and compliance teams are now facing:
No consolidated inventory of which agents exist, what they can access, or who owns them.
No consistent standard for how access gets granted, reviewed, or revoked across agents built by different teams on different tools.
No way to answer a regulator's question about what an AI system did, because the agent that did it was never registered as something requiring that answer in the first place.
Duplicated effort, with three different teams independently building similar agents against the same systems, each with its own inconsistent access setup, because there was no shared, governed path to build one properly.
None of this shows up on a P&L line. All of it shows up the moment something goes wrong, or the moment an auditor asks a question nobody centrally can answer.
The old fix does not work here
The instinct with SaaS sprawl was eventually to consolidate, standardize on approved tools, and route new requests through IT. That model does not transfer cleanly to agents, because the whole appeal of agent-builder tools is speed. Teams adopted them precisely because waiting on a centralized process felt too slow for what they needed. A governance model that just says no and routes everything back through a slow, central bottleneck will get quietly bypassed the same way shadow SaaS did, just with a more capable, more dangerous class of tool doing the bypassing.
The fix has to preserve the speed teams actually want while removing the part that makes ad hoc agent creation dangerous: unmanaged, ungoverned access. That means:
A centralized, governed layer for agent creation that is still fast enough for teams to actually want to use it, rather than working around it.
Access provisioned per agent, per task, tied to identity and scope, not a standing credential a team sets up once and never revisits.
Every agent registered somewhere central by default, not as an afterthought once someone notices it exists.
Deprovisioning that happens automatically when an agent, a task, or the person who owns it changes status, not months later during a scramble.
This is not about slowing teams down. It is about making the governed path the fast path, so nobody has a reason to build around it.
The window to fix this is closing
Every enterprise currently has some number of agents already live that nobody centrally has fully inventoried. That number is only going up, because the tools to build agents keep getting easier and more teams keep discovering them. The organizations that get ahead of this now, with a governed, centralized way to build and provision agents, will avoid spending the next several years doing what enterprises just finished doing with SaaS: clawing back visibility into a sprawl that should never have been allowed to form in the first place.
The question is not whether agent sprawl is happening inside your organization right now. It almost certainly already is. The question is whether anyone centrally could actually list every agent, what it can access, and why, if asked today.
