MCP security is an unsolved problem. Here are the four attack surfaces.

The Model Context Protocol has won. Every major agent framework either supports MCP natively or has it on the roadmap. Claude, Cursor, OpenCode, Hermes, Windsurf, and a dozen others use it as their primary tool-calling layer. The specification is stable at version 2025-03-26, and the extension ecosystem is growing fast.

The security model has not kept up.

Three papers landed between late August and early September 2026, each attacking a different part of MCP's trust assumptions. Together, they map out four distinct attack surfaces that exist in every MCP deployment today. If you are running MCP servers in production, you need to know about all four.

1. Resource abuse across modalities

The first paper is AEGIS (Priya, Taylor, and Araujo, arXiv:2608.20481, August 2026). It focuses on a problem that sounds boring until it takes down your backend: resource abuse through MCP tool invocations.

An MCP server exposes tools. Each tool accepts parameters. Some of those parameters control how much work the backend has to do. A search tool might accept a radius parameter. A video tool might accept a duration parameter. An image tool might accept a resolution parameter. The agent does not know what "reasonable" values look like for your infrastructure, and neither does the LLM calling it.

The attack is straightforward. A malicious or confused agent sends a tool call with an absurdly large parameter:

{
  "tool": "search_nearby",
  "params": {
    "query": "coffee shops",
    "radius": 50000000,
    "limit": 100000
  }
}

Your backend tries to execute it. Depending on your implementation, this is either a slow query that ties up database connections, or a denial-of-service. The AEGIS paper documents this across four modalities: text (massive context injection), images (unbounded resolution requests), video (extreme duration), and location (planet-scale search radii). Each one has different resource implications, and each one can be exploited independently.

What AEGIS proposes

AEGIS is a policy enforcement layer that sits between the MCP client and the server. It uses an LLM to analyze incoming tool calls, normalise them into a standard representation, and check them against administrator-defined policies. The policies are enforced through Open Policy Agent (OPA), which gives you a declarative way to set limits per tool, per parameter, and per modality.

The interesting design choice is using an LLM to do the normalisation. Different servers name their parameters differently. One server's radius is another's distance or range. Hand-writing policy rules for every server's schema does not scale. AEGIS lets the LLM map arbitrary tool schemas into a common representation, then applies policies against that.

The integration with ContextForge AI Gateway means this can sit as infrastructure, not something each server implements individually.

2. Post-authorization execution trust

The second paper is ACLE-MCP (Ding, Luo, Chen, Shen, and Wu, arXiv:2609.02690, September 2026). It attacks a more subtle problem: what happens after you have already authorised a tool call.

OAuth gets you to the door. But OAuth verifies the identity of the endpoint, not what is actually running behind it at the moment your tool call arrives. The ACLE-MCP authors call this the "post-authorization execution trust gap." The endpoint is authorised. The workload behind it may not be what you think it is.

Four specific scenarios they document:

• Workload substitution: The authorised endpoint has been redeployed with different code since you last verified it.
• Stale appraisal state: The attestation evidence is from a previous execution, not the current one.
• Authority transfer: Credentials from one sender are reused by a different sender to access the same tool.
• Undeclared downstream components: The tool you called internally calls another tool you did not authorise.

What ACLE-MCP proposes

The solution is invocation-scoped capability leases. Instead of a long-lived OAuth token that says "this client may call this server," you get a short-lived lease that binds: the expected workload identity, a freshness requirement, the specific operation, parameter bounds, downstream constraints, and receipt obligations.

A provider-side "Execution Gate" consumes the lease immediately before the tool logic runs. If the workload has changed, the lease is stale, or the parameters exceed bounds, the call is rejected.

The cost: 25.7% increase in p95 latency on normal allowed calls compared to OAuth-only. Whether that is acceptable depends on your use case. For financial transactions or sensitive data access, it probably is. For high-throughput tool calls where each invocation is low-risk, it probably is not.

3. Delegation without confinement

The third paper (unnamed single-paper analysis, arXiv:2609.00267, August 2026) takes a wider view. It looks at what happens when agents delegate to sub-agents, and asks whether any existing framework actually confines a compromised sub-agent to its delegated task.

The answer is no.

The authors evaluate LangGraph, CrewAI, AutoGen, and MCP's built-in authorization model. Three of the four provide no confinement at all. MCP provides partial confinement. The gap is real and measurable: under bearer token delegation, a compromised sub-agent can reach all 8,100 possible actions. Under the authors' authorization broker, it can reach a mean of 1.5.

They define four adversaries:

