Breaking the Protocol: Security Analysis of the Model Context Protocol Specification and Prompt Injection Vulnerabilities in Tool-Integrated LLM Agents

Narek Maloyan; Dmitry Namiot

Source-linked AI summary

Breaking the Protocol: Security Analysis of the Model Context Protocol Specification and Prompt Injection Vulnerabilities in Tool-Integrated LLM Agents

Narek Maloyan, Dmitry Namiot

arXiv:2601.17549v1Jan 24, 2026cs.CRcs.AI

TL;DR

MCP lacks formal protocol-level security analysis despite widespread use for LLM–tool integration, leaving architectural vulnerabilities insufficiently characterized. The paper analyzes the specification, measures attacks across MCP deployments against non-MCP baselines, and proposes a backward-compatible extension. MCP amplifies attack success by 23–41%, while the proposed extension reduces attack success from 52.8% to 12.4% with 8.3ms median per-message overhead.

Problem
Prior work did not quantify MCP’s architectural amplification of attack success against equivalent non-MCP integrations or propose backward-compatible capability attestation.
Method
The paper analyzes MCP’s specification and evaluates a backward-compatible extension adding capability attestation, message authentication, origin tagging, and isolation enforcement.
Results
MCP amplifies attack success by 23–41% depending on attack type, while ATTESTMCP reduces attack success from 52.8% to 12.4%.
Takeaways & Limitations
The findings support protocol-level remediation of MCP’s architectural weaknesses rather than relying solely on implementation patching.
Takeaways & Limitations
The security design remains exposed to social engineering of users authorizing malicious capabilities and to capability-authority compromise.

Abstract

from arXiv · show

The Model Context Protocol (MCP) has emerged as a de facto standard for integrating Large Language Models with external tools, yet no formal security analysis of the protocol specification exists. We present the first rigorous security analysis of MCP's architectural design, identifying three fundamental protocol-level vulnerabilities: (1) absence of capability attestation allowing servers to claim arbitrary permissions, (2) bidirectional sampling without origin authentication enabling server-side prompt injection, and (3) implicit trust propagation in multi-server configurations. We implement \textsc{MCPBench}, a novel framework bridging existing agent security benchmarks to MCP-compliant infrastructure, enabling direct measurement of protocol-specific attack surfaces. Through controlled experiments on 847 attack scenarios across five MCP server implementations, we demonstrate that MCP's architectural choices amplify attack success rates by 23--41\% compared to equivalent non-MCP integrations. We propose \textsc{MCPSec}, a backward-compatible protocol extension adding capability attestation and message authentication, reducing attack success rates from 52.8\% to 12.4\% with median latency overhead of 8.3ms per message. Our findings establish that MCP's security weaknesses are architectural rather than implementation-specific, requiring protocol-level remediation.

I. INTRODUCTION

MCP standardizes LLM–tool integration through a JSON-RPC client-server architecture, but its rapid adoption has outpaced protocol-level security analysis. This paper analyzes MCP’s architectural weaknesses, validates their impact experimentally, and proposes a backward-compatible extension.

I. INTRODUCTION: MCP provides an open JSON-RPC client-server standard for integrating LLMs with external tools.The architecture includes hosts, clients, servers, resources, tools, and server-requested sampling.
I. INTRODUCTION: Prior work did not quantify how MCP’s architectural choices amplify attacks relative to equivalent non-MCP integrations.Existing work addressed general prompt injection, agent capabilities, or implementation bugs rather than protocol-level comparative effects.
I. INTRODUCTION: The paper analyzes three protocol-level vulnerability classes, measures their effects across 847 attack scenarios, and designs a backward-compatible security extension.Its contributions cover specification analysis, experimental validation, and protocol extension design.
I. INTRODUCTION: Sampling lets servers request LLM completions through sampling/createMessage, creating a channel for server-injected prompts.The paper identifies sampling as a capability that allows servers to inject prompts and receive responses.

B. Threat Model

The threat model considers compromised or controlling MCP servers, injected external content, and black-box adversaries seeking to hijack behavior, exfiltrate data, or persist. It situates the work against existing agent-security benchmarks and identifies an MCP-specific comparative gap.

B. Threat Model: The adversary may control one MCP server, inject content into retrieved data sources, and access the system without modifying model weights or host code.Goals include hijacking agent behavior, exfiltrating sensitive data, and persisting across sessions.
B. Threat Model: 73% of surveyed installation guides instruct users to run npx directly from GitHub URLs without integrity verification.The survey identified typosquatting, supply-chain compromise, social engineering, and marketplace poisoning as installation vectors.
B. Threat Model: Existing benchmarks measure prompt injection, agent safety, tool use, or multi-agent attacks, but do not isolate MCP’s protocol-specific effects against non-MCP baselines.The paper’s gap is comparative measurement of architectural amplification and backward-compatible protocol mitigation.

