What agent sprawl looks like
Picture a mid-size engineering organization. The platform team built a deployment agent using LangGraph. The data team has three agents running in Jupyter notebooks that pull from production databases every hour. DevOps set up a Slack bot with shell access for incident response. Marketing deployed a content agent through a vendor integration nobody in security reviewed.
None of these teams coordinated. There is no shared list of agents, no common policy for what requires human approval, and no single place to see what happened when something goes wrong. The deployment agent and the data pipeline agent both have write access to the same production database, but with different approval rules. One requires a human sign-off. The other does not.
This is agent sprawl. It is not a hypothetical. It is happening now across organizations of every size, and it follows the same pattern as shadow IT a decade ago, except the stakes are higher because these systems can take autonomous action.
The scale of the problem
The numbers paint a clear picture of how fast agent adoption is outpacing governance maturity.
of enterprise applications will embed agentic AI by 2028, up from less than 1% in 2024, according to Gartner.
of Fortune 500 companies have deployed or are actively piloting AI agents, per McKinsey's 2025 State of AI report.
of organizations have fully governed their AI agent deployments with centralized policy, audit, and lifecycle management, based on Stanford HAI 2025 AI Index governance survey data.
That gap between adoption rate and governance maturity is where sprawl lives. Teams are shipping agents because the tooling makes it easy. Nobody is shipping governance at the same speed because it requires cross-team coordination that does not happen organically.
What top sources cover vs miss
| Source | Strong coverage | Missing piece |
|---|---|---|
| Gartner: Manage AI Agent Sprawl | Strong strategic framing of the governance gap. Names the problem and positions agent management as a board-level concern. | No technical implementation path. Does not describe what an agent inventory contains, how to centralize policy, or how to build a kill switch. |
| McKinsey: Scaling AI Agents in the Enterprise | Good coverage of organizational readiness and the speed at which agent adoption outpaces governance maturity. | No concrete governance architecture. Missing: shared policy enforcement, unified audit trail, and decommissioning workflows. |
| Deloitte: AI Agent Governance Frameworks | Useful taxonomy of governance dimensions and risk categories for autonomous AI systems. | Framework-level guidance without operational specifics. No agent inventory schema, no lifecycle management steps, no centralized policy enforcement pattern. |
The gap across all three: plenty of strategic framing, very little operational guidance. This post fills in the practical steps.
Five symptoms of agent sprawl
These are the patterns that show up consistently in organizations where agent deployment has outpaced governance. If you recognize three or more, your organization has a sprawl problem.
1. No agent inventory
Ask your security team how many AI agents are running in production right now. If they cannot answer within 24 hours, you have sprawl. Agents get deployed through Slack integrations, notebook automations, CI/CD pipelines, and internal tools. Nobody tracks them in one place.
2. Overlapping tool permissions
Agent A can write to the production database. Agent B can also write to the production database. Agent C has full AWS credentials because someone copied the environment config from Agent A. Three agents, three teams, three different levels of review. The blast radius of a single compromised credential multiplies with every duplicate.
3. Inconsistent approval policies
The compliance team requires human approval for production deployments. The data team does not. The marketing automation agent sends emails with no approval gate at all. When policies are team-specific instead of organization-wide, the weakest policy defines your actual security posture.
4. Fragmented audit trails
Agent decisions are logged in five different systems. Some agents log to CloudWatch, some to a local file, some to a Slack channel, and some do not log at all. When an incident occurs, reconstructing what happened across agents takes days instead of minutes.
5. No kill switch
An agent starts behaving unexpectedly. It is sending automated emails to customers with incorrect pricing. Who can stop it? The team that deployed it is on vacation. The API key it uses is shared with two other agents. Revoking the key breaks all three. There is no way to disable one agent without collateral damage.
What goes wrong
Sprawl is not an abstract risk. These are concrete scenarios that security and platform teams encounter once agent adoption reaches a certain density.
Conflicting write access
Agent A (owned by the platform team) and Agent B (owned by the data team) both have write access to the production customer database. Agent A requires human approval before any write. Agent B does not, because the data team set it up before the approval policy existed. A bug in Agent B corrupts 12,000 customer records. The platform team discovers it 6 hours later when their agent fails a consistency check.
The intern deployment
A summer intern deploys a helpful automation agent using a tutorial from a blog post. The agent has full AWS credentials because the intern copied the environment configuration from a shared wiki page. The agent works fine for two weeks. Then it starts provisioning EC2 instances in response to ambiguous prompts. The monthly AWS bill spikes by $47,000 before anyone notices.
Shadow agents in notebooks
A data scientist runs an LLM-powered analysis agent inside a Jupyter notebook on their laptop. The notebook connects to the production analytics database using a personal access token. The agent sends summarized results to a Slack channel, but it also logs raw query results to a local CSV file that includes PII. The agent is not in any inventory. It has no policy coverage. When the data scientist leaves the company, the notebook keeps running on a shared server for three months before someone finds it.
Credential reuse chain
Three agents share the same API key for a third-party email service. One agent needs to be disabled after it sends an incorrect batch of customer notifications. Revoking the API key is the only way to stop it, but doing so also disables the other two agents, one of which handles critical order confirmations. The team spends four hours figuring out how to issue new credentials and update the other agents while the confirmation pipeline is down.
Step 1: Build an agent inventory
You cannot govern what you cannot see. The first step is building a comprehensive inventory of every agent in your organization. This is not a one-time spreadsheet exercise. It needs to be a living registry that updates as agents are deployed, modified, and decommissioned.
At minimum, track these fields for every agent:
| Field | Example | Why it matters |
|---|---|---|
| Agent name | deploy-bot-prod | Human-readable identifier |
| Owner | platform-team / jane.smith | Accountability and escalation |
| Framework | LangGraph / CrewAI / custom | Migration and compatibility tracking |
| Tools granted | db.write, s3.upload, slack.post | Blast radius analysis |
| Permissions scope | prod / staging / read-only | Least privilege verification |
| Risk tags | pii-access, financial-write | Policy rule matching |
| Approval policy | require_human for prod writes | Governance coverage check |
| Last audit date | 2026-03-15 | Staleness detection |
| Status | active / paused / decommissioned | Lifecycle tracking |
The inventory should be queryable. Your security team needs to answer questions like "which agents have production database write access?" or "which agents were last audited more than 90 days ago?" within seconds, not days.
Start by surveying team leads. Then cross-reference with API key registries, cloud IAM roles, and CI/CD pipeline configurations. The gap between what teams report and what you find in infrastructure records is usually where the most dangerous ungoverned agents live.
Step 2: Centralize governance
An inventory tells you what exists. Centralized governance tells every agent what it is allowed to do. The goal is not to force every team onto the same agent framework. The goal is to put one policy layer between all agents and the tools they access.
Shared approval workflows
Define approval thresholds at the organization level, not per team. Any agent that writes to production, accesses customer data, or triggers financial transactions should require human approval through the same workflow, regardless of which team deployed it or which framework it uses.
Unified audit trail
Every agent decision, every tool call, every approval or denial should flow to one audit system. When an incident occurs, you need to reconstruct the full timeline across all agents involved, not piece together logs from five different systems.
One control plane
Not one framework. One control plane. The distinction matters. Teams can keep their preferred agent frameworks. The control plane sits above the framework layer and enforces policies consistently, regardless of whether the agent runs on LangGraph, CrewAI, AutoGen, or a custom solution.
This is the architecture Cordum implements: a governance layer that evaluates every agent action against shared policies before the action executes. It works across frameworks because it operates at the tool-call boundary, not inside the agent runtime.
Step 3: Agent lifecycle governance
Agents are not static deployments. They are living systems that need ongoing management from deployment through decommissioning. Treat agent lifecycle like infrastructure lifecycle.
Deploy with policy
No agent goes to production without policy coverage. Every new agent deployment should include: an entry in the agent inventory, defined tool permissions with least-privilege scoping, an assigned approval policy, and a designated owner. If a team cannot fill in these fields, the agent is not ready for production.
Monitor behavior
Track what agents actually do, not just what they are configured to do. Monitor tool call frequency, approval rates, denial rates, and anomalous patterns. An agent that suddenly starts making 10x more API calls than usual is a signal worth investigating, even if every individual call passes policy.
Review permissions quarterly
Agents accumulate permissions over time, just like human accounts do. A quarterly review should check: Are all granted tools still needed? Are risk tags still accurate? Is the owner still active? Has the approval policy kept pace with changes in what the agent can do? Remove any access that is no longer justified.
Decommission with evidence
When an agent is retired, do not just delete the deployment. Revoke all credentials. Remove tool access. Update the inventory status to decommissioned. Keep the audit trail for compliance retention requirements. Document why it was decommissioned. This evidence trail matters for regulatory compliance and for understanding your fleet history.
Start with an audit
If this guide resonated, here is the immediate next step: answer one question.
How many AI agents does your organization have running right now?
Not how many you intended to deploy. Not how many are in your project tracker. How many are actually running, right now, with active credentials and tool access?
If you can answer that question with confidence, you are ahead of most organizations. If you cannot, that is your starting point.
- 1. Survey every engineering and operations team. Ask: "Do you have any AI agents, automations, or LLM-powered bots running?"
- 2. Cross-reference responses with API key registries, cloud IAM roles, and service account lists.
- 3. Document each agent using the inventory template above.
- 4. Tag each agent with a risk level based on its tool access and permission scope.
- 5. Prioritize governance for the highest-risk agents first.
You do not need to solve everything at once. You need visibility first, then governance for the agents that can cause the most damage, then a scalable process for everything else.
Frequently Asked Questions
What is AI agent sprawl?
How do I know if my organization has agent sprawl?
What is the difference between agent sprawl and shadow AI?
How many AI agents does a typical enterprise have?
Can I solve agent sprawl with a single framework?
What should an agent inventory include?
How does Cordum help with agent sprawl?
Where should I start if I have hundreds of ungoverned agents?
Next step
Run the agent inventory audit this week. Then read these related guides to go deeper on specific governance patterns:
- - Agentic AI Governance (2026) for a comprehensive governance framework across agent fleets.
- - Multi-Agent System Governance for policy patterns when agents interact with each other.
- - AI Agent Compliance: EU AI Act for mapping governance controls to regulatory requirements.