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.
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.
Four failure states define when the boundary has collapsed:
Failure 01 — Scope Creep Delegation
Tool invoked outside its intended authority range. No declared scope boundary exists to prevent it.
Failure 02 — Implicit Trust Inheritance
Tool server assumes the orchestrator's identity without challenge. The tool cannot distinguish a legitimate call from an injected one operating under inherited credentials.
Failure 03 — Non-Revocable Grant
No mechanism exists to constrain authority once delegation is established. The grant persists until something is redeployed.
Failure 04 — Authority Chain Opacity
No evidence artifact exists that allows reconstruction of authority movement after execution. This is not a logging problem — it is an architecture problem. If the evidence record is not generated at execution time, no post-incident logging can recreate it.
Authority Chain Opacity is the forensic-failure state. The other three failure states describe how the boundary breaks. This one describes why nobody knows it broke.
Most enterprises can answer: who made the API call? Very few can answer: which authority chain enabled the tool execution that followed?
What MCP Does to Your Trust Model
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.
Agentic systems break every part of that model:
| Property | Traditional Execution | Agentic Execution |
|---|---|---|
| Identity | Visible at every hop | Indirect — inherited by orchestrator |
| Authority | Explicit — carried with credential | Delegated — passed through chain |
| Ownership | Clear — defined at service boundary | Distributed — often undefined |
| Auditability | Native | Often missing — chain is implicit |
MCP standardizes the protocol through which tool servers are invoked — without standardizing any of the authority or delegation semantics. The protocol governs the transport. Nobody governs the trust.
Tool servers are also the new shadow IT vector. Deployed by developers, invoked by agents, invisible to network security teams. The exposure accumulates before any inventory exists to capture it.
Five Eyes Got the Threat Model Right — and Stopped There
The May 2026 Five Eyes joint guidance on agentic AI correctly identifies prompt injection, tool abuse, and uncontrolled agentic execution as the primary risk categories.
What it does not provide is the architectural layer required to operationalize a response.
Enterprise security programs have mature disciplines for known risk categories:
| Existing Discipline | Governs |
|---|---|
| Identity Governance | Who can act |
| Network Governance | Where traffic flows |
| API Governance | What interfaces expose |
| Policy Governance | What is permitted |
| Delegation Governance | How authority moves — missing |
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.
The CVE That Made This Concrete
CVE-2025-49596 (CVSS 9.4) was active in Anthropic's own MCP SDK. OX Security documented a systemic RCE path in the official implementation.
Traditional vulnerabilities expose implementation flaws. Patch the implementation, close the vulnerability.
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 it carried — were wrong at the specification level. The implementation was consistent with the specification. The specification was wrong about the trust model.
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.
What Architecture Actually Needs
Controls mapped directly to the four failure states in #141:
Scope Creep Delegation → Authority Declarations
Tool servers must declare explicit authority scope at registration — not a capability list, an authority boundary. Invocations outside declared scope require explicit elevation, not default-permit.
Implicit Trust Inheritance → Identity Isolation
The orchestrator's credential must not transit into tool execution context. Tool servers authenticate the invocation, not the upstream identity.
Non-Revocable Grant → Revocable Delegation Scopes
Delegation grants must carry explicit expiration and revocation paths. A tool server registration that cannot be revoked without redeployment is a permanent grant with a protocol wrapper.
Authority Chain Opacity → Evidence-Grade Execution Records
Every tool invocation must generate a record capturing: the delegation chain, the authority scope active at invocation time, the identity context at each layer, and the output produced. Generated at execution time — not reconstructed afterward.
Human-in-the-loop gates belong here too, but placement matters. Map approval requirements to authority elevation events — not to subjectively "sensitive" operations. An operation that elevates authority scope beyond declared boundaries requires human approval. "Sensitive" is not a governable model. Authority scope is.
The Real Exposure Map
| Exposure Tier | Tool Ownership Model | Authority Boundary Condition |
|---|---|---|
| Low | First-party tools only | Boundary is organizational — auditable through existing controls |
| Medium | Internal tools + external connectors | Partial — connectors introduce implicit trust inheritance |
| High | Third-party MCP ecosystem | Authority declarations missing or unverifiable |
| Extreme | Dynamically discovered tools | No static inventory possible — authority chain unknown until execution |
Copilot Studio, Bedrock Agents, n8n, and LangChain-based workflows consuming external MCP servers sit between Medium and Extreme. Organizations at Extreme often don't know it — dynamic tool discovery is frequently a feature, not a flag.
The question that reveals actual exposure: 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. This one is building the case for delegation governance in the same way. Most organizations cannot answer it. That is the exposure.
Architect's Verdict
MCP introduces a trust delegation model that enterprise architecture has no existing governance pattern for. The protocol is not the problem. The absence of the discipline required to govern what the protocol enables is the problem.
Every existing security control was designed for systems where the execution boundary is visible at the network or identity layer. MCP makes the execution boundary implicit, dynamic, and trust-inherited across a chain of intermediate systems. Identity governance tells you who authenticated. API governance tells you what was called. Neither tells you how authority moved from a user request through a model, through an orchestrator, into a tool that executed against production systems.
Delegation governance is the missing discipline. CVE-2025-49596 is not the reason to build it — it is evidence that the absence of it was already being exploited before the absence had a name. The attack surface is live. The inventory does not exist. The authority chains are running. Nobody is mapping them.
Originally published at rack2cloud.com