Zero-Trust Authorization and Discovery for Enterprise MCP

Huan Li; Yuwei Wang; Srinivasan Manoharan

cs.CRSep 18, 2026

Zero-Trust Authorization and Discovery for Enterprise MCP

Authors: Huan Li, Yuwei Wang, Srinivasan Manoharan

Organizations: PayPal Inc. USA

Abstract

LLM agents translate natural-language context, which may include attacker-controlled text, into privileged tool calls, so authorization must remain effective even when an agent is prompt-injected or adversarially steered. The Model Context Protocol (MCP) has become a widely adopted interface for this boundary, yet its official SDKs' authentication and authorization primitives fall short of enterprise zero-trust requirements, most acutely a dual-persona model in which one server must serve human users (corporate SSO) and automated agents (service-account credentials on a different header). We conduct a systematic gap analysis of six surveyed MCP SDKs (Python, TypeScript, Go, Rust, C#, Swift) and identify three structural shortcomings: credential extraction bound to a single Authorization header, complicating dual-persona deployment without custom middleware; the absence of pre-authentication tool discovery; and the lack of fine-grained per-tool authorization in the base SDKs. We close these gaps with composable extensions to FastMCP: cross-header credential normalization for enterprise deployments serving both human and service-account callers, cached token verification across heterogeneous IdPs, an unauthenticated metadata endpoint for credential-free registry discovery, and permission-filtered tool visibility kept consistent with per-tool invocation enforcement by a single declarative annotation, all without modifying the protocol or SDK internals. Across four frontier LLMs over 2160 attempts, an in-body-check-only server still exposes forbidden tools (152/720, 21.1%), whereas permission-aware visibility drives the rate to 0/720; visibility-only filtering remained bypassable by scripted clients, while models referenced the hidden tool by name in up to 94% of settings when inferable from the prompt, confirming that discovery controls cannot replace invocation-time enforcement.

Figures & tables

Capability	Py †	TS	Go	Rust	C#	Swift
Pluggable auth backend	P	P	P	Y	Y	Y
Pre-auth discovery (schema+auth)	N	N	N	N	N	N
Permission-based filtering	Y	N	N	N	N	N
Vendor-API token verif. (beyond RFC 7662)	N	N	N	N	N	N
Declarative per-tool permissions	Y	N	N	N	N	N

Table 1. Cross-SDK capability matrix.

Figure 1. MCP server deployment architecture.

	list_tools		call_tool
Configuration	p50	p95	p50	p95
vanilla MCP	1.71	1.98	2.15	2.41
+auth	1.78	2.07	2.18	2.58
+auth+filter	1.70	2.08	2.21	2.59
+auth+filter+decorator	1.67	1.92	2.18	2.49

Table 2. SDK framework-layer per-request latency (ms).

Goal	Defender	Attack scenario	Result
G1 Tool misuse	C4 (filter + decorator)	Section 4.3.1 Prompt injection	$152/720\rightarrow 0/720$ (4 LLMs)
G2 Header confusion	C1 (deterministic merge)	Section 4.3.2 , multi-header matrix	no wider scope
G3 Auth bypass	C1 (OR composition)	Section 4.3.2 , same matrix	all-fail $\Rightarrow$ error
G4 Stale credential	C2 (bounded TTL)	Section 4.3.3 Revoke + reuse	$\leq$ TTL (300 s default)

Table 3. Threat coverage matrix.

	Baseline (per attack class)				Baseline	Filter-only	With-ext.
Model	DI	II	RP	CO	overall	overall	overall
claude-sonnet-4-6	$0/45$	$0/45$	$0/45$	$0/45$	$0/180$	$0/180$	$0/180$
claude-opus-4-7	$3/45$	$0/45$	$0/45$	$0/45$	$3/180$	$0/180$	$0/180$
gpt-5	$26/45$	$0/45$	$33/45$	$0/45$	$59/180$	$0/180$	$0/180$
gemini-2.5-pro	$27/45$	$23/45$	$37/45$	$3/45$	$90/180$	$0/180$	$0/180$
Total	$\mathbf{56/180}$	$\mathbf{23/180}$	$\mathbf{70/180}$	$\mathbf{3/180}$	$\mathbf{152/720}$	$\mathbf{0/720}$	$\mathbf{0/720}$

Table 4. Multi-model adversarial sweep: forbidden-tool attempt counts.

Bearer	Custom	Backend outcome	Scopes
yes	no	Bearer succeeds	Bearer
no	yes	Custom succeeds	Custom
yes	yes	Both succeed	Union
no	no	All return None	Error

Table 5. Multi-header authentication outcome matrix.

Configuration	Listed	Direct call execs	Blocked by
Baseline	yes	no	in-body check
Filter only	no	yes	— (bypass)
With-extensions	no	no	@require_perm

Table 6. Tool-name-guessing attack outcomes by configuration.

	Pre-auth schema	Per-tool authz	Cross-header creds	Discovery-coupled
Envoy / Istio ( Li et al., 2019 )	—	—	part.	—
OPA / Cedar ( Open Policy Agent, 2024 ; Amazon Web Services, 2023 )	—	yes	—	—
SPIFFE/SPIRE ( SPIFFE Project / CNCF, 2022 )	—	—	—	—
FastMCP auth= ( Lowin, 2026 )	—	yes	part.	part.
Cerbos–FastMCP ( Cerbos, 2025 )	—	yes	—	part.
Gateway ( Kumar et al., 2026 )	n/r	n/r	yes	n/r

Table 7. Positioning vs. adjacent stacks. “n/r” = not reported.

Appendix figures & tables1 asset

Supplementary material from the paper’s appendix.

Appendix

