Zero-Trust Authorization and Discovery for Enterprise MCP

What it is

Research from PayPal engineers proposing four composable extensions to FastMCP (the Python MCP framework) that close specific gaps found across six official MCP SDKs (Python, TypeScript, Go, Rust, C#, Swift): cross-header credential normalization, cached cross-IdP token verification, an unauthenticated metadata/discovery endpoint, and a single declarative per-tool permission annotation governing both visibility and invocation.

How it works

The extensions plug into existing framework extension points only — Starlette HTTP middleware, FastMCP application middleware, custom_route for the pre-auth metadata endpoint, and Python function decorators — with no monkey-patching or MCP protocol/SDK core modification. Credential composition uses OR logic (accept any of several credential types) or AND logic (require multiple credentials simultaneously for high-assurance deployments). The permission decorator preserves the wrapped function's signature via dynamic code generation so FastMCP's JSON-schema introspection keeps working. Token verification results are cached within a bounded TTL to avoid a round-trip per call for IdPs issuing opaque (non-JWT) tokens, and cache keys are SHA-256 hashed so an attacker reading the cache can't recover the token (though timing could still reveal whether a token is cached — an explicitly out-of-scope side channel).

Preconditions / Affected

Applies to enterprise deployments needing dual-persona auth (human SSO + service-account automation on one server) and to registry/control-plane setups that need to index many MCP servers' tools without holding credentials. The gap analysis found the three older SDKs (Python, TypeScript, Go) bind credential extraction to the Authorization header by default, requiring middleware replacement (not configuration) to support a second credential type; the three newer SDKs (Rust, C#, Swift) expose auth extension points but still lack both pre-auth tool metadata and native declarative per-tool authorization in the versions surveyed. The paper notes FastMCP 3.0+ already added scope-based auth= component authorization covering visibility and invocation, so the paper doesn't claim novelty there — its distinguishing contribution is deriving pre-auth metadata, authenticated listings, and invocation checks consistently from one policy declaration.

What to do

No patches or commands are given (this is a research architecture, not a shipped library/CVE). The paper's prescriptive guidance: enforce authorization at the tool-invocation layer, not just transport auth; filter list_tools by caller permission so visibility matches invocability (per-tool DNF permission declaration drives both); keep a pre-auth metadata endpoint limited to schema/auth-method exposure with execution gated behind the authenticated path; cache IdP token verification with a bounded TTL and SHA-256-hashed cache keys rather than doing a round-trip per call.

Caveats

The threat model trusts the IdP, OS, TLS chain, and host, and assumes the agent cannot forge HTTP headers at the transport boundary — attacks on those layers are explicitly out of scope, as is DoS, preventing prompt injection itself, and forwarding caller authorization downstream (RFC 8693 is noted as future work). The paper is a single-vendor (PayPal) production deployment report plus benchmark, not an independently reproduced result.