AI Asset Sprawl as an Attack Surface Expansion Vector

Security teams built their entire discipline around a simple unit of risk: the application. You find it, you inventory it, you decide who gets access, and you watch that access relationship stay roughly fixed until someone changes it by hand. AI asset sprawl breaks that model at its foundation. Every unmanaged AI asset is an autonomous identity, capable of acting on its own, with access relationships that shift on their own schedule, not the schedule security teams set.

A shadow SaaS app has one fixed identity and one access relationship. It sits where IT put it, or where an employee signed up for it, and it stays there. An AI agent does not stay put. It can spawn child agents, generate new credentials, and call tools across multiple systems, all inside a single workflow.

A shadow SaaS app has one fixed identity and one access relationship, but an AI agent can spawn child agents, create new credentials, and invoke tools across multiple systems in a single workflow. Gravitee.io's research found that 25.5% of deployed agents can autonomously create and task further agents. Any security leader needs to rethink asset counts because of that number alone. It means the count is never static. Each new agent does not simply add one more item to a list; it multiplies the number of access relationships already in play, so the attack surface grows combinatorially rather than linearly. They are a branching structure of credentials, tool calls, and trust relationships that outpaces any inventory built for fixed applications.

The problem compounds because much of this sprawl is not even the result of deliberate adoption. Gravitee.io and Grip Security's Mid-Year AI Exposure Update both found that most enterprise applications now carry AI functionality that arrives automatically through routine product updates. Organizations are acquiring AI identities they never consciously chose to adopt. A vendor ships a feature update, and suddenly there's a new autonomous actor operating inside the environment, with its own access to data and systems, and nobody ran an approval process because nobody knew there was anything to approve.

This is the premise the rest of this analysis rests on: AI asset sprawl is a different kind of problem than the ones security teams already know how to solve, built around identities that act and multiply rather than applications that sit still.

The Model Context Protocol as connective tissue of enterprise attack surface

The Model Context Protocol, or MCP, is the standard that lets AI models discover and call external tools, and it has become the backbone connecting agents to the rest of the enterprise stack. AgentMelt's 2026 MCP security analysis describes the structural shift directly: traditional API integrations expose functions, but MCP servers expose tool definitions that the model itself reads and reasons about, which makes the descriptions attack surface in their own right, not just the endpoints behind them. A conventional API either lets you call a function or it doesn't. An MCP tool description is text the model interprets, and text can be made to say things a function signature never could.

MCP's risk profile differs from the API integrations that came before it in three design properties. Discovery is dynamic: an MCP server can add, remove, or silently change its tool list after a client has already connected to it. A tool approved today can carry a malicious payload tomorrow, with no new approval event triggered anywhere in the system.

Blast radius is additive rather than contained. An agent connected to multiple MCP servers inherits the union of every one of those servers' permissions, so a single poisoned server can leverage access that was only ever meant to belong to the others.

The protocol also inverts the trust model security architects have relied on for decades. In a conventional client-server relationship, the client asks and the server answers. The SaaS Library analysis notes that the NSA flagged this inversion directly: MCP servers act autonomously on the client's behalf, feeding new instructions back into the model's next decision. Conventional API threat models can't trace these attack paths, because they assumed the server was a passive responder, not an active participant shaping what happens next.

Cisco's State of AI Security 2026 Report called MCP the "connective tissue" of the AI ecosystem, and warned that its vulnerability "has created a vast and often unmonitored attack surface," since connective tissue is what makes a body function and what lets an injury in one place affect everything attached to it.

What makes all of this urgent rather than theoretical is speed. AgentMelt documents that MCP went from an Anthropic-only specification in November 2024 to being shipped across Claude, ChatGPT, Gemini, Cursor, VS Code, JetBrains, and Zed by mid-2026, with the official registry crossing 10,000 servers in that same span. At that pace, security review of each new server becomes structurally impossible without automated governance built into the pipeline itself. No team of human reviewers was ever going to keep up with ten thousand servers arriving across a year and a half.

The governance gap the sprawl has already opened

Enterprises deployed AI agents far faster than they built the infrastructure to govern them, and that gap is the current operating condition, not a rounding error. Most of the agent estate inside large organizations today runs unmonitored, and most organizations still have no coherent strategy for treating agents as the distinct identity category they actually are.

The Gravitee.io State of AI Agent Security 2026 report surveyed 750 senior technology leaders across the UK and USA, and it puts numbers to that gap. Nearly every enterprise surveyed already uses AI agents. Only a small fraction of them have a centralized governance platform in place to manage those agents. That mismatch alone describes an industry that adopted the technology before it built the controls for it.

Only a small minority of organizations treat AI agents as distinct, identity-bearing entities with their own bounded access rights. Most still rely on shared API keys for agent-to-agent communication. Shared keys erase the boundary between agents, so when something goes wrong, nothing in the credential itself can show which agent did what.

None of this is closing on its own. In 2026, the barrier to building an agent has dropped below the barrier to detecting one. A developer can stand up a new agent faster than a security team can notice it exists. That creation-to-governance lag is a structural feature of how agents get built and deployed right now, not a temporary oversight that better tooling will quietly fix next quarter, and it will keep widening until governance infrastructure catches up to deployment speed.

Part of that lag traces back to the protocol doing the connecting. The governance gap is also a product of what the MCP specification itself chooses to mandate, and what it leaves entirely optional, not just an organizational failure of discipline or budget.

What the MCP specification does and does not enforce

