Eighteen months ago, the IT director at a mid-size logistics company could name every AI tool in production: two. One for customer support ticket triage, one for internal document search. Both had gone through security review. Both had approved vendor contracts. Both were on a known budget line.
By the time the next annual IT audit ran, the number was 47. Forty-seven autonomous agents, most running under individual developer API keys, billing against personal or departmental credit cards, with no centralized visibility into what data each one touched or what each one cost.
This is not an unusual story. It is the default trajectory when enterprises adopt AI without a governance layer in place from the start.
How it starts
The path to 47 agents rarely involves bad intentions. A product team spins up an agent to summarize customer feedback. Two weeks, working prototype, shipped. A developer on the platform team builds a code review agent to speed up their sprint cycle. Another team automates contract clause extraction for the legal department. Each project is, in isolation, a reasonable effort with a clear payoff.
The problem is not the individual projects. The problem is that each one creates a new API key, a new data flow, and a new spend vector with no connection to IT's view of the environment.
Developers reaching for OpenAI or Anthropic directly is rational from their perspective. The API is well-documented, onboarding takes minutes, and there is no waiting for IT procurement approval. From IT's perspective, every one of those direct API connections is an unregistered endpoint carrying sensitive company data out of the network, without review, without a data processing agreement that IT negotiated, and without any record that IT can produce in response to a compliance question.
What the audit finds
When IT finally runs a discovery sweep, the findings tend to fall into three groups. First, there are the agents that were approved and known about. Then there is a second, larger group: agents built under team budgets that were never flagged to IT because the teams considered them developer tooling rather than production systems. Then there is a third group: personal-use cases where individual employees or contractors set up agents using their own credentials, sometimes for entirely legitimate work tasks, with no visibility from anyone above them.
The cost picture is scattered across accounts. There are company credit cards on file with three or four different AI providers. There are personal cards that employees are expensing. There are contracts negotiated by individual teams with no volume aggregation across the organization. Finance has no consolidated view. The total that appears when IT finally aggregates everything is almost always higher than anyone expected, and the per-team breakdown is impossible to reconstruct after the fact.
The data picture is more concerning than the cost picture. Agents built without a central policy layer have processed customer PII, internal financial projections, legal documents, and HR records. Not because developers did anything wrong, but because nobody defined what the agent was and was not allowed to see. The agent had access to whatever systems it was given credentials for, and it used that access.
The actual risk surface
IT governance teams often frame AI agent sprawl primarily as a cost problem. The cost problem is real and measurable, but it is the most straightforward part to address. The harder issues are data classification and liability exposure.
When an agent that was never reviewed by IT processes a customer's personal information and forwards it to an LLM vendor's API, that is a data flow with regulatory implications. Depending on jurisdiction and industry, it may be a reportable incident. The fact that a developer built it in good faith and nobody explicitly approved or disapproved it does not change what happened to the data.
The same logic applies to internal confidential documents. If a summarization agent was given read access to a shared drive and that drive contained M&A planning materials or unreleased financial projections, those documents likely traveled to an LLM API endpoint that had no specific contract or data processing agreement covering that category of information.
Every IT team we have talked with during early deployments has found at least one agent in their environment handling data it should not have been handling. In most cases the developer who built it did not realize there was a problem, because they were focused on whether the agent worked, not on what the data governance implications were.
What IT is not saying
It is worth being direct about what the governance conversation is not. Requiring AI agents to route through a central control plane is not a message to developers that building AI tools is wrong. It is not a slowdown mechanism or an obstacle to innovation.
The teams building these agents are doing valuable work. The problem is purely structural: when every agent has its own API key and its own billing relationship, IT cannot answer basic questions. Which team is responsible for this agent? What data did it process last month? What did it cost this quarter? Those are not unreasonable questions, and answering them does not require slowing down development. What it requires is that every agent route through a layer that can answer those questions automatically, without requiring developers to file paperwork or restructure their code.
The governance layer should be a path of least resistance, not an approval process. That is the design goal.
Getting back to a governed state
The cleanup process after a sprawl discovery follows consistent phases. First is inventory: identify every agent, which team owns it, what data it accesses, and which LLM vendor it calls. This is almost always done manually the first time, using finance records, network logs, and team interviews. It is slow and incomplete because nobody tracked this information in a structured way.
Second is rationalization: which of the 47 agents need to keep running? Some will be obvious candidates for decommissioning, personal experiments or duplicative tools. Others are load-bearing for team workflows and need to be migrated to a governed setup rather than simply shut down.
Third is forward structure: for every agent that stays, route it through a central endpoint. Assign it to a team namespace. Apply a data classification policy. From that point, the agent is visible, attributed, and governed. This is where the routing layer pays back its setup cost quickly. Once it is in place, every new agent that ships is governed from day one. Sprawl is not fixed retroactively but prevented structurally going forward.
What the routing layer changes in practice
When a routing control plane sits between an agent and the LLM vendor, a few things happen automatically. Every request gets tagged with a team namespace. Cost is attributed to that team in real time, not at the end of the billing cycle. Data classification rules run before the prompt leaves the network: if the request contains customer PII, the policy layer masks or blocks it based on the rules IT has configured. The agent does not change its code. The developer does not change their workflow. IT can see the full picture from a single dashboard.
The shift in governance posture is significant. Instead of IT discovering agents through audit, agents are registered the moment they route their first request. Instead of finance reconstructing spend from six different invoices, the cost dashboard shows attribution by team, by agent, and by date range. Instead of data policy being a post-hoc concern, it is enforced at the only reliable interception point: before the prompt travels outbound to the vendor.
Sprawl does not stop because companies get stricter. It stops because the cost of building with governance becomes lower than the cost of building without it. A routing endpoint that takes an afternoon to configure per agent is a friction-free path to compliance. That structural change is what prevents the next audit from finding 47 unknowns.