Language	Version	Released
Python	v1.27.0 (+ fastmcp v3.4.0)	2026
TypeScript	v1.26.0	2026-02-04
Go	v1.3.0	2026-02-09
Rust	rmcp v1.2.0	2026-03-11
C#	v1.1.0	2026
Swift	0.10.2	2025-09-23

Appendix

Table 8. MCP SDK versions analyzed.

MCP Security

Model Context Protocol (MCP) security studies how to protect AI agents, tool servers, and data flows from attacks and misuse.

See all 41 papers

Mar 8, 2026

Give Them an Inch and They Will Take a Mile:Understanding and Measuring Caller Identity Confusion in MCP-Based AI Systems

The Model Context Protocol (MCP) is an open and standardized interface that enables large language models (LLMs) to interact with external tools and services, and is increasingly adopted by AI agents. However, the security of MCP-based systems remains largely unexplored.In this work, we conduct a large-scale security analysis of MCP servers integrated within MCP clients. We show that treating MCP servers as trusted entities without authenticating the caller identity is fundamentally insecure. Since MCP servers often cannot distinguish who is invoking a request, a single authorization decision may implicitly grant access to multiple, potentially untrusted callers.Our empirical study reveals that most MCP servers rely on persistent authorization states, allowing tool invocations after an initial authorization without re-authentication, regardless of the caller. In addition, many MCP servers fail to enforce authentication at the per-tool level, enabling unauthorized access to sensitive operations.These findings demonstrate that one-time authorization and server-level trust significantly expand the attack surface of MCP-based systems, highlighting the need for explicit caller authentication and fine-grained authorization mechanisms.

Yuhang Huang, Boyang Ma, Biwei Yan +5

Shandong University Qingdao, Shandong, China · City University of Hong Kong Hong Kong, Hong Kong, China

MCP Security AI Agent Security Tool Access Control for LLM Agents AI Agent Auditing

Ask PDF

May 22, 2026

Attested Tool-Server Admission: A Security Extension to the Model Context Protocol

The Model Context Protocol (MCP) standardizes how a large-language-model (LLM) agent and an external tool server exchange messages, but not trust: a host reads a server's self-declared tool list and dispatches calls, with no notion of which servers it may use, at what sensitivity, or which of a server's tools are in bounds. This work grew out of a concrete need -- letting the Enclawed agent use Google's externally-operated MCP servers (Gmail, Calendar, Drive) safely, admitting the server and bounding the tools it may drive, without changing MCP or Enclawed's own tool application-programming interface (API). The mechanism we built, mcp-attested (shipped in both the open enclawed-oss distribution and the enclaved flavor), generalizes: the gap that makes an unmediated third-party connection unsafe for one user makes a regulated deployment impossible to accredit. We close it with three additive mechanisms: (1) a small, offline-signed clearance assertion a server publishes at a well-known Uniform Resource Identifier (URI) and a host verifies against a pinned trust root before any tool dispatch; (2) a deny-by-default per-server tool allowlist, so admitting a server is not trusting its every tool; and (3) a flavor-gated enforcement mode that turns the checks from warnings into hard denials, with every decision written to a tamper-evident audit log. We give the wire format, the verification algorithm, a security analysis, and an LLM-driven adversarial evaluation; we then state the design in normative Request-for-Comments (RFC 2119) form -- schema, verification rules, error registry, well-known registration, and machine-checkable conformance vectors -- so it can be adopted as an MCP addendum rather than reinvented. An unextended host ignores the well-known document and behaves exactly as today.

Alfredo Metere

Enclawed LLC

MCP Security AI Agent Security Model Context Protocol Tool-Use Authorization Tamper-Evident Logging

Ask PDF

Aug 11, 2026

A Gateway Architecture for Enterprise MCP Authentication: Unifying Heterogeneous Auth, Identity Delegation, and the User / Non-User Persona Problem

The Model Context Protocol (MCP) has become the de-facto interface for connecting LLM agents to enterprise tools, and adoption has been explosive: within a year, large organizations went from zero to dozens of internally built MCP servers. That speed created a governance crisis. Each team implemented authentication independently -- some with no auth, some with API keys, some with full OAuth -- producing a fragmented landscape with no consistent way to authorize callers, track who did what, or offboard a departing employee across the fleet. This paper reports an industry deployment that resolves the crisis with a centralized MCP gateway: a single aggregation, governance, and authentication layer that fronts every downstream MCP server. We make four contributions grounded in production experience. First, a two-axis authentication model crossing persona (interactive user vs. automated non-user) with credential type (no-auth, static/dynamic API key, PKCE, client credentials, platform app-context). Second, a gateway authentication layer supporting three enterprise SSO grants and three token-provisioning models: Bring-Your-Own-Token, Generate-Your-Own-Token, and delegated OAuth via RFC 8693 token exchange. Third, three end-to-end identity flows -- User-to-OAuth2, Non-user-to-Service-Account, and User-to-Service-Account -- composing client, gateway, and server. Fourth, the deployment evolution from CDN/WAF/edge perimeter to private MCP tunnels and enterprise-wide connectors. The architecture is in production, fronting dozens of MCP servers across web, desktop, custom-SDK, and low-code clients.

Suraj Kumar, Amy Wang, Srinivasan Manoharan

Enterprise AI Platform Engineering

MCP Security Tool-Use Authorization Access Control

Ask PDF

Abstract

MCP Security

Explore similar work

Give Them an Inch and They Will Take a Mile:Understanding and Measuring Caller Identity Confusion in MCP-Based AI Systems

Attested Tool-Server Admission: A Security Extension to the Model Context Protocol

A Gateway Architecture for Enterprise MCP Authentication: Unifying Heterogeneous Auth, Identity Delegation, and the User / Non-User Persona Problem