PaperlayerView exact revision on arXiv

Source-linked AI summary

ACLE-MCP: Attested Capability Leases for Execution-Time Trust in Remote LLM Tool Use

Zhiyang Ding, Yang Luo, Guangpu Chen, Qingni Shen, Zhonghai Wu

arXiv:2609.02690v1cs.CR

TL;DR

OAuth authorization alone does not establish that a later tool call executes on the expected, freshly appraised provider workload. ACLE-MCP binds invocation authority to workload appraisal and admits calls immediately before protected execution; evaluations show it blocks all evaluated attack families while preserving benign tasks.

  • Problem

    OAuth authorization does not establish that a later call executes on the expected, freshly appraised provider workload, leaving an execution-time trust gap in remote MCP tool use.

    Source: Introduction · p. 1, Post-Authorization Execution Trust Gap · p. 2

  • Method

    ACLE-MCP issues short-lived, sender-constrained leases binding workload appraisal and invocation constraints, which a provider-side gate consumes immediately before protected tool logic.

    Source: Introduction · p. 2, Design Overview · p. 3

  • Results

    The complete design achieved a 100% blocking rate over attacks expected to be denied and preserved evaluated benign tasks.

    Source: RQ2: Ablation Study and Mechanism… · p. 6, Conclusion · p. 7

  • Takeaways & Limitations

    ACLE-MCP is a reference-monitor architecture for the post-authorization execution trust gap, not a complete trust framework for agentic systems.

    Source: Discussion · p. 7

    Evaluation covers four benign and six author-constructed misuse families; sender proof and workload appraisal are simulated in the main harness, so evidence demonstrates prototype-level feasibility rather than production readiness.

    Source: Discussion · p. 7

Abstract

from arXiv · show

Remote Model Context Protocol (MCP) services enable large language model agents to invoke external tools, but OAuth authorization alone does not ensure that a later tool call is executed by the provider-side workload that the relying party intended to trust. An endpoint may remain authorized even after execution shifts to a substituted workload, relies on stale appraisal state, reuses authority transferred from another sender, or traverses an undeclared downstream component. We call this problem the post-authorization execution trust gap. We present ACLE-MCP, an invocation-scoped architecture that couples delegated authorization, workload appraisal, and resource-side execution admission. For protected calls, ACLE-MCP issues a short-lived, sender-constrained capability lease that binds the expected workload, freshness requirement, operation, object and parameter bounds, downstream constraints, and receipt obligations. A provider-side Execution Gate consumes the lease immediately before protected tool logic begins. We implement a runnable prototype with Keycloak/OIDC validation, an MCP Python SDK server, and an optional vTPM quote-verification backend. Controlled security experiments and an agent tool-use extension show that weaker authorization or connect-time attestation modes leave distinct post-authorization attacks open, whereas full ACLE-MCP blocks all evaluated attack families while preserving all benign tasks. In the locally simulated agent extension, the complete design increases request-level pooled p95 latency on normal allowed calls by 25.7% relative to OAuth-only. These results indicate that invocation-time binding between call authority and current workload state is a practical complement to OAuth-protected remote tool use.

Introduction

ACLE-MCP addresses the post-authorization execution trust gap: OAuth authorization alone does not ensure that a tool call is executed by the expected, freshly appraised provider workload. It binds authorization, workload appraisal, sender proof, and resource-side admission at invocation time.

