MCP Security Ceiling: A New Paper Maps the OWASP MCP Top 10 to Three Tiers

A preprint posted to arXiv on 2 November 2026 asks how far a careful MCP server developer can get on their own, and finds that five of the ten OWASP MCP Top 10 entries are primarily addressable at the server tier (its Table 1; the paper also says half of the taxonomy can be addressed at the server). “Where Does MCP Security End? A Three-Tier Mitigation Mapping Framework for the OWASP MCP Top 10” (arXiv:2611.02611, cs.CR) by Christopher Krakauer and Andreas Schaad sorts each OWASP MCP Top 10 entry by the layer where it is primarily addressable. Three entries land in the protocol tier, where server-side controls are only partial.

This is a v1 preprint and we found no sign of peer review. The article summarizes the paper’s own claims, and we have not reproduced its case study. The High, Medium and Low ratings are the authors’ qualitative judgement from one case.

The Core Argument

MCP carries tool descriptions, resource contents and tool outputs into the same context the model uses to decide what to do. The authors call this a blended data and control plane. Any text that reaches the context window can act as an instruction, and the model cannot reliably tell the difference. The paper treats indirect prompt injection and confused deputy behavior as consequences of that routing, not as bugs in individual servers.

Three properties shape the framework. Non-determinism limits verification, since the same input can be handled differently across runs and no unit test proves a natural-language control holds. The blended plane limits reachability, since once content enters model reasoning, deployed code cannot rebuild a boundary the protocol never preserved. And the lack of integrity checks on distributed tool definitions limits observability, since one server cannot see what its neighbors in a shared deployment are feeding into the same context.

Three Tiers, Four Questions

Each entry gets a primary tier. The server tier covers deterministic controls inside the developer’s code, such as input validation and scoped credentials. The gateway tier covers controls that need infrastructure outside one server, such as cross-server telemetry and connection policy. The protocol tier covers root causes that only a change to the specification could fix.

A four-question decision tree sets the tier and a confidence level:

1. Can a unit test prove the control works?
2. Can it be bypassed without exploiting an implementation bug?
3. Does it behave predictably inside the server’s scope while failing against threats from outside it?
4. Can it be circumvented with encoding, obfuscation, novel phrasing or the model’s non-determinism?

Passing the first two questions gives High confidence. Passing the third gives Medium. Reaching the fourth gives Low, which the authors describe as a structural limit, not a weak implementation.

The Mapping

Entry	Tier	Confidence
MCP01 Token Mismanagement and Secret Exposure	Server	High
MCP02 Privilege Escalation via Scope Creep	Server	High
MCP03 Tool Poisoning	Protocol	Low
MCP04 Software Supply Chain Attacks and Dependency Tampering	Server	Medium
MCP05 Command Injection and Execution	Server	Medium
MCP06 Intent Flow Subversion (the paper’s name; OWASP’s project page lists “Prompt Injection via Contextual Payloads”)	Protocol	Low
MCP07 Insufficient Authentication and Authorization	Server	High
MCP08 Lack of Audit and Telemetry	Gateway	Medium
MCP09 Shadow MCP Servers	Gateway	Medium
MCP10 Context Injection and Over-sharing	Protocol	Low

Two rows show the logic. MCP05 is Medium because parameterized command construction is testable, but an indirect path remains where the model itself builds the dangerous parameters. MCP06 is Low because output sanitization can be unit tested against known patterns, yet it is bypassed without any defect, and the paper cites prior work on evasion of deployed guardrails to support that.

The Case Study and Its Failures

The authors tested the framework against an enterprise Managed File Transfer MCP server written in Go under real security governance. They report that the High-confidence controls behaved as predicted. API scopes were fixed upstream before the OAuth flow ran, and PKCE-based token validation rejected expired tokens.

The more useful part is the list of documented failures:

• Trust tagging. Wrapping content in UUID provenance markers to restore data and instruction separation failed because nothing in the specification carries or recognizes such markers.
• Field masking. Masking of sensitive fields was left out of production to preserve functionality, which shows the limit server controls face against context aggregation.
• Session isolation. Attempts hit the same wall, with per-server namespaces enforced inside a shared context.
• Gateway controls. The platform shipped no MCP-specific gateway controls and left them to customers.

The paper also tests extensibility on context window saturation, a denial of service vector that OWASP does not list. The same tree puts rate limiting at server tier with High confidence, aggregate resource monitoring at gateway tier with Medium, and context budgeting at protocol tier with Low, since the protocol has no field to declare a budget.

Limits of the Evidence

This is a framework paper. The evidence is one case, and the paper describes the authors’ role in it as participant-observer, which it acknowledges as a source of bias. Confidence levels are categorical judgments, not measured bypass rates, and the authors say tier assignments across other deployments are untested. The framework itself proposes no change to the MCP specification, though the conclusion points to neutral multi-stakeholder governance of AI protocols as the likely route to protocol-level fixes.

What This Means for Defenders

Our assessment is that the mapping is most useful as a budgeting tool. Server teams should finish the High and Medium work first: scoped credentials, token validation, dependency integrity checks and parameterized execution. They should not expect sanitization or tagging to close tool poisoning or context over-sharing.

For the gateway tier, the paper implies that audit aggregation across servers and detection of unapproved servers are deployment responsibilities. Our guidance is to assign an owner for them, because the paper’s case study reports the platform shipped no MCP-specific gateway controls and left them to customer discretion. For the protocol tier, the paper rates server-side controls as partial. These suggestions are ours, not the paper’s: allowlists of approved servers, review of tool definitions when they change, and human confirmation for high-impact actions.

References

• Krakauer and Schaad, “Where Does MCP Security End? A Three-Tier Mitigation Mapping Framework for the OWASP MCP Top 10,” arXiv:2611.02611, 2 November 2026: https://arxiv.org/abs/2611.02611
• Full text (PDF): https://arxiv.org/pdf/2611.02611
• OWASP MCP Top 10 project page: https://owasp.org/www-project-mcp-top-10/