MCP Security: Containing Blast Radius for Model Context Protocol Servers

Anthropic introduced the model context protocol in November 2024 to solve a real problem.¹ Before MCP, every AI application that needed to access an external tool required custom integration code. Model context protocol MCP replaced that fragmented plumbing with a standardized protocol, allowing any AI system to connect to any data source through a consistent interface.

The most common analogy compares MCP to USB-C: a single standardized connector that works with everything. That analogy is accurate, and it is exactly why MCP security matters so much. When one port connects everything, a problem with that port reaches everything.

By December 2025, more than 10,000 active public MCP servers had been deployed, with 97 million monthly SDK downloads across Python and TypeScript.² MCP adoption moved from niche developer tooling into mainstream agent infrastructure in under twelve months. The security controls did not keep pace.

Understanding MCP security starts with understanding how the MCP protocol operates. It uses a client-server architecture with three components.

The MCP Host

The host is the application running the AI model. It manages the overall environment and controls which servers the model can access.

How the MCP Client Sends Requests

The MCP client lives inside the host application and handles communication with external tools. When an AI agent needs to execute a task, the MCP client sends a structured JSON-RPC request to the appropriate server. The response passes relevant tool context back to the model for reasoning.

What the MCP Server Exposes

The MCP server wraps external tools and data sources, exposing them as executable functions the AI model can call. A deployment might expose file system access, database queries, API calls to external services, or direct access to cloud infrastructure. Each MCP server registers its available tools and tool descriptions with connected MCP clients during session initialization.

This separation looks clean on paper. In practice, a single MCP server is often the gatekeeper for dozens of sensitive resources simultaneously.

When Anthropic released the MCP specification, authentication was technically optional.³ The spec recommended OAuth 2.1 for authorization but did not require it. As a result, a December 2025 Bitsight research report found roughly 1,000 servers exposed on the public internet with no authorization controls.⁴

The first malicious MCP package appeared in September 2025, confirming that attackers had recognized the MCP ecosystem as an active target.⁵ CVE-2025-49596, rated CVSS 9.4, allowed attackers to execute arbitrary commands through unauthenticated MCP Inspector instances.⁵ Security researchers have documented command injection vulnerabilities and remote code execution paths in improperly configured deployments.

The OWASP MCP Top 10, published in 2025, was the first proper classification of MCP security risks, naming tool poisoning, prompt injection, and credential exfiltration as the top attack patterns.⁶

A malicious MCP server impersonates a legitimate server to manipulate AI agents into harmful actions. The attack surface is broad because these deployments are designed to access external systems.

Tool Poisoning and Malicious Instructions

Tool poisoning embeds malicious instructions inside tool descriptions. When the host retrieves tool descriptions during initialization, those descriptions can include hidden directives that redirect the AI agent's behavior. The model reads what it believes is documentation and follows it as instructions. Proper validation of tool registration is not optional in a production environment.

Prompt Injection Through External Data Sources

This attack vector does not require direct installation by the attacker. Prompt injection attacks deliver malicious instructions through content that a legitimate server reads from external data sources. The server processes a document or database record containing injected instructions, and the AI model treats those instructions as authoritative.

Credential and Data Exfiltration

Because servers commonly handle cloud credentials, SSH keys, API keys, and session IDs to authenticate with connected services, a compromised MCP server has direct access to those sensitive resources. The Cascade in March 2026 demonstrated this pattern at scale: a poisoned dependency harvested AWS, GCP, and Azure credentials from any Python process that loaded it, across a library used in roughly 36% of cloud environments.⁷

A local MCP server runs on the same machine as the MCP client and the AI host. Because it operates within the local environment, it is often treated as implicitly trusted. That assumption creates significant security risks.

Local deployments typically have file system access, the ability to execute shell commands, and direct access to environment variables containing cloud credentials and API keys. A server installed locally through a supply chain compromise or a typosquatted package inherits all of those permissions without needing to bypass network controls.

Local traffic communicates via standard input and output, which most security teams do not instrument. Remote server traffic at least traverses networks where inspection tools can observe it.

Several security concerns in the MCP architecture consistently receive less attention than they deserve.

The Exposed Tool Access Problem

Every MCP server exposes tools as executable functions. When an MCP client sends a tool call to the server, it is executing code against real external systems. Security teams that review application-layer controls but do not govern what servers expose are missing the actual attack surface.

Rug Pull Attacks on MCP Components

An operator can modify tool descriptions or tool behavior after deployment. An AI application that trusted a legitimate deployment at installation can find itself interacting with a fundamentally different service weeks later. The MCP protocol provides no mandatory mechanism for detecting this.

Session Identifiers and State Problems

Sessions use identifiers to maintain context across multi-turn interactions. If those session IDs are not properly protected, attackers can hijack existing sessions without needing separate credentials.

Access control in this environment is more complex than traditional network access control because the threat model is semantic, not just network-based.

At the network layer, each MCP server should be reachable only from the hosts and MCP clients that legitimately need it. East-west traffic enforcement prevents a compromised server from reaching cloud metadata endpoints, credential stores, or sensitive files it has no business accessing.

At the identity layer, policy needs to operate at the workload identity and application protocol levels, not at IP addresses and ports. A deployment calling GitHub should be permitted to reach specific repositories under a specific service account, not all of github.com.

