mediumAgent ThreatProtocol Vulnerability

MCP Execution-Layer Authorization Gap (Connection-Layer-Only Security in Agent Runtimes)

First seen Jul 5, 2026 · Updated Jul 5, 2026

MCPexecution-controlauthorizationresearchbenchmarkagent-runtimecapability-based-securitydefense-in-depthASI05 · Unsafe Code ExecutionSurface: ProtocolPropagation: None

This is an academic research paper (not an active exploit) that identifies a structural weakness in MCP-style agent runtimes: security is typically enforced only at the connection layer (auth, session checks, approval dialogs) while execution-time actions lack consistent, testable invariants like principal binding and data-flow authorization. The authors demonstrate that naive and even 'practice-informed' mitigation baselines still permit most modeled attacks, and propose a reference runtime (HCP) that blocks all 10 benchmark attack cases by enforcing explicit execution-layer controls.

Technical Analysis

The paper's core finding is that MCP-like ecosystems conflate connection-layer trust (successfully connecting to a tool/server, passing an approval dialog, OAuth handshake) with execution-layer authorization (whether a specific call, with specific data flows, should be permitted given the current principal and grants). Because metadata (tool descriptions, resource names) is treated as authoritative and approvals are session-scoped rather than call-scoped, an attacker who can influence tool metadata, resource identifiers, or reuse a session can escalate from a legitimately connected tool into unauthorized execution or data exfiltration across source/target boundaries. The authors formalize eight invariants (e.g., metadata non-authority, grant-backed approval, canonical resources, scoped capability invocation, source-and-target data-flow authorization) and show empirically that a naive runtime permits 10/10 modeled attacks and a hardened connection-layer baseline still permits 6/10, while their capability-based HCP runtime blocks all 10 and preserves audit trails. This crosses agent/tool boundaries because the gap lies precisely where an MCP client hands control to a server/tool at execution time without re-validating principal identity, resource canonicalization, or authorized data flow.

Affected Systems

MCP reference implementations, generic MCP-style connection-layer runtimes; protocols: MCP

Detection Signatures

  • Log pattern: approval granted at session start but reused across multiple distinct tool calls without per-call re-authorization
  • Metadata-derived resource identifiers used directly as authorization targets without canonicalization
  • Absence of principal-binding checks between OAuth/session identity and the invoking capability
  • Missing deny-path audit entries for rejected/blocked calls
  • Tool descriptions or resource names that differ between connection-time metadata and execution-time target (metadata/resource mismatch)

Remediation Steps

  1. 1

    Implement execution-layer authorization, not just connection-layer gating

    Deploy a policy/capability layer that re-validates every tool invocation against principal identity, grants, and canonical resource identifiers, rather than relying solely on initial connection approval or OAuth.

  2. 2

    Adopt grant-backed, scoped capability invocation

    Require explicit, narrowly-scoped grants per capability invocation instead of broad session-level approvals; avoid treating server-supplied metadata as an authorization source.

  3. 3

    Canonicalize resource identifiers before authorization checks

    Normalize and validate resource/tool identifiers server-side to prevent aliasing or metadata spoofing from bypassing access checks.

  4. 4

    Enforce source-and-target data-flow authorization

    Check both the origin and destination of data moved by a tool call, not just that the call itself was approved, to prevent unauthorized exfiltration paths.

  5. 5

    Maintain deny-path audit logging

    Ensure blocked/denied calls are logged with full context so forensic review and anomaly detection remain possible even when attacks are stopped.

  6. 6

    Benchmark MCP deployments against known invariant classes

    Use the paper's eight invariants (or equivalent test suites) to evaluate whether existing MCP servers/clients enforce execution-layer security before production deployment.

Industries Most Exposed

Software/AI infrastructureCloud servicesEnterprise SaaSFinancial servicesHealthcare (any sector deploying MCP-based agent tooling)

Sources

Respond to this threat

Pro subscribers get a full AI-generated incident-response playbook for this threat — detection, containment, eradication, and recovery steps — plus an unlimited AI Threat Advisor for questions about your environment.

View response playbook →Browse more threats