MCP security conversations this week are about to get more complicated.
On July 28, 2026, the Model Context Protocol specification transitions to a stateless architecture. The change eliminates a class of known vulnerabilities, including session hijacking at the protocol level, and Akamai's security researchers published the most detailed technical analysis of the transition available anywhere. Their findings are accurate. The new MCP architecture shifts security responsibility from the protocol layer to the developers building MCP servers, and that shift introduces five documented attack surfaces: workflow hijacking via predictable tracking IDs, header-body desync attacks, secrets leakage through x-mcp-header, hit-and-run denial-of-service against async tasks, and cross-site scripting through MCP UI panels.
The analysis stops there. What it does not address is what happens at the network layer when those implementation flaws are present inside your cloud environment, and that is the part that determines Blast Radius.
What MCP Architecture Actually Looks Like in Production
MCP is an open standard released in late 2024. It uses a client-server architecture: the MCP client is the AI application requesting external context, and MCP servers are the components that expose external tools, databases, and services as callable functions. By December 2025, more than 10,000 public MCP servers were in active deployment, with 97 million monthly SDK downloads across Python and TypeScript.
In practice, most enterprises are running more MCP servers than their security teams have inventoried. Each server connects to external data sources, handles API keys and OAuth tokens for multiple services, and exposes tool descriptions that MCP clients use to decide what to call. MCP servers aggregate OAuth tokens for multiple services simultaneously. That concentration is what makes a single compromised server a credential exfiltration event rather than an isolated incident.
The MCP specification's client-server architecture is not the security problem. The absence of mandatory authentication and the assumption that implementation quality will be consistent across every MCP server an enterprise runs are the problems.
What the MCP 2026-07-28 Specification Changes, Precisely
The July 28 update moves the protocol to a stateless model. Instead of maintaining persistent sessions, MCP servers now issue tracking identifiers and state objects that the client holds and passes back on each request. The protocol eliminates server-side session management. Security boundaries that the old protocol enforced at the session layer now depend entirely on how each individual MCP server implements the new specification.
That is the correct architectural direction for enterprise-scale MCP deployments. It is also a transfer of security risk from the protocol to the implementation layer, which varies across every server in your environment.
The 12-month deprecation window for legacy functionality means that for the rest of 2026, production MCP environments will contain a mix of old and new implementations running concurrently. The security posture of your MCP deployment will be as consistent as the least-careful implementation in that mix.
Malicious MCP Servers and Command Injection: The Threat the Spec Update Does Not Fix
The new specification eliminates protocol-level session hijacking. It does not address the threat categories that have made malicious MCP servers a documented attack surface since late 2025.
The OWASP MCP Top 10 identifies tool poisoning as the leading risk: attackers embed malicious instructions inside tool descriptions, which the MCP client reads during initialization and treats as legitimate directives. CVE-2025-49596, rated CVSS 9.4, demonstrated remote code execution via unauthenticated MCP endpoints before the specification update. Command injection vulnerabilities in MCP implementation have been documented by security researchers across multiple server codebases. A local MCP server running on a developer machine with file system access and shell execution capability is a significant attack surface regardless of which version of the specification it implements.
5.5% of analyzed MCP servers in published research showed tool poisoning vulnerabilities. In an enterprise running 200 MCP servers, that is 11 servers with documented manipulation vectors available to any AI model that connects to them. The July 28 update does not patch those 11 servers. It changes the session model.
MCP Security Threats That Live Below the Application Layer
Once an MCP client sends a request and the server calls an external tool or data source, that traffic traverses the network. It moves east-west between services inside your cloud environment. It crosses VPC boundaries. It hits managed cloud services and external APIs. None of that is governed by how well the developer implemented the new stateless session model.
A compromised MCP server, whether through tool poisoning, command injection, a supply chain attack on a dependency, or a modification to tool descriptions after deployment, will attempt data exfiltration using the credentials and network access the server already has. The Cascade in March 2026 demonstrated this at scale: a poisoned dependency in LiteLLM harvested AWS, GCP, and Azure credentials from every Python process that loaded it, using legitimate authenticated channels that produced no anomalous signal.
Detection does not catch this. The traffic looks like normal authenticated API calls because it is normal authenticated API calls, made by compromised code that the identity layer has no reason to question. What stops it is governing what the MCP server can reach at the network layer, before the compromise happens, independent of whether it has been detected.
MCP Network Layer Security: The Control That Holds
MCP network layer security means enforcing explicit, per-server egress policy at the workload level. Not at a centralized gateway that MCP traffic can route around. Not as a developer-implemented access control that depends on implementation quality. At the network fabric itself, where every egress connection from every server is evaluated against a policy before it leaves.
Per-server scope
A GitHub MCP server should reach api.github.com and nothing else. An MCP server handling medical records should reach the EHR system it was built for and nothing beyond it. Two MCP servers in the same Kubernetes namespace get different egress policies based on workload identity, not IP addresses. Kubernetes NetworkPolicy cannot enforce this. Service mesh sidecars do not cover MCP tools that run as standalone processes or in serverless functions.
Detection-independent enforcement
The policy holds before the breach, not after it is detected. A compromised MCP server attempting to reach an attacker-controlled domain finds no network path to that destination. The route does not exist, regardless of what credentials the code holds or what the MCP specification version is running.
Coverage across compute models
Local MCP server deployments on developer machines, containerized servers on EKS or AKS, serverless MCP implementations on Lambda: each runs in a different compute environment. The network enforcement layer needs to reach all of them without requiring an agent on every workload or a sidecar on every container. This is what Aviatrix's Cloud Native Security Fabric delivers: agentless enforcement at the network layer, covering every compute model without per-workload installation.
Three Things to Verify Before July 28
Inventory every MCP server in your environment, including local MCP server deployments on developer machines that your platform team did not sanction. Aviatrix AgentGuard surfaces shadow agents and unauthorized MCP deployments using network flow and DNS telemetry, without requiring gateway insertion or code changes.
Map east-west traffic from each server. For every MCP server you find, identify what it can reach inside your cloud environment: across VPCs, to managed cloud services, to credential stores. That reachability map is the current Blast Radius. Aviatrix AgentGuard can also help with this east-west traffic discovery.
Enforce network-level containment before the deprecation window closes. The 12-month window for legacy MCP functionality means mixed implementation quality through mid-2027. Network-layer enforcement that applies uniformly regardless of implementation version is the only control that covers the full mixed state.
The MCP 2026-07-28 specification is a genuine improvement. It removes protocol-level risks that needed removing. What it cannot do is govern where MCP traffic goes once it is moving through your cloud environment. That has always required a different layer. July 28 does not change that.
Explore the security risks of rapid AI tool adoption and what security teams can do about them.
Discover how the Aviatrix-Obot partnership secures enterprise MCP servers.
Frequently Asked Questions
The update removes protocol-level session hijacking by moving MCP to a stateless architecture. It does not fix tool poisoning, command injection, or supply chain attacks inside MCP servers. Those risks depend on how each server is built, not on the protocol version. Enterprises still need to secure the implementation layer and the network layer separately.
A compromised server uses credentials and access it already has. Its traffic looks like normal authenticated activity because it is normal authenticated activity, just initiated by compromised code. This is what happened in the LiteLLM supply chain incident in March 2026. Governing what a server can reach at the network layer, before any compromise occurs, closes this gap.
Three things: inventory every MCP server in the environment, including unsanctioned local deployments; map what each server can reach across VPCs and managed cloud services; and enforce egress policy at the network layer so that reachability holds steady no matter which implementation version a given server is running.
Ready to see Aviatrix in action?
Get a personalized live demo walkthrough or explore our latest deep-dive cloud threat research intelligence.
Gartner Strategic Roadmap for Zero Trust Security Programs 2025 Report
Download and gain actionable insights to advance your cloud security strategy.