• Confused deputy: An agent with higher privileges is tricked into exercising them on behalf of a lower-privileged request.
• Token theft and replay: A bearer token is intercepted and reused in a different context.
• Prompt injection privilege escalation: A prompt injection causes the agent to request tools or data it should not access.
• Compromised sub-agent: A delegated sub-agent has been taken over and acts against the delegator's interests.

What they propose

An authorization broker that sits between agents and the tools they call. The broker enforces delegation boundaries: a sub-agent can only reach the tools and parameters explicitly delegated to it. The broker blocks all four adversary types, resists 200,000 forged tokens in adversarial testing, and adds roughly 2.6 microseconds per decision. The principles are implemented in production in VotalAI's LLM Shield.

4. Pre-authorization context manipulation

A fourth paper (arXiv:2608.23858, August 2026) analyses Google's Agent Payments Protocol (AP2) and finds that the problem extends beyond tool calls into payment flows. AP2 v0.2 signs checkout mandates to protect transaction data after signing, but the agent interactions that shape the transaction before signing are outside that protection.

This is relevant to MCP because MCP tool calls are often part of the pre-authorization chain. An agent browses products via MCP tools, builds a cart, and then initiates payment. If the browsing and cart-building steps can be manipulated (through a compromised MCP server or a prompt injection), the signed mandate reflects a transaction the user did not intend.

The AP2 analysis identifies48 threats across five attack families, eight of which score "High" in at least one deployment architecture. Valid mandate signatures alone do not ensure that an agent-mediated transaction reflects the user's intent when the pre-authorization context has been manipulated.

What exists vs what is needed

What you can do today

None of these solutions are standardised or widely deployed yet. But you do not have to wait for the spec to catch up. Here is what is practical now.

Validate tool parameters at the server level

Do not trust the agent to send reasonable values. Every MCP server should validate its input parameters against sensible bounds before executing anything.

// In your MCP server tool handler
const MAX_RADIUS_KM = 100;
const MAX_RESULTS = 50;

server.tool("search_nearby", {
  // ... schema
}, async (params) => {
  const radius = Math.min(params.radius, MAX_RADIUS_KM);
  const limit = Math.min(params.limit, MAX_RESULTS);
  // Execute with clamped values
});

This is the lowest-effort, highest-impact mitigation. It does not require any infrastructure changes, and it blocks the most common resource abuse vectors.

Use short-lived, scoped tokens

If your MCP server accepts OAuth tokens, configure them with short expiry and narrow scopes. A token that grants access to all tools for 24 hours is a liability. A token that grants access to one tool for 5 minutes is a reasonable compromise between usability and security.

Log and monitor tool invocations

You cannot detect abuse you cannot see. Log every MCP tool call with: the tool name, the parameters, the caller identity, the timestamp, and the response code. Set up alerts for unusual patterns: high-frequency calls, large parameter values, or tools being called from unexpected contexts.

Isolate high-risk tools

If a tool can modify data, execute code, or initiate payments, run it in a separate MCP server with its own authentication and its own resource limits. Do not put a file-write tool and a file-read tool on the same server if you can avoid it.

Consider a gateway

The AEGIS and ACLE-MCP approaches both assume a policy enforcement layer between clients and servers. If you are running multiple MCP servers for multiple agents, a gateway that enforces consistent policies across all of them is worth the operational overhead. ContextForge is one option. Building your own with OPA is another.

Where this is heading

The MCP specification's security section currently says implementors "SHOULD" build consent flows, implement access controls, and follow security best practices. That is not a security model. It is a suggestion.

The three papers above show that the gap between "MCP works" and "MCP is secure" is wide enough to drive real attacks through. The good news: every attack surface has at least one proposed mitigation, and some of those mitigations are already in production.

The bad news: none of them are built into MCP itself. Security is still something you bolt on, not something you get by default. If you are building on MCP today, the burden is on you to close these gaps. The tools to do it exist. The spec has not caught up yet.

Sources

• AEGIS: Priya, Taylor, and Araujo, "AEGIS: Preventing Cross-Domain Resource Abuse in MCP," arXiv:2608.20481, 20 Aug 2026
• ACLE-MCP: Ding, Luo, Chen, Shen, and Wu, "ACLE-MCP: Attested Capability Leases for Execution-Time Trust in Remote LLM Tool Use," arXiv:2609.02690, 2 Sep 2026
• Delegation Without Trust: "Delegation Without Trust: An Empirical Gap Analysis of Identity, Authorization, and Runtime Governance in Multi-Agent LLM Systems," arXiv:2609.00267, 31 Aug 2026
• AP2 Security: "Beyond the Mandate: A Systematic Security Analysis of the Agent Payments Protocol (AP2)," arXiv:2608.23858, 24 Aug 2026
• MCP specification: modelcontextprotocol.io/specification/2025-03-26