AI agent sprawl is already the new shadow IT — and the fix is not another governance policy slide. The fix is an agent control plane: a single operational layer that handles machine identity, ephemeral access, runtime kill switches, per-agent cost budgets, and decision accountability for every autonomous agent your employees spin up. Gartner projects the average Fortune 500 enterprise will go from fewer than 15 AI agents in 2025 to over 150,000 by 2028, and only 13% of organizations believe they have the right governance in place to handle it. The companies that win this decade will not be the ones that deploy the most agents — they will be the ones that can say, with a straight face, that they know what every single agent is doing. This guide is the missing layer between "we have a governance policy" and "we can prove it." For the companion piece on what sprawl is and the four-layer governance framework, see our full AI agent sprawl governance guide; this article is the operational "how to build it" sequel.
Last verified: 2026-07-31 · Primary keyword: AI agent control plane
- Gartner: Fortune 500 enterprises will go from <15 agents (2025) to >150,000 (2028); only 13% feel their agent governance is adequate (Gartner, April 2026).
- The EU AI Act Article 14(4)(e) already legally requires a "stop button or similar procedure" for high-risk AI systems (EUR-Lex / AI Act Service Desk).
- 98% of FinOps practitioners now formally manage AI costs, up from 31% in 2024 — the fastest adoption of any FinOps practice in history (FinOps Foundation, State of FinOps 2026).
Volatile facts: Vendor control-plane tooling, agent platform features, and EU AI Act deadlines change often — re-verify before acting.
What Is an AI Agent Control Plane?
An AI agent control plane is the centralized operational layer that governs the entire lifecycle of autonomous agents — from creation, through identity and access provisioning, runtime monitoring, cost accounting, kill-switch execution, and retirement — independent of which vendor, model, or business unit built the agent. Without it, agents become ungoverned shadow AI: invisible to IT, unauditable, and unstoppable when they misbehave.
The reason almost every enterprise is missing this layer is structural. The tools that let employees build agents are not the tools that govern them. A marketing team can spin up a workflow agent in Anthropic's Claude Cowork in minutes (Anthropic); IT has no console that even sees that agent exists. The result is a store-and-forget model — agents get created faster than they can be discovered, classified, permissioned, or decommissioned.
A control plane is not the same as a governance policy. A policy says agents should follow the rules. A control plane makes following the rules mechanically enforceable — the difference between a sign on a door and an electronic lock.
Why a Policy Isn't Enough: The Two Agent Types Driving Sprawl
Enterprises face two fundamentally different kinds of AI agents, and sprawl comes almost entirely from the second kind.
| Agent type | Who builds it | Sprawl risk | Control lever needed |
|---|---|---|---|
| Process-automation agents | Central IT / platform team | Lower — centrally controlled, scoped, retired on a schedule | Versioning, retirement cadence, integration audit |
| Digital-workplace agents | Individual employees, business units | High — created in minutes via low/no-code tools, ungoverned, never retired | Self-service guardrails, mandatory registration, auto-expiry |
The explosion to 150,000 agents is mostly digital-workplace agents — the employee-built kind. Process-automation agents carry their own risk when the underlying workflow was never re-engineered for an autonomous actor (we've written separately about why AI fails in the enterprise until the process is rebuilt, not the model), but the sprawl fire is lit almost entirely by the employee-built agents piling up without inventory. Low-code and no-code agent builders (Claude Cowork, Google Gemini in Workspace, Microsoft Copilot Studio, and a long tail of autonomous agents that creep in as "shadow AI") made creation trivial, but lifecycle management was never part of the product. Creating an agent is like adopting a pet; everything that comes after — training, vaccinations, tick checks, nail clipping — is the hard part. Enterprises are enthusiastically adopting and almost never maintaining.
This is why a policy fails. You cannot retroactively govern thousands of agents you cannot see. The control plane's first job is discovery: before you can manage agents, you have to know they exist.
How Do You Build an AI Agent Control Plane? (The 6 Layers)
A workable agent control plane stacks six operational layers. Each maps to a concrete failure mode that ungoverned sprawl produces — and to a regulatory or industry standard that already expects it.
1. Agent discovery and inventory (the census)
You cannot govern what you have never counted. The first layer is an always-on registry that discovers agents across sanctioned tools and shadow AI, tags each one with its owner, business unit, models, data sources, and risk tier, and flags redundant replicas.
The single most-cited sprawl anecdote is a CIO who reported building 2,000 agents in eight months — then admitted only around 200 of those should exist. The other 1,800 were redundant duplicates, each quietly incurring compute, API, and governance costs for zero incremental value. That CIO's problem was not ambition; it was no inventory. Gartner's published guidance calls this out directly: organizations should use AI trust, risk, and security management (AI TRiSM) tooling to discover and categorize agents across applications, "both from sanctioned tools, and from shadow AI solutions" (Gartner, April 2026).
2. Machine identity with ephemeral, not perpetual, access
Identity for agents must work differently from identity for humans. The default for humans is perpetual access — you join a company, get access to a set of applications, and keep that access until you leave. Apply that default to machines and you get the security posture that produced the cloud-credential-leak era, scaled up.
Agents are usually built for a specific task. When the task is done, the agent should not have access to anything — but with perpetual access it quietly retains API keys, data-source credentials, and tool permissions forever. The control-plane principle is ephemeral access: identities are short-lived, scoped to a single task or workflow, and auto-revoked when the task completes. A machine should never hold "lifetime" access the way an employee does.
This requires treating agent identity as a first-class workload-identity problem — the same way mature platforms issue short-lived tokens to services rather than long-lived static keys. The cloud-security industry already document the rise of non-human identity (NHI) as the fastest-growing identity surface; agents are simply the newest and most numerous NHI type.
3. Runtime controls and the kill switch
Identity gets you visibility; runtime controls get you the ability to act when an agent misbehaves. The control plane must support real-time observation of agent behavior and a kill switch that immediately halts an agent — whether it is misbehaving on governance, cost, customer-facing, or safety grounds — and brings it to a safe state.
This is not a nice-to-have. The EU AI Act, in Article 14(4)(e), legally requires high-risk AI systems to let a human "intervene in the operation of the high-risk AI system or interrupt the system through a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state" (EUR-Lex). The kill switch is now a regulatory floor, not a leading-edge feature. A control plane that cannot instantly quell a rogue agent is, by this standard, already non-compliant for any agent you classify as high-risk.
The practical design test: pick any agent your team built this month. If you cannot name the person who can stop it, the network path to halt it, and the safe-state it falls back to — you do not have a kill switch, you have a wish.
4. Agent FinOps: per-agent, per-task cost budgets
Agents are the first workload that can autonomously increase your cloud bill in a tight loop. An agent can spin up smaller sub-agents, recurse on tasks, and fire off dozens of LLM API calls in seconds — a single runaway loop can burn thousands of dollars in API spend in under an hour. Traditional FinOps was built for predictable compute; agents violate every assumption it rests on.
The control plane's cost layer needs three things:
- Per-agent and per-task cost attribution — not aggregate tokens, but dollars tied to a specific agent and workflow, surfaced through the existing LLM-observability stack (Langfuse, Helicone, LangSmith, or vendor-native gateways).
- Hard budget enforcement at runtime — circuit breakers that halt an agent when it crosses a spend threshold, and swarm-level budgets that cap spend across multi-agent orchestrations. Runyard and a growing category of "AI cost control" vendors ship SDKs that wrap inference calls with these limits.
- Value accounting — the FinOps Foundation's State of FinOps 2026 found 98% of practitioners now formally manage AI costs (up from 31% in 2024), yet 40.1% still cannot quantify AI value or ROI, and 53.4% lack visibility into AI spending (FinOps Foundation). Cost without value is the governance failure mode: you can see the bill but cannot prove the agent earned its keep.
The three questions finance teams now ask before signing off on an agent deployment codify this: What did the agent spend? What did it produce? Who authorized the spend? If your control plane cannot answer all three for any agent, the CFO will eventually veto its renewal.
5. Red-teaming and evaluation before production
Agents are probabilistic systems — they reason, orchestrate workflows, and behave, rather than deterministically execute a script. That means "it worked on the demo" is not evidence it will work in production. The control plane must gate promotion to production with red-teaming and evaluation: stress-test the agent as an ethical hacker would, drive it toward edge cases and known failure modes (prompt injection, data oversharing, hallucinated customer-facing answers, cost runaway), and only release it once there is confidence it behaves predictably.
Red-teaming is the agent equivalent of a load test — and just as load testing found the servers that would crash at peak traffic, agent red-teaming finds the agents that will embarrass the company under adversarial conditions. An agent that has never been deliberately broken should not be let near a customer or a production database.
6. Accountability assignment (the ownership record)
The last layer is the one most enterprises skip — and the one that turns a governance gap into a crisis. When an agent makes a bad call, who owns the decision? The builder? The deployer? The business unit that benefited?
The honest answer in most enterprises today is: nobody is sure. Forward-leaning organizations with a mature internal AI platform team treat it as shared responsibility — a relay race where every team in the build → deploy → operate chain carries the baton for a leg. In less mature organizations, accountability implicitly falls on whoever built it, often an employee who was never trained on the implications of the tools they were handed. For process-automation agents with no human owner, accountability becomes a collective responsibility of the business unit leader.
The control plane cannot solve the accountability question — it's an organizational design problem — but it can make the answer enforceable: every agent registered in inventory must have a named owner (individual or business unit) before it is allowed to run, and that ownership record is the audit trail produced when something goes wrong. Accountability without a clear owner is the gap that becomes a crisis.
The 90-Day Pilot: What to Do This Quarter
You do not build a control plane in a quarter — but you can stand up a credible pilot of the three highest-leverage layers in 90 days. Here is the concrete sequence, mapped to the layers above.
- Days 1–30 — Discovery sprint. Stand up an agent inventory (even a spreadsheet is a start). Run discovery against sanctioned agent tools and known shadow-AI surfaces. Goal: a number, even if it is ugly. Most enterprises finishing this step are shocked to learn they have five-to-ten times more agents than they estimated.
- Days 31–60 — Identity and kill switch. Issue short-lived, task-scoped credentials to the agents you found. For every agent classified as high-risk or customer-facing, wire a documented kill switch and verify it works (not just that it exists — that it actually halts the agent safely). This is your EU AI Act floor.
- Days 61–90 — FinOps and red-team. Attach per-agent cost attribution to your top-spend agents, set hard budget circuit breakers, and red-team the highest-risk three agents before promoting them. At the end of the pilot you will have a defended perimeter around your most dangerous agents, even if the long tail is still open.
By the end of 90 days you will not have solved sprawl — but you will have moved from "we don't know how many agents we have" to "we catalog them, can stop them, can see what they cost, and have confidence in the ones in production." That is the difference between adoption and control.
What This Means for You
- If you're a CIO or IT leader: winning the agent decade is not an adoption race — it is a control race. Treat the control plane as the prerequisite to scale, not the cleanup after it. The workforce-size agents are already arriving — major services firms are planning agent counts in the hundreds of thousands per organization — and you can see what a 600,000-agent plan means for enterprise IT to understand the scale you are racing toward. Your single highest-leverage move this year is the discovery inventory, because you cannot govern an agent you have never counted.
- If you're a platform or security engineer: the control plane is a workload-identity + runtime-policy problem you already know how to solve. Borrow the patterns from service-mesh and NHI management; what is new is the ephemeral-access default and the per-agent FinOps layer. Think of this as the security half of building an AI agent operating system — the orchestration gets the headlines, but identity-and-control is what makes it safe to run.
- If you're a finance or FinOps leader: agent spend is now the volatilizing line item. Push for per-agent attribution and hard budget circuit breakers before the runaway-loop bill arrives — the 98% of FinOps practitioners now managing AI cost are not early adopters, they are survivors of the first wave.
- If you're a small business owner: you likely have far fewer agents, but the same principles apply at small scale — keep a list of every agent you use, what data it can reach, and how you'd turn it off. Ephemeral access and a documented "stop" are cheap to set up and they are the only thing standing between you and an agent that quietly costs money or sends the wrong email.
FAQ
Q: What is an AI agent control plane? A: An AI agent control plane is the centralized operational layer that governs the entire lifecycle of autonomous agents — identity, ephemeral access, runtime monitoring, cost budgets, kill switches, and accountability — independent of which vendor, model, or business unit created the agent. Without it, agents multiply as ungoverned shadow AI that IT cannot see, audit, or stop.
Q: Why is AI agent sprawl called the new shadow IT? A: AI agent sprawl mirrors the SaaS sprawl of the 2010s, but with far larger blast radius — employees build autonomous agents in minutes with low/no-code tools (Claude Cowork, Google Gemini in Workspace, Microsoft Copilot Studio) and IT has no inventory of them, so the organization cannot tell what its agents are doing, accessing, or deciding. Gartner warns that blocking sanctioned tools just pushes employees to shadow AI, which carries greater risk (Gartner, April 2026).
Q: How many AI agents will enterprises run by 2028? A: Gartner projects the average global Fortune 500 enterprise will have over 150,000 AI agents in use by 2028, up from fewer than 15 in 2025. The estimate is ballpark, drawn from multiple Gartner surveys, and is at the aggressive end of projections; only 13% of organizations believe their agent governance is currently adequate (Gartner, April 2026).
Q: Is a kill switch legally required for AI agents? A: For high-risk AI systems, yes. EU AI Act Article 14(4)(e) requires that natural persons assigned to oversight be able to "intervene in the operation of the high-risk AI system or interrupt the system through a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state" (EUR-Lex). Whether a given enterprise agent qualifies as high-risk depends on its use case, but customer-facing and consequential-decision agents frequently do.
Q: How do you control the cost of AI agents? A: Agent cost is controlled with three layers: per-agent and per-task dollar attribution (via LLM observability tools like Langfuse, Helicone, or vendor-native gateways), hard runtime budget circuit breakers that halt an agent when it crosses a spend threshold, and value accounting that ties spend to a produced outcome. The FinOps Foundation found 98% of practitioners now manage AI costs (up from 31% in 2024), yet over 40% still cannot quantify AI ROI (FinOps Foundation, State of FinOps 2026).
Q: Who is accountable when an AI agent makes a wrong decision? A: In mature organizations with an internal AI platform team, accountability is shared across the build-deploy-operate chain (a "relay race" model). In less mature organizations it implicitly falls on the employee who built the agent — who often was never trained on the implications — or, for process-automation agents with no single human owner, on the business unit leader as collective responsibility. The control plane cannot decide accountability but it makes it enforceable by requiring a named owner on every registered agent.
Discussion
0 comments