Introduction

  • Valid OAuth authorization does not ensure that a later call reaches the expected, freshly appraised workload or prevent routing through an undeclared proxy or reuse of another sender’s lease.The central question is whether the authorized call is executed by the intended workload within the bounds of its additional authority.Source: Introduction · pp. 1–2
  • Existing defenses cover adjacent boundaries but lack invocation-scoped binding among OAuth context, current workload appraisal, caller sender proof, and admission at execution.Prompt-injection defenses and plan validators act before remote execution; OAuth does not appraise the consuming workload, sender constraints do not prove its current state, and connect-time attestation can become stale.Source: Introduction · p. 1
  • ACLE-MCP issues a short-lived, sender-constrained lease binding OAuth context and workload appraisal to invocation scope, freshness, downstream constraints, and receipt obligations.A Verifier appraises target-workload evidence; the issuer combines the result with OAuth context, and a provider-controlled Execution Gate consumes the lease immediately before protected logic begins.Source: Introduction · pp. 1–2
  • The prototype separates Verifier, lease issuer, gate, and tool services, validates Keycloak/OIDC tokens, and forwards admitted requests to an MCP Python SDK Server.An optional swtpm/tpm2-tools backend uses nonce-bound quote verification while preserving the same appraisal-result, lease, and gate interfaces.Source: Introduction · p. 2
  • The evaluation implements five enforcement modes and covers replay, workload substitution, stale appraisal, scope misuse, undeclared proxying, receipt violations, and chained and streaming agent tool use.The agent scenarios extend the analysis without redefining the core security problem.Source: Introduction · p. 2

Security Problem

OAuth authorization confirms that a client may access an audience, but does not establish that the expected workload, its acceptable state, and fresh appraisal hold when a tool executes. ACLE-MCP frames admission as requiring delegated access and current workload trust together, while confining authority to its approved scope.

Post-Authorization Execution Trust Gap

  • OAuth alone does not establish expected workload identity, acceptable appraised state, or fresh evidence at execution; admission also bounds operation, object, parameters, side effects, and downstream path.The guarantee does not prove arbitrary tool semantics or infer latent user intent.Source: Post-Authorization Execution Trust Gap · p. 2

Attack Classes and Security Goals

  • The attack classes are credential replay or transfer, workload substitution, stale appraisal, invocation-boundary misuse, undeclared delegation, and missing or forged receipts.Chained, reordered, repeated, and streaming agent workflows test how invocation-scoped authority might be reused or widened.Source: Attack Classes and Security Goals · p. 2

Threat, Trust, and Policy Model

  • The adversary may influence the MCP-facing workload or a legitimate-looking proxy, replay credentials, broaden arguments, reuse authority, or forward execution to undeclared dependencies (OWASP Foundation 2025; National Institute of Standards and Technology 2024; National Vulnerability Database 2025; JFrog Security Research 2025; Endor Labs 2026).Source: Threat, Trust, and Policy Model · p. 2
  • The Host’s boundary logic, Verifier, lease issuer, and non-bypassable provider Execution Gate are trusted; compromised or misconfigured application workloads are not.The guarantee excludes alternate paths around the gate, compromise of trusted components, prompt injection, incorrect Host-side planning, malicious local stdio launch commands, and hidden, undeclared, unmediated dependencies.Source: Threat, Trust, and Policy Model · pp. 2–3
  • Host policy sets the user-authorized invocation boundary, Provider policy sets acceptable workload states, appraisal freshness, and downstream constraints, and the issuer intersects them; conflicts, missing versions, or downgrades fail closed.Signed policy-version identifiers accompany appraisal results and leases.Source: Threat, Trust, and Policy Model · p. 3

Related Work

Prior work addresses agent behavior, delegated authorization, and workload appraisal; ACLE-MCP focuses on admitting each remote tool invocation only when its authority is bound to a fresh, expected provider-side workload.

Agent and tool security

Delegated authorization and capabilities

  • OAuth extensions, delegated tokens, sender-constrained tokens, least-privilege policies, and attenuated capabilities provide authorization mechanisms that ACLE-MCP builds on (Lodderstedt, Richer, and Campbell 2023; Jones et al. 2020; Fett et al. 2023; Cao et al. 2024; Birgisson et al. 2014; Andersen et al. 2019).ACLE-MCP’s added contribution is binding narrow invocation authority to fresh provider-side appraisal and consuming it at the tool-execution boundary.Source: Related Work · p. 3

