MCP, Tool Use, and the New Attack Surface Nobody Is Mapping

The agent wasn’t compromised.

The model wasn’t compromised.

The tool wasn’t compromised.

Every component did exactly what it was designed to do. The system still executed an action nobody authorized.

That is not a vulnerability in the traditional sense. There was no implementation flaw to patch, no misconfigured permission to revoke, no anomalous credential activity to detect. The failure occurred in the authority chain between components — in the delegation logic that connected a user request to a tool execution across three intermediate layers. And there is currently no discipline in enterprise architecture that knows how to govern that chain.

MCP — the Model Context Protocol — makes this problem structural. It introduces delegated authority chains that are longer than any governance model enterprises currently operate. Not longer by degree. Longer by category. The tools are new. The trust assumptions are new. The failure modes are new. The discipline required to govern them does not yet exist.

This is an mcp security architecture failure before it is a security tooling failure.

Framework #141 — Agentic Authority Boundary

The Agentic Authority Boundary defines the formal limit within which an agentic system may delegate execution authority — constrained by explicit scope, identity, ownership, and revocability.

Authority Chain Opacity deserves particular attention. The first three failure states describe how the boundary breaks. The fourth describes why nobody knows it broke. If the evidence record is not generated as part of execution, no amount of post-incident logging can recreate it. That is not a logging problem. It is an architecture problem — one that makes the other three failure states permanently invisible until something goes wrong at the wrong scale.

Most enterprises can answer: who made the API call? Very few can answer: which authority chain enabled the tool execution that followed?

MCP Security Architecture and the Trust Model Break

To understand why existing governance patterns fail here, the execution model needs to be visible.

Traditional systems establish authority at the perimeter and carry it forward explicitly. A user authenticates, a credential is issued, that credential travels with the request. The authority chain is short, synchronous, and inspectable at every hop. Network controls, API gateways, and identity governance all operate on this assumption.

Agentic systems break every part of that model.

The table below is not about complexity for its own sake. It is about which properties enterprise security controls were designed to govern — and which ones they were not.

The auditability row is where Authority Chain Opacity lives. In a traditional execution path, the identity and authority evidence is produced as a side effect of execution. In an agentic chain, it is not. No log of the model’s invocation captures the authority context the orchestrator was operating under. No tool server log captures which upstream delegation authorized the call. The chain ran. The action executed. The authority record was never created.

MCP accelerates this problem by standardizing the protocol through which tool servers are invoked — without standardizing any of the authority or delegation semantics. Tool servers are registered, discovered, and called through a consistent interface. What authority the calling orchestrator holds, what scope that authority covers, whether the grant is revocable, and whether any evidence of the delegation exists are all left entirely to the implementer. The protocol governs the transport. Nobody governs the trust.

Tool servers are also the new shadow IT vector. They are deployed by developers, invoked by agents, and invisible to network security teams. An engineer wires an MCP server into a workflow. The orchestrator calls it. The tool executes against systems the security team does not know are in scope. The exposure accumulates before any inventory exists to capture it.

Five Eyes Got the Threat Model Right — and Stopped There

In May 2026, the Five Eyes intelligence alliance published joint guidance on agentic AI systems. The threat model in that document is accurate: prompt injection, tool abuse, and uncontrolled agentic execution are correctly identified as the primary risk categories.

What the guidance does not provide is the architectural layer required to operationalize a response.

Identifying prompt injection as a risk does not produce a delegation inventory. Naming tool abuse as a threat does not define an authority boundary model. Recognizing that agentic risk exists does not create the governance discipline required to govern it.

The gap between the guidance and what enterprise architecture actually needs can be stated precisely. Enterprise security programs have mature disciplines for governing known risk categories:

The Five Eyes guidance identified the symptoms. Delegation governance is the discipline that would treat them. The threat model exists. The governance model does not. That is the architectural gap — and it is not filled by patching individual tool servers or tightening prompt engineering rules.

The CVE That Made This Concrete

CVE-2025-49596 carries a CVSS score of 9.4. It was active in Anthropic’s own MCP SDK. OX Security’s accompanying research documented a systemic remote code execution path in the official implementation.

The finding matters here not as a vulnerability disclosure but as a diagnostic signal about the protocol’s foundational assumptions.

Traditional vulnerabilities expose implementation flaws. A buffer overflow, an injection point, a misconfigured access control. Patch the implementation and the vulnerability closes.

MCP vulnerabilities expose authority-model flaws. The RCE path existed because the SDK’s trust assumptions about where tool server input came from — and what authority that input carried — were wrong at the specification level. The implementation was consistent with the specification. The specification was wrong about the trust model.

That distinction matters architecturally: implementation patches close the current expression of the gap. They do not close the gap. A patched SDK operating under incorrect authority assumptions remains exploitable through any future expression of the same assumption. The attack surface does not shrink when the trust model is unaddressed.

CVE-2025-49596 is not the endpoint of this analysis. It is evidence for the framework. The authority-model flaw was present before the CVE was identified. It will be present in the next implementation that inherits the same assumptions.

What Architecture Actually Needs

The controls that apply to this mcp security architecture problem map directly to the four failure states in #141.

The fourth control — evidence-grade execution records — connects directly to the operational memory problem. When an incident occurs, the question is not only what the system did. It is what the system believed it was authorized to do, and why. Infrastructure that remembers configuration but forgets intent cannot answer that question. The evidence record has to be architectural, not investigative.

Human-in-the-loop gates belong in this list, but their placement matters. Mapping approval requirements to authority elevation events — not to subjectively “sensitive” operations — gives the gates architectural meaning. An operation that elevates authority scope beyond declared boundaries requires human approval. An operation within declared scope does not. That is a governable model. “Sensitive” is not.

The Real Exposure Map

The enterprises most exposed to this attack surface are not necessarily running the most sophisticated AI deployments. They are running agentic workflows where the tool layer is not first-party.

Organizing by ownership model rather than by product makes the exposure visible:

Copilot Studio, Bedrock Agents, n8n, LangChain-based workflows, and any custom orchestration layer that consumes MCP servers from outside the organization’s own codebase sits somewhere between Medium and Extreme on this table. The organizations that fall into Extreme are often unaware of it — because dynamic tool discovery is frequently a feature, not a flag.

The maturity question that reveals actual exposure is not “what agentic tools are you running?” Most security teams can answer that. The question that matters is: can you produce an inventory of every tool your agentic systems can invoke today — including which authority scope each tool was granted, and whether those grants are revocable?

Twenty years ago, the equivalent question was: can you produce an inventory of every privileged account in your environment? That question built identity governance as a discipline. The MCP inventory question is building the case for delegation governance in the same way. Most organizations cannot answer it. That is the exposure.

Additional Resources