Model Context Protocol (MCP) Security Architecture
Understanding the core architecture of Anthropic's open standard for AI tool integration, its transport mechanisms, and the associated threat vectors.
Model Context Protocol (MCP) functions as a universal plug-and-play standard connecting AI agents directly to local and cloud-based resources. Historically, integrating a model with external databases, APIs, or files required building custom API adapters for each tool. MCP standardizes this connection, acting as the USB-C standard for agentic architectures.
However, by bridging the cognitive reasoning of LLMs with structural files and APIs, MCP standardizes the attack surface as well. A single vulnerability in an MCP server exposes the entire agentic pipeline across the organization. Security teams must move beyond basic model safety checks and govern the protocol's runtime integrations.
The Client-Host-Server Model
The MCP standard defines three core components:
- MCP Host: The orchestrating application (e.g., Claude Desktop, Cursor, or custom enterprise agent runtime) where the user interacts and where the LLM's system prompts are defined.
- MCP Client: A protocol handler embedded in the Host that establishes a connection to servers, negotiates capabilities, and formats requests.
- MCP Server: Lightweight, modular programs exposing specific tools (REST calls, database queries, local scripts) and resources (logs, system files) via standardized JSON-RPC schemas.
How MCP Processes a Dynamic Request
1 / 4🤝 Session Handshake & Capability Negotiation
Upon startup, the Client and Server exchange `initialize` requests to negotiate supported capabilities (Tools, Prompts, Resources) and define schemas.
📋 Schema Matching and Parameter Binding
When the LLM decides to call an MCP tool, the Host matches the tool parameters against the JSON Schema advertised by the Server, validating types.
⚡ JSON-RPC Protocol Dispatch
The Host Client dispatches a JSON-RPC request to the Server (e.g., `tools/call` with argument bindings). The transport channel executes the message.
📦 Execution Isolation & Return Value
The Server executes the background operation (e.g., querying SQLite or hitting Slack API) and returns the structured result back to the Client Host.
Core Threat Vectors in MCP
1. Indirect Prompt Injection Propagation
If an MCP server fetches untrusted content (such as reading a web page, file contents, or database log), the return payload is injected directly into the LLM context. If this payload contains injection instructions, the agent re-plans its lifecycle, hijacking downstream tools to perform malicious operations.
2. The Confused Deputy Problem
Because MCP servers run with service tokens or elevated administrative permissions, an agent (acting as the deputy) can be manipulated via injection to execute privileged tools (like file deletion or credential queries) that the original human user is not authorized to call.
3. Transport Channel Risk (stdio vs SSE)
MCP supports two default transports:
- stdio: Local Inter-Process Communication (IPC) over standard input/output. Highly secure as it is limited to the local machine and requires local host credentials.
- SSE (Server-Sent Events): HTTP-based transport over network sockets. Sockets are susceptible to unauthenticated network access, cross-site request forgery (CSRF), and man-in-the-middle (MITM) data sniffing.
Click the card to reveal the explanation
Implicit Trust in Local Tool Registries
A developer pulls an unverified open-source MCP server to access Jira logs. Since MCP config files are simple JSON files on local disk, the server installs without warning or permission approvals.
The third-party MCP server has hidden dependencies that perform typosquatting package attacks. When initialized, the server exposes an undocumented 'system-report' tool. During a planning query, the compromised server outputs a hidden instruction that the agent reads and evaluates, forcing it to run the undocumented tool.
The tool reads local environment files (.env) and sends database passwords to an attacker's C2 endpoint. This highlights why local config directories require strict file integrity monitoring (FIM) and local registries must be locked down.
- Unvetted local MCP servers create direct pathways for Remote Code Execution (RCE)
- Implicit trust of local IPC enables silent lateral data collection
- Mitigated by disabling local user registries in favor of a centralized, signed company registry
Agents connect directly to stdio and SSE servers with raw JSON-RPC queries. Tool parameters are passed directly from model outputs to system shells. Local configuration files allow any user to add untrusted server plugins.
- No permission restrictions on tool execution: the agent can invoke any exposed shell command
- Compromised server outputs bypass intermediate validation, leading to instant context poisoning
- Local users install unmanaged tools, creating 'Shadow MCP' entry points
- Missing audit trails make post-incident forensics impossible
All MCP servers are centrally inventoried and run inside isolated network-less microVMs. The Host Client intercepts RPC calls, sanitizing parameters and matching credentials before tool execution.
- **Capabilities Restricting:** The host gateway restricts access to high-risk endpoints (like write/delete) based on user scopes
- **Output Sandboxing:** Observations fetched from the network are evaluated by a secondary validation LLM before ingestion
- **Signed Registries:** Only MCP servers signed with the company's private key are permitted to initialize
- **IPC stdio Enclosure:** Remote SSE servers are blocked; all servers run locally inside dedicated jail enclosures
Hardening Your MCP Deployment
1. Enforce Parameter Schema Verification
Do not trust the LLM to output clean arguments. The Host Client must validate that the parameter variables exactly match the server's published JSON Schema constraints (like string formats, enums, and regex filters) before executing the RPC request.
2. Enforce Least-Privilege IAM Bindings
An MCP server connected to PostgreSQL should never run as the `superuser` account. Configure the database connector with a read-only role limited strictly to tables containing public records.
3. Audit the Tool Consent Loop
Configure the Host client to display an interactive UI approval modal whenever high-impact tools (e.g., executing shell scripts, writing files, sending emails, or charging cards) are requested by the model. The tool execution should stall until a human clicks "Approve".
4. Network Egress Segmentation
If using SSE transport, wrap the connection in TLS 1.3 with mutually authenticated certificates (mTLS). Restrict the client container's network firewall to block outbound requests to any hostname not present on the connection allowlist.