A paper closes the gap between MCP login and execution

A new paper names a gap in how remote MCP tool calls get trusted. OAuth proves an endpoint was authorized once; nothing checks that the workload running the call later is still the one the caller trusted.

The paper describes four ways that gap gets exploited. A tool call can run on a substituted workload, or lean on stale attestation instead of a fresh check. It can also reuse authority meant for another sender, or route through an undeclared downstream component.

Each lets a call pass authorization while running somewhere, or as something, different from what got approved. Anyone running agents against remote MCP servers is trusting one login-time check to hold for every call that follows it.

The fix in the ACLE-MCP paper is a short-lived, sender-constrained capability lease. It binds the expected workload, a freshness window, the specific operation, object and parameter bounds, downstream constraints and receipt obligations. A provider-side Execution Gate checks that lease immediately before the protected tool logic runs. Every call gets re-verified at the moment it executes, rather than once at login.

The authors built a working prototype on Keycloak/OIDC and the MCP Python SDK server, with an optional vTPM backend for hardware-based quote verification. Weaker setups, authorization alone or attestation checked only at connect time, left the four attack families open. The full lease-plus-gate design blocked all of them while still letting legitimate tasks through.

The paper doesn't say how the Execution Gate performs under production load, or whether the lease scheme works without a vTPM. Those gaps sit between this prototype and production use of remote MCP tool servers.