III. PROTOCOL SPECIFICATION ANALYSIS

The specification analysis identifies unauthenticated capability declarations and sampling requests that let servers escalate permissions and inject prompts indistinguishably from user input. The proposed protocol-level response addresses origin ambiguity rather than relying on host implementation discretion.

III. PROTOCOL SPECIFICATION ANALYSIS: MCP capability declarations are self-asserted, so clients cannot verify whether servers possess the capabilities they claim.A malicious server can claim arbitrary capabilities during initialization.
III. PROTOCOL SPECIFICATION ANALYSIS: Servers can later invoke sampling/createMessage despite initially claiming only resource access, because message-level capability enforcement is not mandated.This permits unrestricted post-initialization capability escalation and violates least privilege.
B. Vulnerability 2: Sampling Without Origin Authentication: Sampling-derived prompts reach the LLM in the same format as legitimate user input, without distinguishing server-originated content.The attack uses sampling/createMessage with attacker-controlled content in the “user” role.
B. Vulnerability 2: Sampling Without Origin Authentication: No tested host implementation visually distinguishes sampling-derived messages from user-originated prompts.The paper treats this as an origin-authenticity failure and notes that the specification does not require such distinction.
B. Vulnerability 2: Sampling Without Origin Authentication: ATTESTMCP mandates protocol-level origin tagging, removing host discretion over whether server-injected prompts are distinguishable.The proposed fix addresses the specification’s silence on origin display.

C. Vulnerability 3: Implicit Trust Propagation

MCP’s composability allows outputs from one server to influence actions on another because the specification defines no inter-server isolation boundaries or provenance tracking. The proposed default requires explicit authorization for cross-server data flow, trading some utility for lower attack success.

C. Vulnerability 3: Implicit Trust Propagation: MCP does not define isolation boundaries between simultaneously connected servers.The shared LLM context conflates outputs from different servers without provenance tracking.
C. Vulnerability 3: Implicit Trust Propagation: A compromised Server A can induce invocations on Server B, exfiltrate Server B data, and persist by poisoning shared context.This violates isolation, meaning compromise of one component can propagate to others.
C. Vulnerability 3: Implicit Trust Propagation: MCP deliberately prioritizes composability over isolation, but provides no mechanism for users to configure isolation policies.The paper argues that cross-server trust should require explicit user consent rather than remain implicit.
1) Isolation-Utility Tradeoff:: ATTESTMCP’s user-prompted isolation reduces ASR by 48% while retaining 87.4% task completion versus 94.2% baseline.Cross-server information flow requires explicit authorization under the default policy.
D. Message Integrity Analysis: The MCP specification relies on transport security without application-layer protections, which is insufficient when servers may be compromised.This exposes a separate message-integrity weakness in the multi-server security setting.

IV. EXPERIMENTAL METHODOLOGY

The methodology uses PROTOAMP to measure how MCP architecture changes attack success relative to semantically equivalent non-MCP integrations. It adapts established benchmarks, adds protocol-layer injection points, and evaluates 847 scenarios across five server implementations and three LLM backends.

Benchmark Design: PROTOAMP measures protocol amplification by comparing MCP-integrated agents with equivalent non-MCP baselines.The framework preserves tool-function semantics while adding MCP protocol overhead.
Instrumentation: Injection capabilities target resource content and sampling request prompts, while clients log JSON-RPC messages to trace attack propagation.These injection points expose both content-mediated and protocol-mediated attack paths.
Testbed: The testbed includes filesystem, git, SQLite, Slack, and adversarial MCP servers, evaluated with Claude-3.5-Sonnet, GPT-4o, and Llama-3.1-70B.The servers span file, repository, database, messaging, and protocol-edge-case functionality.
Attack Scenarios: The evaluation covers 847 attack scenarios spanning InjecAgent adaptations, AgentDojo adaptations, and novel protocol-specific attacks.The scenario counts are 312, 398, and 137, respectively.

C. Controlled Variables

The controlled comparison holds tool semantics, payloads, prompting, and network latency constant while comparing MCP and non-MCP integrations. The reported results show protocol-level amplification and a distinct sampling attack surface.

Controlled Variables: Tool semantics, injection payloads, LLM prompting, and network latency were held constant between MCP and baseline conditions.The baseline used direct function calls with simulated network overhead matching MCP.
Controlled Variables: MCP transport latency was 12.4ms median for stdio and 23.7ms for HTTP/SSE, without a significant effect on safety refusal rates.A paired t-test reported p > 0.3 with n = 200.
Results: MCP architecture amplifies attack success by 23–41% depending on attack type.Table IV compares attack success rates for MCP-integrated agents and non-MCP baselines.
Sampling Results: Sampling attacks achieve 58–72% success, including 42–61% sensitive-context exfiltration and 31–44% persistence across sessions.The sampling mechanism creates an attack vector absent from non-MCP systems.

