Zero-Trust Authorization and Discovery for Enterprise MCP
Huan Li, Yuwei Wang, Srinivasan Manoharan
cs.CR · cs.AI
Quick verdict
FastMCP extensions for dual-persona auth, pre-auth discovery and per-tool RBAC, in production; candid paper, but the headline 21.1%→0% result is architecturally forced.
Summary
The paper presents FastMCP extensions for enterprise zero-trust MCP authorization: cross-header credential normalization (C1) serving human SSO and service-account callers on one server, cached vendor token introspection (C2), an unauthenticated pre-auth metadata endpoint for registry discovery (C3), and permission-filtered tool visibility tied to per-tool invocation enforcement via one declarative DNF annotation (C4). A versioned gap analysis of six MCP SDKs (Table 1, snapshot 2026-05-15) motivates the design. Across four frontier LLMs and 2160 attempts, the baseline server with only in-body checks drew 152/720 (21.1%, Wilson CI [18.3, 24.2]) forbidden-call attempts under prompt injection (per-model 0/180 to 90/180), versus 0/720 with permission-aware visibility plus enforcement. The authors candidly state these zeros follow structurally from removing tools from the agent schema; the empirical value lies in baseline characterization and name-echo leak rates up to 94% for names inferable from prompts, with a scripted direct-call bypass (Table 6) motivating the decorator layer. Production cache metrics (96.1% hit rate, 9.9 ms p50) are internal and not reproducible, the artifact repository lacks a live link, and the positive control used partly mismatched checkpoints, limiting generalization.
Review complete
Assessment at a glance
6
risk flags identified
● high 0
● medium 3
● low 3
4 strengths · 5 weaknesses · 5 author questions
AI text signal = Binoculars zero-shot detector score over 20 sampled passages (Fast-DetectGPT co-reported) — absence does not prove human authorship, and a flag does not imply misconduct.
Levels reflect verification complexity — not a quality score. Evolve never rates your paper.
Key claims under review
- The six surveyed MCP SDKs (snapshot 2026-05-15) provide no documented path combining dual-header credential composition, pre-auth tool discovery, and declarative per-tool authorization (§2.3, Table 1, §A).
- A single _required_permissions DNF annotation can keep pre-auth metadata, authenticated listings, and invocation enforcement consistent by construction, using only native FastMCP/Starlette extension points (§3.2, §3.8).
- With permission-aware visibility plus invocation enforcement, prompt-injected frontier LLMs emit zero forbidden-tool call attempts (0/720 across four models), versus 152/720 (21.1%) for an in-body-check-only baseline (Table 4).
- Visibility filtering alone is bypassable by scripted direct tool calls once the name leaks, and models echo inferable hidden-tool names in up to 94% of with-extensions cells, so discovery control cannot replace invocation-time enforcement (§4.3.4, Table 6).
- The extensions run in production at PayPal with ~30x p50 introspection speedup (96.1% cache hits) and ≤~0.15 ms p95 overhead (§4.2, Table 2).
Strengths
Three-surface consistency from one declaration (C4)
The _required_permissions annotation is read simultaneously by the pre-auth metadata endpoint (§3.5), the PermissionFilterMiddleware listing hooks (§3.6), and the @require_permissions decorator (§3.8), so discovery, listing and enforcement cannot drift apart — this is honestly positioned as the remaining delta over FastMCP 3.0's native auth= parameter and the Cerbos-FastMCP integration (§2.3, §3.8).
Unusually candid structural framing
§4.3.1 explicitly concedes the 0/720 filter-only and with-extensions results are 'almost true by definition' and reframes the empirical contribution as the baseline attempt distribution (152/720, 21.1%, Wilson CI [18.3, 24.2]), cross-vendor variance (0/180 to 90/180 on identical prompts), and the name-leak rates — a defensible, honest scoping rare in this subfield.
The decorator-layer argument is empirically grounded
Real production deployment with quantified overhead
Weaknesses
Headline zeros are architecturally forced, limiting empirical value
Weakened positive control
No inferential statistics beyond aggregate Wilson intervals
Leak-rate design is a name-echo measurement
Verification currently impossible
Full Review Report
$1.99 · one-timeUnlock the complete preliminary analysis Evolve produced for this paper.
Report preview
Scope & Claims
This paper targets the MCP server boundary in enterprise deployments, where LLM agents — potentially prompt-injected — translate attacker-conditionable context into privileged tool calls. The claimed core is not novel primitives but composition: a "three-surface consistency" property (§1) deriving pre-auth metadata (C3), authenticated listings, and invocation checks (C4) from one declarative DNF annotation (`_required_permissions`, §3.8), plus cross-header credential normalization (C1) and cached multi-vendor token introspection (C2). A versioned gap analysis of six SDKs (Table 1, snapshot 2026-05-15, §A) motivates the work. The security invariant (§2.4) — visibility iff invocability iff DNF-satisfied, with natural-language input excluded from the decision — is the paper's central formal claim, satisfied "by construction" and stress-tested empirically.
Notably, the authors preempt the obvious novelty objection themselves: FastMCP 3.0+ `auth=` already couples listing and invocation (§2.3), and Cerbos-FastMCP provides separate list/call actions. The remaining delta is DNF (disjunctive) composition and the metadata surface derived from the same declaration. Yet §4.1 still frames "five capability gaps" against FastMCP — a tension a camera-ready should resolve.
The remaining sections cover Methodology Assessment, Statistical Evidence, Results & Reproducibility, Limitations & Risks, and Verdict & Recommendations.
- All 4 strengths & 5 weaknesses, analyzed in detail
- 6 risk flags with severity, section & reviewer questions
- Methods & statistical evidence assessment
- 5 questions a peer reviewer would ask
- Full six-dimension evaluation report & recommendations
One-time purchase · this paper only
One-time purchase, this paper only. AI-generated preliminary analysis — not peer review.
Frequently asked questions
Can you hide MCP tools from an LLM agent based on permissions?
Yes. The paper's PermissionFilterMiddleware removes tools a caller is not authorized to use from list_tools responses, and its decorator blocks invocation even if the agent learns a hidden tool's name. Measured over 2160 attempts across four frontier LLMs, a server with both layers drew zero unauthorized call attempts under prompt injection, versus 152/720 (21.1%) when all tools were listed and permissions were only checked inside tool bodies. Filtering alone is not enough: a scripted client calling a hidden tool directly bypasses it.
How vulnerable are LLM agents to prompt-injection attacks on MCP tools?
It depends heavily on the model. In this paper's baseline configuration (all tools visible, permissions enforced only inside tool bodies), four frontier models made 152 unauthorized-call attempts out of 720 prompt-injection trials (21.1%), but per-model rates on identical prompts ranged from 0% (claude-sonnet-4-6) to 50% (gemini-2.5-pro). The authors argue this 50-point cross-vendor spread shows model refusal is too unstable to serve as a security boundary, favoring server-side authorization instead.
Does the paper's pre-auth metadata endpoint leak sensitive information?
By design, yes, partially. It publishes tool names, JSON schemas, and required permissions (in DNF form) without authentication so registries can index servers without holding credentials. The authors argue it grants reconnaissance but no invocation ability, since calling a tool still requires valid credentials and passes the per-tool permission check. They acknowledge this helps attackers craft targeted injections, and the endpoint can be disabled or separately protected.
Is caching token verification safe, and how much faster is it?
The paper caches vendor token-introspection results for a default 300 seconds, SHA-256-keyed so raw tokens are never stored. In a 7-day production trace, 96.1% of verifications were served from cache at 9.9 ms p50 versus 296 ms p50 on a miss (~30x). The tradeoff: a token revoked at the identity provider can remain accepted for up to the TTL window (300 s default); deployments needing immediate revocation must disable the cache or add a revocation webhook.
About this review
This is an AI-generated preliminary review by Evolve.Pub, produced from the openly available text of the paper. It is not peer review and does not represent the authors' views. The canonical record of the paper is at the publisher link above.
- Figure 1 (deployment architecture) and Table 5 cell values are only partially reconstructible from the extracted text; the abstract is truncated mid-sentence in the source text.
- No venue or submission target is stated in the extracted text; review standards assumed are ACM-style security/systems venues.
- References [19] and [23] are an arXiv companion paper and vendor documentation respectively; cross-SDK gap claims (Table 1) reflect a 2026-05-15 snapshot and could not be independently verified within this review.
- The embedded text is stated to possibly be truncated; sections appear complete but page-level layout could not be checked.
Go deeper on this paper
Wrote a paper? Stress-test it before reviewers do.
Upload your manuscript for the same structured scrutiny — reasoning, statistics, evidence, figures, and reproducibility.