Agent Tool Sprawl

Defining Agent Tool Sprawl

Agent tool sprawl refers to the unmanaged expansion of tools, APIs, and MCP servers that AI agents are able to invoke, beyond what any individual team tracks or intends. It is distinct from general software sprawl because the access point is not a human user account but an agent identity, often with standing credentials and the ability to chain tool calls autonomously.

OWASP's Top 10 for LLM Applications names this condition Excessive Agency, defined as a system granted more functionality, permissions, or autonomy than its intended task requires. Tool sprawl is the infrastructure-level manifestation of that risk: it shows up as agents with reachable tool endpoints that no one is actively reviewing, MCP servers deployed by different teams exposing overlapping functionality, and API keys with broader scope than any single workflow uses. The result is an attack surface that grows without a corresponding increase in oversight.

Why Tool Access Expands Without Central Control

Tool sprawl is rarely the product of one bad decision. It accumulates through many reasonable, incremental choices made by separate teams. A team building a support agent connects it to a ticketing API. A data team stands up an MCP server for internal analytics. A third team reuses an existing integration for a new agent because it already works, without revisiting whether the original scope still applies.

None of these decisions is registered against a shared inventory, so the organization loses track of which agents can reach which tools. The Model Context Protocol's own documentation acknowledges this challenge directly: as organizations connect more MCP servers, tracking which servers expose which tools and resources to which clients becomes a discovery and governance problem in its own right. Because MCP's authorization guidance recommending OAuth 2.1 is optional rather than mandatory, third-party and community-built servers frequently ship without enforced access controls, compounding the visibility gap.

Contributing Factors

Several recurring patterns drive tool sprawl across organizations:

Technical and Operational Consequences

The core technical implication is blast radius. When permissions are granted at a coarse level, such as full API scope rather than a specific method or resource, a compromised or misconfigured agent can act far beyond its intended function. MITRE ATLAS catalogs unauthorized tool invocation and excessive permission grants as recognized attack techniques against agentic systems, meaning this is not a theoretical concern but a documented threat pattern.

Operationally, the absence of tool-call level logging, distinct from agent-response logging, means most organizations cannot answer a basic audit question: which agent called which tool, with what parameters, at what time. Without that data, permission reviews rely on team memory and documentation that is often out of date. Redundant MCP servers add a second cost beyond security exposure: duplicated maintenance burden for functionally identical capabilities deployed by different teams.

Governance and Ownership

NIST's AI Risk Management Framework Generative AI Profile places tool and plugin inventory under its Map and Govern functions, which implies assigning explicit ownership for third-party integration risk rather than leaving it to whichever team first connected a tool. CISA's guidelines on secure AI system development recommend maintaining an inventory of AI system components, including connected tools and third-party integrations, as a baseline control.

Organizations should document the intended scope of each agent's permissions and treat any deviation from that scope as a policy violation requiring review, consistent with OWASP's framing of Excessive Agency. No sprawl-specific regulation currently exists, so these obligations are best understood as extensions of general AI governance and zero-trust guidance rather than a distinct compliance regime.