Explicit user approval for high-risk tool calls is a security control the MCP specification itself recommends. Implementing it means classifying tools by risk level and routing destructive or irreversible operations through approval workflows before execution.

Most MCP security guidance is detection-oriented: log everything, alert on anomalies, respond to incidents. That advice is necessary but not sufficient.

82% of intrusions in 2026 ride valid credentials through legitimate channels, producing no anomalous signal.⁸ A compromised MCP server using harvested cloud credentials does not look like an attack. It looks like normal authenticated API traffic.

The Containment Era reframes the question. Instead of asking "did we detect the compromise?" it asks "what is the Blast Radius if this deployment is compromised right now?"

Blast Radius is the set of systems, data, and functions that compromised workload code can reach when it runs. For a server with access to production databases, cloud storage, and internal APIs, the Blast Radius without containment controls equals the breach cost of everything it can reach.

Communication Governance for MCP Server Environments

Communication Governance is the organizational and architectural capability to define, enforce, and audit what every workload can communicate with, on every path, under all conditions. Applied to MCP deployments, it means every server has an explicit policy defining which external systems it can reach, what identity it presents, and what data it can return to connected clients.

When that policy is enforced at the network layer rather than inside the application, it holds even when the server itself is compromised. The attacker controls the code. They do not control the network fabric the code runs on.

Detection-Independent Enforcement

Detection-independent enforcement means the policy holds before, during, and after a breach without requiring that the breach be detected first. Supply chain attacks like The Cascade arrive through trusted, signed code and produce no anomalous signal at the moment of compromise.

If enforcement depends on detection, the Blast Radius is already expanding by the time any alert fires.

The Aviatrix Cloud Native Security Fabric governs every workload communication path across every cloud, every VPC, every Kubernetes cluster, and every serverless function, from a single policy plane. For MCP deployments, this means network-layer enforcement that travels with the workload.

Aviatrix AgentGuard, now in early access, discovers every AI agent running across VMs, Kubernetes clusters, and serverless functions, including shadow agents and unauthorized deployments that security teams do not know exist. It maps the LLMs, tools, and data sources each agent connects to and builds a risk profile for every deployment in the environment.

Aviatrix has also published Validated Containment Architectures for enterprise MCP deployments, developed with Obot and Microsoft, providing lab-tested insertion patterns and baseline policy packs. As Shannon Williams, President of Obot AI, noted: "Every enterprise running AI agents is running MCP servers, often more than they realize. Without governance at the gateway and the network, a compromised agent's blast radius extends to everything those servers can reach."⁹

Inventory every MCP server running in your environment, including local deployments on developer machines. According to IBM's 2025 Cost of a Data Breach Report, breaches involving shadow AI cost an average of $670,000 more per incident, and 97% of organizations breached through AI lacked proper AI access controls.¹⁰

Enforce least-privilege network access for every deployment. No server needs unrestricted internet egress or access to cloud metadata endpoints outside its defined function. Scope this access at the network layer, where it survives application-layer compromise.

Run security assessments that specifically include MCP components. Most standard application reviews do not instrument MCP traffic or test tool descriptions for injected instructions.

Implement runtime monitoring for outbound connections from each MCP server. Destination diversity and connection volume are observable signals even without payload decryption.

The Aviatrix Threat Research Center tracks active campaigns and maps real-world attack paths for cloud workloads including AI agents, providing current threat intelligence for security teams evaluating their mcp security posture.

Model context protocol MCP is the infrastructure that enterprise AI is being built on. MCP adoption will continue accelerating as AI agents move from pilots into production. The question is not whether to deploy an MCP server. The question is whether those deployments will be governed when something goes wrong.

The security issues in the current MCP ecosystem are not primarily flaws in the protocol itself. They stem from the mismatch between how fast deployments are proliferating and how slowly security controls are following. Authentication is optional by default. Access control is typically absent. Runtime monitoring is uncommon.

Containment is the architectural answer. Limit the Blast Radius, and a breach stays a breach. Leave it open, and it becomes a catastrophic one.

Aviatrix is pioneering the Cloud Native Security Fabric, the architecture the Containment Era requires. The Cloud Native Security Fabric governs every workload communication path across every cloud, every VPC, every Kubernetes cluster, and every serverless function, from a single policy plane. One rule. Universal propagation. Enforced at the workload, not at a chokepoint. Trusted by more than 500 of the world's leading enterprises. For more information, visit aviatrix.ai.

1. https://modelcontextprotocol.io/docs/getting-started/intro

2. https://www.digitalapplied.com/blog/mcp-adoption-statistics-2026-model-context-protocol

3. https://siliconangle.com/2025/12/11/model-context-protocol-security-risks-grow-unsecured-servers-appear-across-internet/

4. https://siliconangle.com/2025/12/11/model-context-protocol-security-risks-grow-unsecured-servers-appear-across-internet/

5. https://www.practical-devsecops.com/mcp-security-guide/

6. https://www.practical-devsecops.com/mcp-security-guide/

7. https://aviatrix.ai/learn-center/the-containment-era/the-cascade/

8. https://aviatrix.ai/blog/threat-response-2026-containment/

9. https://aviatrix.ai/newsroom/press-release/containment-platform-for-ai-agents/

10. https://www.ibm.com/reports/data-breach