Remote attestation and execution control

  • RATS and systems for workload identity, build provenance, dynamic appraisal, or isolation strengthen execution environments, while ACLE-MCP uses appraisal to decide admission for one remote agent tool invocation (Birkholz et al. 2023; Chen 2023; Hugenroth et al. 2025; Wang et al. 2023; Galanou et al. 2025; Delignat-Lavaud et al. 2025; Zhang et al. 2023; Sridhara et al. 2024).The cited examples include Runtime SBOM verification, Attestable Builds, ARI, Full Trust Alchemist, Transparent Attested DNS, SHELTER, and Acai.Source: Related Work · p. 3

Methodology

ACLE-MCP binds delegated OAuth authorization to a fresh appraisal of the provider-side workload and admits each protected invocation through a gate immediately before tool logic begins. Its boundary compiler, risk-based step-up, bounded leases, and fail-closed enforcement constrain which workload may execute which invocation.

Design Overview

  • The Execution Gate consumes a short-lived lease immediately before protected tool logic, denying calls with mismatched senders or workloads, stale appraisal, or requests outside the authorized boundary.The final check addresses the gap between OAuth authorization or connect-time appraisal and the concrete execution unit serving the invocation.Source: Design Overview · p. 3

Attested Step-Up and Lease Issuance

  • At registration and invocation, the boundary compiler combines tool defaults with concrete object, parameter, tenant, side-effect, and downstream constraints to produce the invocation boundary and minimum workload-assurance requirement.Risk governs step-up: low-risk reads may use ordinary OAuth, medium-risk calls require a scoped lease and bounded appraisal reuse, and high-risk calls require stricter freshness and tighter limits; uncertainty cannot lower risk.Source: Attested Step-Up and Lease Issuance · p. 3
  • For protected calls, a Verifier appraises fresh workload evidence under Provider policy and signs a minimized result; the issuer combines it with verified OAuth context and sender identity to issue a bounded capability lease.The lease binds workload identity, sender key, tool and operation, object and parameter bounds, execution state, downstream set, side-effect budget, policy versions, receipt obligation, expiry, and a unique identifier; OAuth grants delegated access, while the lease authorizes one bounded invocation under a particular workload state.Source: Attested Step-Up and Lease Issuance · pp. 3–4

Invocation-Time Enforcement

  • A Provider- or platform-controlled gate validates and consumes the lease before the protected handler, preventing side effects until sender, workload, freshness, request, and state constraints pass.Enforcement can use a proxy, sidecar, gateway, service-mesh filter, or confidential-computing wrapper if alternate paths are prevented; chained protected hops need separate leases or explicit downstream authorization, and required receipt or other validation failures fail closed.Source: Invocation-Time Enforcement · p. 4

Evaluation

The evaluation finds that full ACLE-MCP blocks the evaluated execution-misuse attacks while preserving the observed benign tasks, and examines the mechanisms, integration, and runtime cost behind those results. Its experiments also show that freshness requirements affect security and that the reported costs depend on the measurement setup.

Experimental Setup

  • The evaluation compares five enforcement modes across four benign task families and six execution-misuse attack families, with ten repetitions per scenario yielding 500 mode–scenario observations.The controlled harness separates Verifier, lease issuer, Execution Gate, MCP tool service, and adversarial workloads, and records request-level decisions and stage-level latency.Source: Experimental Setup · pp. 4–5

RQ1: Security Effectiveness and Agent Extension

  • Full ACLE-MCP blocks every evaluated attack scenario (false-negative rate 0%), while all five modes achieve 100% benign-task success (false-positive rate 0%); OAuth-only and connect-time attestation block none.The mechanism experiments also find that OAuth-only and connect-time attestation admit replay, workload substitution, stale appraisal, undeclared proxying, and receipt violations because they do not bind each invocation to current appraisal at the gate.Source: Table 1 · p. 5, RQ1: Security Effectiveness and Agent… · p. 5