MCP's specification requires some security properties outright and leaves others as implementation choices, and the gaps in what it mandates line up closely with the gaps that 2026's most significant attacks exploited.

Where authorization is implemented, the spec does require real security controls. It requires OAuth 2.1 with PKCE for HTTP transports. It requires that all authorization server endpoints be served over HTTPS, and that all redirect URIs be either localhost or use HTTPS. It requires that authorization server metadata be discoverable by clients, and that Protected Resource Metadata under RFC 9728 be exposed. It also requires validation of Resource Indicators under RFC 8707, so token audience confusion can't happen. And it explicitly forbids token passthrough: an MCP server must not simply forward a client's inbound token to an upstream API. If a server needs to call an upstream service, it has to obtain its own separate token from that upstream authorization server.

That's a real list of requirements, and organizations that implement them close off several entire categories of exploit. But the list of what the spec leaves unstandardized is just as consequential. Tool-level role-based access control isn't defined. Approval workflows and human-in-the-loop review queues aren't defined. Audit-record schemas, credential isolation between tools, and SIEM export formats aren't defined either. None of these exist in the core spec. Every one of them has to be built by whoever implements the protocol. Their presence or absence varies server to server, vendor to vendor, with no baseline a security team can assume.

This reflects a protocol built to standardize connectivity first, with security maturing around it afterward, rather than a flaw introduced by careless spec authors. But it means enterprises adopting MCP are adopting a foundation with known, documented gaps, and protocol compliance alone cannot stand in for a security posture. Attackers are already finding those exact gaps.

The attack classes MCP's design gaps enable

Dynamic tool discovery, optional authentication, and a model's inherent trust in whatever a tool description tells it have together produced a distinct set of attack techniques, and conventional API security tools were never built to catch them.

Tool poisoning is the dominant class. A malicious or compromised MCP server can hide instructions inside a tool's description text. The model reads that description with the same trust it extends to its own system prompt, acts on the hidden directive, and still returns a response to the user that looks entirely normal. AgentMelt documents the Invariant Labs proof-of-concept that made this concrete: a hidden instruction buried inside a simple_calculator tool's description quietly read SSH keys and MCP configuration files. The attack worked because the client never surfaced the tool's full description to the user in the first place.

Cross-server tool shadowing works differently, but it lands in the same category of invisible harm. In Invariant Labs' May 2025 demonstration against a GitHub MCP server, an attacker hid a malicious instruction inside a public GitHub issue. When an agent with an active GitHub MCP session read that issue, it opened the user's private repositories and leaked their contents into a public pull-request comment on the attacker's own repository. The GitHub server itself was never compromised. The agent's combined session scope, the union of everything it had permission to touch, was the actual attack surface. That's the additive blast radius described earlier, now shown as a working exploit rather than a design concern on paper.

Credential aggregation turns a single compromised server into a master key. Because one MCP server often holds credentials for several systems at once, Wiz Research's disclosure found flaws in the Amazon Q VS Code extension that let a malicious repository achieve arbitrary code execution and steal cloud credentials, through nothing more than a crafted workspace MCP configuration file. The spawned MCP server processes inherited the developer's full environment, credentials included. Compromise one server under that design, and every system it holds credentials for is breached along with it.

Agentjacking shows that explicit defenses don't hold up well on their own. Tenet Security's research into Sentry's MCP event injection found that agentjacking bypassed explicit anti-injection instructions in the vast majority of cases tested. Sentry declined to remediate the underlying issue and deployed only a payload-string filter in response, a mitigation that addresses the symptom rather than the mechanism.

The deepest of these issues is at the SDK level, in the software libraries used to build MCP servers in the first place. OX Security's advisory, titled "Mother of All AI Supply Chains," found that Anthropic's official MCP SDKs for Python, TypeScript, Java, and Rust all pass command strings directly to subprocess calls without sanitizing them. Any application built on top of these SDKs inherits that flaw automatically. Anthropic's response was that the behavior is intentional, and that sanitization is the responsibility of whoever builds the client. As of July 2026, 14 CVEs have been assigned to MCP implementations, hundreds of thousands of servers are estimated as potentially compromisable through this SDK flaw, and hundreds of MCP servers have been independently scored for security risk, a crack running through the foundation that much of the MCP ecosystem is built on top of.

Real incidents expanding the attack surface in practice

These are not hypothetical categories waiting to be exploited someday. Gravitee.io's State of AI Agent Security 2026 report found that 88% of enterprises have already had an AI agent security incident. That figure turns everything in the preceding sections from a taxonomy of possible attacks into a description of what's already happening inside production environments.

The incidents documented above aren't isolated anomalies, either. They trace a single pattern: a governance gap opens because agents multiply faster than oversight can track them, MCP's design gaps give attackers a concrete mechanism to exploit that gap, and the result lands as a real breach inside a real enterprise. Tool poisoning hid commands inside a calculator's description, and it read private SSH keys. A GitHub issue, never touching the GitHub server itself, leaked private repositories into a public comment. A crafted configuration file inherited a developer's entire credential set. An injection technique beat explicit anti-injection safeguards in most of the tests run against it. Each of these started as a specific, narrow flaw. Each one ended by giving an attacker leverage far beyond the single tool or server where the flaw lived.

At 88% of enterprises already reporting an incident, the sprawl described at the start of this piece has already converted into measurable organizational harm. The identities multiplying without inventory, the blast radius spreading across every connected server's combined scope, the SDK flaw sitting underneath hundreds of thousands of servers: none of it is a future risk to plan around eventually. It's the shape of the attack surface enterprises are operating inside of right now.