AI agent sprawl is not primarily a tool-count problem.
It is an enterprise authority problem.
An agent is not simply another application. It can carry an identity, hold permissions, access data, invoke tools, call APIs, create or modify records, communicate with customers, commit code, trigger payments, and make decisions inside operating workflows. When these capabilities spread faster than governance, the enterprise is not merely accumulating software. It is distributing decision rights to digital workers without a coherent management model.
Gartner predicts that an average global Fortune 500 enterprise could move from fewer than 15 agents in 2025 to more than 150,000 by 2028. The number is dramatic, but the more important warning sits underneath it: most enterprises do not yet have the inventory, identity model, runtime controls, evidence trail, or ownership structure required to manage machine action at that scale.
The strategic question is therefore not how many agents the enterprise can deploy.
It is whether every agent can be identified, bounded, observed, challenged, stopped, and held to an accountable business purpose.
The Real Issue
Enterprise AI adoption is becoming decentralized by design.
Agents are being introduced through cloud platforms, productivity suites, customer applications, developer tools, workflow systems, low-code environments, integration platforms, business SaaS products, robotic process automation, and custom engineering teams. Some are formally commissioned. Others are assembled by employees who can connect a model to enterprise data and tools in a few hours.
This changes the nature of shadow IT.
A shadow application may store data or automate a task. A shadow agent can interpret an objective, choose a sequence of actions, invoke multiple systems, and continue operating without a person approving every step. It may act through a human account, a shared API key, a service identity, an OAuth token, a browser session, a model gateway, an API gateway, an MCP server, or a chain of delegated agents.
The result is not just technology fragmentation. It is a shadow operating model.
The enterprise may no longer know:
- which agents exist;
- who owns them;
- which business outcome they serve;
- what data they can see;
- which actions they can execute;
- what other agents they can delegate to;
- what permissions they inherited;
- what they cost to operate;
- whether their behavior has changed;
- or who is accountable when they act incorrectly.
Traditional control systems each see only part of this picture.
Identity platforms see accounts and credentials, but not always the agent’s purpose or decision path. API gateways see calls, but may not know which human sponsor, task, model, or approval state sits behind the call. Security monitoring sees events, but may struggle to reconstruct why an agent chose a sequence of individually permitted actions. FinOps tools see consumption, but not whether the spend produced a trusted business outcome. Application inventories see systems, but not the growing population of agents configured inside them.
Agent sprawl emerges in the gaps between these control domains.
Why The Usual Approach Falls Short
The first common response is prohibition.
Leaders attempt to block unsanctioned tools, restrict low-code development, or require every experiment to pass through a central team. This can reduce immediate exposure, but it rarely removes demand. Business teams route around controls when the approved path is too slow, too narrow, or disconnected from the work they are trying to improve.
The second response is platform consolidation.
The enterprise selects a strategic AI vendor and assumes that standardizing the model, copilot, or agent platform will solve governance. It will not. Agents will still emerge inside SaaS applications, developer environments, integration tools, cloud services, endpoint automation, and partner ecosystems. A single platform may reduce some variation, but it does not eliminate the multi-platform, multi-cloud, and multi-gateway reality of a modern enterprise.
The third response is uniform governance.
Every agent is forced through the same approval process and control set. This is administratively simple but operationally weak. A read-only summarization agent does not require the same controls as an autonomous agent that can modify production configurations or release payments. Over-governing low-risk use cases slows adoption and encourages shadow development. Under-governing high-autonomy agents creates unacceptable exposure.
The fourth response is static access.
Agents are given permanent service accounts, broad OAuth scopes, reusable API keys, or inherited human permissions because these mechanisms are familiar. The access often remains after the original workflow changes, the owner leaves, the agent is replaced, or the business need disappears. Permanent machine authority becomes the residue of experimentation.
The fifth response is demo-led assurance.
An agent completes a task successfully in a controlled environment, so the enterprise treats it as production-ready. But demonstrations rarely test prompt injection, poisoned context, tool misuse, privilege escalation, approval fatigue, recursive delegation, conflicting instructions, excessive retries, silent data leakage, or failure under changing operating conditions.
A successful demo proves that an agent can act.
It does not prove that the enterprise can govern the action.
What Leaders Should Pay Attention To
1. Treat Every Agent As A Managed Enterprise Entity
An agent should not enter production without an enterprise record.
That record should function as an agent passport. It should include a unique identity, named business owner, technical owner, purpose, risk tier, model and platform dependencies, data domains, approved tools, permitted actions, autonomy level, human approval requirements, cost limit, review date, expiry condition, rollback method, kill switch, and required evidence.
This is more than inventory.
It establishes the minimum information needed to assign responsibility, enforce policy, and make lifecycle decisions.
The registry must also discover agents that were not formally registered. Sanctioned inventory without shadow discovery creates false confidence.
2. Govern Autonomy And Authority Separately
An agent’s ability to decide and its ability to act are different dimensions.
A highly capable agent with read-only access may present less operational risk than a simpler agent with permission to update customer accounts, deploy code, or approve a transaction. Governance should therefore classify agents using at least two axes:
- Autonomy: observe, advise, act with approval, or act autonomously.
- Authority: the data, systems, transaction values, environments, and consequences the agent can reach.
The control level should rise when either autonomy or consequence rises.
This avoids a binary choice between fully trusted and fully blocked agents. It also makes governance proportionate enough to remain usable.
3. Replace Permanent Permissions With Task-Bound Authority
Machine access should be short-lived, purpose-bound, and revocable.
An agent should receive the minimum capability required for a specific task, for a defined duration, under a known sponsor and policy. Credentials should expire automatically. Delegated authority should become narrower as it passes from a human to an agent and from one agent to another.
The practical shift is from standing permission to ephemeral authority.
That means moving away from shared API keys and long-lived service credentials toward workload identity, short-lived tokens, just-in-time access, transaction-level scopes, and explicit delegation chains.
The enterprise should be able to answer not only, “Which identity made this call?” but also:
On whose authority, for which task, under which policy, with what remaining scope, and until when?
4. Build A Federated Control Plane Across The Multi-Gateway Estate
Most enterprises will not govern agents through one gateway.
They already operate a fragmented enforcement estate that may include:
- external and internal API gateways;
- model gateways;
- MCP gateways and tool servers;
- service meshes;
- identity and privileged-access platforms;
- integration and iPaaS environments;
- SaaS connector controls;
- cloud control planes;
- data access layers;
- endpoint and browser automation;
- and workflow platforms.
Replacing all of these with one product is neither practical nor necessary.
The stronger architecture is a logically centralized control plane with physically distributed enforcement.
The control plane should maintain a canonical agent identity, registry, risk tier, policy model, approval state, and telemetry schema. Existing gateways and platforms should act as policy enforcement points. They should evaluate the same core context before allowing an action and return normalized evidence after execution.
Every material agent request should carry a verifiable context envelope containing:
- agent identity;
- human or business sponsor;
- task and workflow identifier;
- requested capability;
- data classification;
- risk tier;
- approval state;
- policy version;
- expiry;
- and cost or transaction limit.
This context should survive identity translation and gateway hops. Otherwise, the enterprise may authenticate the technical caller while losing the business authority behind the action.
The objective is not one gateway.
It is one governance truth across many gateways.
5. Observe Decision Paths, Not Only API Traffic
Traditional monitoring focuses on events: a login, a query, an API call, a data transfer, a configuration change.
Agent governance must also preserve the path between intent and action.
The enterprise needs an evidence chain that can reconstruct:
- the original objective;
- the context the agent received;
- the policy in force;
- the tools considered;
- the action proposed;
- the approval obtained;
- the action executed;
- the result returned;
- the retries and exceptions;
- and the subsequent agent or human decision.
This does not mean storing every hidden reasoning token. It means capturing enough structured evidence to explain and audit the operating sequence.
A technically permitted action can still be inappropriate when it is part of an unsafe sequence. Runtime governance must therefore evaluate paths, thresholds, and cumulative behavior, not only isolated requests.
6. Make Cost A Runtime Control
Agent economics can deteriorate quietly.
An agent may loop, call expensive models unnecessarily, duplicate work across tools, retry failed actions, generate excessive context, or create downstream review demand that costs more than the automation saves.
Cost governance should not stop at monthly model spend.
Each agent should have operating budgets linked to tasks and outcomes: token limits, tool-call limits, execution duration, retry ceilings, transaction values, exception rates, and human-review load. The system should slow, downgrade, route, or stop an agent when thresholds are exceeded.
The useful metric is not cost per agent.
It is cost per accepted, trusted outcome.
7. Red-Team The Operating System Around The Agent
Agent assurance is broader than model testing.
Red-teaming should test the complete chain: model, instructions, memory, retrieval, tools, identities, APIs, approval workflows, delegation, data handling, monitoring, and incident response.
Scenarios should include malicious input, poisoned documents, compromised tools, conflicting policies, prompt injection, privilege escalation, data exfiltration, approval fatigue, agent-to-agent manipulation, runaway loops, and failure of upstream or downstream systems.
The test is not whether the agent behaves perfectly.
The test is whether the control environment detects, contains, explains, and recovers from imperfect behavior.
The Operating Implication
AI agent governance cannot be assigned to one function.
The CIO should own the enterprise control architecture and ensure that agent adoption remains connected to operating priorities. The CISO should define identity, access, security testing, monitoring, and response requirements. Data owners should determine which information domains an agent may access and under what conditions. Business executives should remain accountable for the outcomes of agents operating inside their processes. Platform and engineering teams should implement the common control plane and distributed enforcement. Risk, compliance, and internal audit should test whether evidence and accountability hold under real operating conditions.
The key principle is simple:
Human accountability cannot be delegated to a machine.
A business owner may delegate execution to an agent. The organization may allow the agent to act autonomously inside defined boundaries. But ownership of purpose, consequences, and remediation remains human.
This should be reflected in decision rights.
Every production agent needs a named executive or process owner who can answer three questions:
- Why does this agent exist?
- What is it allowed to decide and do?
- What happens when it is wrong?
Without those answers, the enterprise has deployed capability without accountability.
The NetworkGain View
The enterprise AI strategy is not failing because organizations lack access to advanced models.
It is failing when adoption moves faster than the operating model required to govern machine action.
The agent count is therefore the wrong measure of progress.
A company with 10,000 poorly governed agents is not more AI-native than a company with 100 agents that are tied to clear business outcomes, bounded authority, verifiable execution, and accountable ownership. Quantity can create activity. It does not create trusted execution.
NetworkGain’s view is that the enterprise needs an agent control model, not merely an agent platform.
That model should connect five layers:
- Business intent — the outcome, owner, process, and decision rights.
- Agent identity — a unique, attestable identity with lifecycle and delegation context.
- Authority and policy — proportionate permissions, data boundaries, approvals, budgets, and stop rules.
- Distributed enforcement — consistent controls across APIs, models, tools, gateways, clouds, SaaS, and workflows.
- Execution evidence — an auditable chain from objective to action to outcome.
This is the control fabric that allows innovation to scale without turning autonomy into unmanaged authority.
The important architectural choice is not centralization versus decentralization.
It is centralized governance truth with decentralized execution.
Business teams should be able to build and improve agents close to the work. But they should do so inside an enterprise frame that makes every agent discoverable, every permission temporary, every high-impact action governable, every cost visible, and every outcome accountable.
What To Do Next
CIOs do not need to wait for the agent population to explode.
The next 90 days can establish the control foundation.
Days 1-30: Discover And Define
Create a cross-enterprise inventory covering sanctioned and shadow agents. Define what qualifies as an agent. Establish the agent passport. Map current gateways, tool protocols, service identities, low-code environments, SaaS connectors, and agent-building platforms. Identify high-impact workflows where machine action already exists.
Do not begin with a blanket shutdown.
Begin by making the estate visible.
Days 31-60: Classify And Constrain
Adopt a proportional risk model based on autonomy and authority. Assign owners. Remove shared credentials where possible. Introduce expiry dates, short-lived access, approval requirements, transaction limits, and kill switches for higher-risk agents. Define the minimum evidence required for each risk tier.
Do not treat all agents equally.
Treat them according to what they can decide, reach, and change.
Days 61-90: Prove The Control Plane
Select two or three production workflows that cross multiple gateways or platforms. Implement a canonical agent identity and context envelope. Federate policy enforcement across the relevant API gateway, identity layer, model gateway, MCP or tool layer, and workflow system. Normalize telemetry into one decision-action evidence trail. Test revocation, rollback, policy change, cost thresholds, and incident response.
Do not start by buying a universal control product.
Start by proving that governance truth can survive a real multi-gateway execution path.
The future of enterprise AI will not be determined by who deploys the largest population of agents.
It will be determined by who can govern machine authority without losing execution speed.
An agent should never be invisible, permanently privileged, economically unbounded, or operationally ownerless.
That is the standard CIOs must establish before agent sprawl becomes enterprise control failure.
Research Note
This perspective draws on Gartner’s April 2026 forecast and governance guidance on AI agent sprawl, Gartner’s May 2026 proportional autonomy model, NIST’s 2026 work on software-agent identity and authorization, and OWASP’s 2026 agentic application and red-teaming guidance.