RQ3: Real-Component Integration and Runtime Cost

  • 12.20 ms to 15.34 ms is the agent-suite pooled p95 change from OAuth-only to full ACLE-MCP, an increase of 3.14 ms or 25.7%.In the separate mechanism-level experiment, normal allowed requests have a pooled mean of 23.17 ms and p95 of 38.41 ms; the 356.13 ms blocking-path p95 includes a configured 350 ms delay, not lease or gate overhead.Source: Table 1 · p. 5, RQ1: Security Effectiveness and Agent… · p. 6, Figure 4 · p. 6

RQ2: Ablation Study and Mechanism Attribution

  • At a 50 ms freshness window, ACLE-MCP blocks all modeled TOCTOU cases; blocking falls to 0.60 at 500 ms and zero at 5000 ms.The 50 ms window averages 10.2 Verifier calls with a cache-hit ratio of 0.5143; wider reuse windows reduce verification pressure but extend exposure between appraisal and execution.Source: Figure 3 · p. 6, RQ2: Ablation Study and Mechanism… · p. 6
  • The complete design achieves a 100% blocking rate; removing sender proof, freshness checks, downstream constraints, or receipt validation reopens their corresponding attack classes while benign-task success remains 100%.The configuration without Attested Step-Up also disables workload-binding checks, so it is a joint ablation rather than a Verifier-only removal.Source: RQ2: Ablation Study and Mechanism… · p. 6, Table 2 · p. 7

RQ3: Real-Component Integration and Runtime Cost

  • The Keycloak/MCP integration validates a real Keycloak token, enforces resource audience at the Execution Gate, and invokes an MCP Python SDK tool; optional vTPM quote verification preserves the appraisal, lease, and gate interfaces.The path does not include production remote attestation, DPoP-bound issuance, or a complete hardware trust chain, and the vTPM path is not a production-performance measurement.Source: Experimental Setup · p. 5, Table 3 · p. 7, RQ3: Real-Component Integration and… · p. 7

Discussion

ACLE-MCP addresses the post-authorization execution trust gap through a provider-side reference monitor, but depends on a non-bypassable Execution Gate. Its evaluation shows prototype-level feasibility, not production readiness, and excludes important threats and guarantees.

Assumptions and scope

  • ACLE-MCP’s enforcement depends on a non-bypassable provider-side Execution Gate; control of the gate or all routing paths defeats it.The prototype also excludes prompt injection, incorrect Host-side planning, and compromise of the Verifier or lease.Source: Discussion · p. 7

Evaluation limitations

  • The evaluation covers four benign tasks and six author-constructed misuse families, with sender proof and workload appraisal simulated in the main harness.The vTPM path verifies quotes without binding every workload claim.Source: Discussion · p. 7
  • Receipts cannot undo external side effects, and downstream guarantees cover only declared or mediated dependencies, so the results demonstrate prototype-level feasibility rather than production readiness.Source: Discussion · p. 7

Conclusion

ACLE-MCP addresses the post-authorization execution trust gap by binding workload appraisal to the invocation boundary through a short-lived, sender-constrained lease consumed before protected tool logic begins. Evaluations report that the complete design preserves evaluated benign tasks and blocks all evaluated attack families.

Conclusion

  • The complete design preserves all evaluated benign tasks and blocks all evaluated attack families, while authorization-only, connect-time attestation, Stateful policy, and Capability-only designs leave distinct attack surfaces.Evidence comes from controlled attacks, component ablations, and the agent tool-use extension.Source: Conclusion · p. 7
  • ACLE-MCP issues a short-lived, sender-constrained capability lease that binds workload appraisal to the invocation boundary and is consumed immediately before protected tool logic begins.Source: Conclusion · p. 7
  • For high-risk remote tool calls, workload trust must be checked when delegated authority is actually consumed, because OAuth authorization alone does not ensure execution by the expected, freshly appraised provider-side workload.Source: Conclusion · p. 7

Related papers

Loading 2609.02690v1…