C. Multi-Server Trust Exploitation

Multi-server experiments examine cross-server trust exploitation and motivate protocol mechanisms for authentication, isolation, and capability governance. The proposed design uses a federated capability-authority model and explicit cross-server authorization.

Multi-Server Trust Exploitation: With five servers, one compromised server reaches 78.3% ASR and a 72.4% cascade rate.The cascade rate measures successful compromise of additional servers’ operations.
Mitigation Comparison: Prompt instructions reduce cross-server ASR from 61.3% to 47.2%, while ATTESTMCP reduces it to 8.7%.The comparison is presented as evidence that prompt-level defenses remain weaker than protocol-level isolation.
Protocol Design: ATTESTMCP adds capability attestation, HMAC-SHA256 message authentication, origin tagging, explicit cross-server authorization, and replay protection.These additions target arbitrary capability claims, unauthenticated messages, server-origin ambiguity, implicit information flow, and replay.
Trust Model Options: The implementation uses federated capability authorities operated by platform vendors with cross-signing agreements for interoperability.The model is described as balancing decentralization with operational simplicity.

C. Protocol Additions

The protocol additions combine authenticated capabilities and messages with replay protection and gradual-adoption modes. The design supports legacy migration while adding downgrade protection and reporting low per-message overhead.

Authentication: Capability certificates bind server identities to declared capabilities, while authenticated JSON-RPC messages bind content to the server identity.The example fields include server_id, capabilities, issuer, timestamps, expiry, and a signature or HMAC.
Replay Protection: Replay protection rejects duplicate nonces and expired timestamps using a 1,000-nonce sliding window with 30-second validity.Clients maintain the nonce window separately for each server.
Adoption Modes: ATTESTMCP supports permissive, prompt, and strict modes for progressively stronger handling of unsigned servers.The modes respectively warn, require user confirmation, or reject unsigned servers.
Downgrade Protection: Once valid credentials are observed, downgrade protection warns when later connections omit them.This is intended to prevent an attacker from stripping security headers from a previously authenticated server.
Performance: Median overhead is 8.3ms cold and 2.4ms with a warm cache per message.Certificate validation dominates cold-start overhead, while caching reduces repeated-call costs.

F. Effectiveness Evaluation

ATTESTMCP substantially reduces measured attack success, while the remaining risk and practical effectiveness depend on authorization behavior and deployment scope. The analysis also argues that protocol-level remediation is necessary because implementation fixes do not address these architectural weaknesses.

Effectiveness: 52.8% to 12.4%: ATTESTMCP reduces overall attack success rate by 76.5%.The largest improvements occur in cross-server and sampling attacks.
Limitations: ATTESTMCP does not address attacks from a legitimately authorized server that serves malicious content.
Limitations: ATTESTMCP does not address social engineering that persuades users to authorize malicious capabilities.
Limitations: Federated certificate authorities mitigate but do not eliminate compromise risk, while first-contact attacks remain unprotected in some cases.
Residual Risk: Residual 12.4% attack success primarily reflects indirect injection through legitimately retrieved content, a limitation shared with LLM systems generally.
User Behavior: 52.8% to 12.4% effectiveness assumes users carefully review cross-server authorization prompts, but alert fatigue may reduce real-world protection.
Architectural Scope: Patching individual vulnerabilities does not address capability-attestation absence, sampling injection, or missing cross-server isolation.

B. Limitations of This Work •

The work is bounded by its five-server evaluation, unverified extension design, adoption assumptions, and lack of adversarial bypass testing. Within those limits, it reports protocol-level architectural weaknesses and recommends corresponding protocol controls.

Evaluation Scope: The experiments used five MCP servers, so production deployments with dozens of servers may exhibit different characteristics.
Verification: ATTESTMCP has not been formally verified; symbolic model checking is reserved for future work.
Deployment: The federated certificate-authority model requires ecosystem coordination that may face adoption barriers.
Evaluation Scope: The study did not evaluate adversarial attempts to bypass ATTESTMCP itself.
Positioning: MCP’s architectural contribution extends prior work on inter-agent trust and complements prompt-level defenses by addressing the protocol layer.
Conclusion: 23–41%: MCP architecture amplifies attack success rates compared with non-MCP integrations, while ATTESTMCP reduces attack success from 52.8% to 12.4%.The reported median performance overhead is 8.3ms per message.
Conclusion: The recommended controls are mandatory capability attestation, origin tagging for sampling, and explicit user-authorized isolation boundaries.