Ask an enterprise IT team to list its production servers and you will get a list. Ask for the SaaS contracts and someone can pull the renewal spreadsheet. Ask how many AI agents are running inside the company right now, what each one can touch, and who owns it, and the room goes quiet. That quiet is not a small gap in record-keeping. It is the early shape of the next governance failure, and the field has already named it: agent sprawl.
The numbers are the fastest way to feel the size of it. IBM, presenting survey data at its Think 2026 conference, projects that by the end of 2026 a typical large enterprise will run a digital workforce of more than 1,600 AI agents. In the same survey, only 18 percent of organizations keep a current, complete inventory of the agents already operating inside their walls. Gartner runs the projection further out: by 2028, it expects an average global Fortune 500 enterprise to have over 150,000 agents in use, up from fewer than 15 in 2025. The count is heading into the thousands, and the inventory is a rounding error.
This post is about why that happened so fast, what goes wrong when it does, and what governing it actually takes.
Origin: the same mistake, four times running
Agent sprawl is not a new kind of problem. It is the newest instance of a pattern enterprise IT has lived through several times, and naming the pattern plainly tells you what comes next.
The first instance was shadow IT proper. Through the 1990s and 2000s, departments that could not wait for central IT bought or built their own tools. A marketing team stood up a database. A finance group wrote a spreadsheet macro that quietly became load-bearing. None of it was malicious. People were solving real problems faster than the approval queue allowed. Gartner has long estimated that shadow IT accounts for 30 to 40 percent of IT spending in large enterprises. The work got done. It also got done outside anyone's map.
The second instance was SaaS sprawl. Cloud software lowered the barrier from a procurement cycle to a credit card. A team signed up for a tool in an afternoon, and the company's real software estate drifted away from the contracts IT had on file. A 2024 Productiv report found that 48 percent of enterprise applications are unmanaged, with nobody specifically assigned to watch their usage, licenses, or security. The third instance lived deeper in the stack: service accounts and scripts. Every integration needed a credential, so engineers minted service accounts and left automation scripts running on cron jobs. Each one made sense when it was created. Years later, nobody could say which were still needed, and this kind of machine-identity sprawl tends to stay invisible and unreviewed until a breach forces an audit.
Every one of those waves followed the same arc. Something useful became cheap to create. Creation outran the ability to track. The estate grew faster than the map. Agent sprawl is instance four, and it has every property of the first three plus one that makes it worse. A shadow spreadsheet sits there until a person opens it. A forgotten SaaS app stores data but does nothing on its own. An AI agent acts. It runs on a schedule or a trigger, reads data, calls tools, makes decisions, and moves information between systems with no human in the loop. The earlier sprawls left you with untracked things. This one leaves you with untracked actors.
Present: why agents multiply faster than anything before them
Three forces push agent counts up, and together they explain how a company gets from a handful of agents to a four-digit number in a year.
The first is the low-code and no-code builder. Standing up an agent no longer requires a data science team or even a developer. Microsoft says more than 230,000 organizations have used Copilot Studio, its graphical agent builder, to create custom agents, and that customers built more than a million custom agents across Copilot Studio and SharePoint in a single quarter. The whole design goal of these tools is to let a marketer, an analyst, or an operations lead build an agent without filing a ticket. That is genuinely useful, and it is also exactly the mechanism that produced SaaS sprawl. When creation takes an afternoon and needs no approval, creation happens everywhere at once.
The second is that every team builds its own. Marketing builds a content agent. Sales builds a lead-research agent. Finance builds a forecasting helper. Support builds a ticket-triage bot. None of them knows what the others are doing, because there is no standard registration step for deploying an agent the way there is for requesting a server. Agents arrive as a toggle inside a SaaS product, a no-code workflow, or a quick script that gradually gains access. The result is duplication by default: one analysis describes three teams independently building overlapping summarization agents, and two departments running separate Jira triage bots that conflict with each other.
The third force has no equivalent in any earlier sprawl. Agents spawn agents. The dominant architecture for hard tasks in 2026 is an orchestrator that breaks work into pieces and hands each to a sub-agent. So a single agent a team deployed and counted can, at runtime, instantiate others that nobody deployed and nobody counts. The estate is no longer growing only from the top through human creation. It is also growing from the inside, at machine speed.
Set against that, the governance numbers read like a warning. Deloitte's 2026 State of AI in the Enterprise found that only about one in five companies has a mature model for agentic AI governance. In the IBM survey, seven in ten executives said the AI governance they have today is not fit for purpose. And in the past year, 82 percent of organizations discovered at least one AI agent or workflow that security or IT did not previously know about. Microsoft cited that same shadow-AI pressure when it moved its Agent 365 management product out of preview. The adoption curve and the control curve have separated, and the gap between them is where the risk lives.
What sprawl actually breaks
The harm is not abstract. It shows up as five failures.
Orphaned agents with live credentials. An agent built for a project keeps running after the project ends and its creator changes teams. It still holds API keys and access scopes, often broad ones, and now no human is accountable for it. These credentials tend to be static and long-lived, and unlike a human login they sit behind no multi-factor prompt: if the key leaks, nothing stands between an attacker and your systems. Security researchers describe long-lived secrets as the root cause behind most non-human-identity breaches. This is the service-account problem returning, except the account can now think and act.
Duplicated and conflicting agents. When teams build in isolation, the company pays more than once for the same capability and gets worse results for it. Two agents can pursue conflicting objectives, one optimizing for cost while another optimizes for speed, or hammer the same API until they degrade the system they both depend on. Redundancy here does not just waste money, it produces contradictory outputs that erode trust in every agent.
An expanded attack surface. Every agent adds connections: new SaaS integrations, new API tokens, new data sources, sometimes new open-source dependencies pulled in to make a tool work. Each connection is a door. An estate of 1,600 agents has thousands of doors, most of them undocumented. Non-human identities already outnumber human ones in many organizations by more than 80 to 1, and every agent you add widens that gap. A sprawl you cannot see is a sprawl you cannot defend.
Untracked cost. Agents loop. They call models repeatedly, and a poorly bounded one can run up a bill no one forecast. When every team deploys independently, finance cannot reconcile AI spend: the charges scatter across departments, and the company cannot say which agents earn their keep.
Compliance gaps. Auditors and regulators expect you to show what processes touch regulated data and how, and frameworks like GDPR, HIPAA, and the EU AI Act assume you can produce that record. An agent that finance never knew about, quietly reading customer data, is a gap you cannot close in an audit because you did not know it was there to document.
Future and impact: governing a workforce you cannot see
The fix is not to ban agents. That fails the same way blocking SaaS failed: people route around it, and the sprawl simply goes darker. Gartner's own framing of its six-step program to manage agent sprawl is about making agents governable, not forbidden. Combined with the lifecycle guidance the field has converged on, governing sprawl rests on five capabilities.
A registry and inventory. You cannot govern what you cannot list. Every agent belongs in one organizational record: its purpose, its owner, the model and tools it uses, its data access, and its status. Crucially, the inventory must be populated by discovery, not just voluntary registration, because the agents that most need governing are exactly the ones nobody will register. AI trust, risk, and security management tooling exists to scan for agents across sanctioned and shadow sources alike.
Ownership and lifecycle. Every production agent needs a named human owner and a defined life: registered, reviewed, approved, deployed, monitored, and eventually retired. The point that gets missed is that retirement is a governance action, not a cleanup chore. Retiring an agent means revoking its credentials, removing its data access, and checking what downstream work depended on it. Without an explicit retirement step, every agent ever built stays live forever, which is exactly how the orphan problem compounds.
Identity and least-privilege access. An agent needs its own identity, distinct from the person who built it, so its actions are attributable and its permissions are its own. It should hold the narrowest access its task requires, on credentials that are short-lived and scoped rather than static admin keys. This is the bridge to the deeper problem of AI agent identity: who the agent is, and what it may touch.
Observability. A governed agent is one whose behavior you can see: what it did, which tools it called, what it spent, and where it deviated from its intended scope. You cannot run an estate of autonomous actors blind, and the discipline of agent observability is what turns a population of black boxes into a system you can actually operate.
A retirement and remediation process. The standing ability to find agents that have gone quiet, drifted from their purpose, or lost their owner, and to shut them down cleanly. Sprawl is not a one-time cleanup. It is a current that runs as long as agents are cheap to create, so the counter-process has to run continuously too.
Where Perform Digital fits
Most enterprises do not arrive at agent governance with a clean slate. They arrive with a few hundred agents already running, built by different teams on different tools, and a real fear that hard controls will break work someone depends on. The job is to inventory what exists, assign ownership, scope identities to least privilege, and put observability and a retirement process in place without freezing the teams that came to rely on their agents. This is implementation work, not strategy slideware, and it is the kind of work Perform Digital does: making an agent estate one a company can actually see, account for, and trust.
The honest summary is that agent sprawl is not a future risk to plan around. It is a present condition in most enterprises that have moved on agents at all, and the gap between the agents running and the agents inventoried is the clearest measure of the governance debt already accrued. The companies that treat the agent estate the way they eventually learned to treat servers and SaaS and service accounts, as a population to be inventoried, owned, scoped, watched, and retired, will run agents at scale. The rest will spend the next few years discovering their own agents the hard way.
Council summary
This post argues that agent sprawl is not a novel crisis but the fourth run of a pattern enterprise IT already knows from shadow IT, SaaS sprawl, and service accounts: something useful gets cheap to create, creation outruns tracking, and the estate grows past the map. What makes this instance worse is that the untracked things now act, multiply from inside through orchestrators that spawn sub-agents, and carry live credentials no one owns. The piece is honest that the real numbers are early and that vendor counts vary, but the direction is not in dispute, and the gap between agents running and agents inventoried is a usable measure of governance debt. The reader leaves with a concrete, five-capability checklist: treat the agent estate as a population to be discovered, owned, scoped to least privilege, observed, and deliberately retired, and do it now, because banning agents only pushes the sprawl into the dark.
Comments