The Model Context Protocol received its biggest overhaul in July, and the security consequences now deserve greater attention. Most discussion has focused on easier scaling, cleaner HTTP deployment, stronger authorization support, and more flexible extensions. However, the deeper change is that MCP security can no longer depend heavily on a persistent session boundary.
The July 28 specification removed the handshake and session model that previously connected clients with particular server instances. Every request now carries its own protocol details, client information, and capabilities before reaching whichever server handles it. That architecture improves reliability, but it also forces security teams to examine each request as an independent trust decision.
This matters because enterprise agents increasingly connect directly with databases, developer tools, internal systems, and sensitive business applications. When those agents act across several services, a compromised request can travel farther than ordinary application traffic ever could. MCP security therefore becomes less about protecting one connection and more about continuously validating every action an agent attempts.
The scale behind that change is already significant, rather than something enterprises can postpone until another technology cycle. MCP maintainers say Tier One software development kits now generate almost half a billion downloads during each month. Censys also identified 12,520 internet-accessible MCP services during April, including systems exposing sensitive data and administrative functions.
Those figures explain why security researchers have become increasingly concerned about how quickly MCP deployments are reaching production environments. The NSA warned in May that MCP adoption requires careful implementation because powerful agent workflows can touch sensitive information. That guidance arrived before the July specification removed sessions, making the newer architecture especially important for security planning today.
Stateless architecture gives platform teams something they wanted because requests can move freely across ordinary load-balanced infrastructure. Servers no longer require sticky routing or shared session stores simply to remember which client started an interaction. Yet MCP security must now follow the request itself, because the transport layer remembers considerably less than before.
Portable handles illustrate that shift clearly because applications can still preserve state without maintaining protocol-level sessions between calls. A server can issue an identifier, while the model carries that handle into later requests requiring the same state. The convenience is useful, although security teams must treat those handles like sensitive credentials rather than harmless conversation text.
That becomes dangerous when prompt injection enters the workflow through tickets, documents, webpages, or responses from connected tools. Malicious content could persuade an agent to expose, reuse, or forward a handle during an otherwise legitimate interaction. Network monitoring may never recognize the problem because the damaging decision can happen inside the agent’s application context.
MCP Apps create another important boundary by allowing servers to deliver interactive interfaces rendered inside compatible artificial intelligence clients. That feature can make agent workflows richer, because users can interact with generated interfaces instead of plain tool responses. However, MCP security must now consider hostile interface content alongside traditional risks involving tools, prompts, and connected resources.
Sandboxing can reduce damage from malicious interface code, although it does not make every rendered component automatically trustworthy. Artificial intelligence clients may sit beside source code, filesystems, terminals, credentials, and connections with several other MCP services. A compromised interface therefore deserves the same scrutiny organizations already apply to untrusted scripts entering important business applications.
Authorization has improved substantially, with the new specification hardening identity flows and aligning implementation more closely with established standards. Tokens can be bound more carefully to intended issuers and servers, reducing opportunities for unsafe credential reuse elsewhere. Even so, stronger standards only help when teams configure them correctly and validate authorization on every important request.
That requirement changes how organizations should think about gateways positioned between artificial intelligence clients and connected enterprise services. A gateway cannot simply authenticate an agent once and assume every later request deserves identical access automatically. Effective MCP security requires repeated identity, scope, audience, and authorization checks whenever tools receive actions carrying meaningful consequences.
Endpoint visibility also becomes more important because several emerging risks occur beyond the areas network security products understand best. Teams need awareness of local MCP servers, client rendering behavior, tool execution, and interactions happening inside development environments. Without that context, organizations may successfully secure network traffic while missing dangerous behavior occurring after approved requests arrive.
Testing practices should change for similar reasons, because ordinary unit tests rarely reproduce complete agent behavior across realistic workflows. A server may pass isolated tests while handles leak between scopes or unexpected interface content appears during execution. Security teams should test migrated deployments with real models, realistic permissions, and representative tools before assuming production behavior remains safe.
The July specification also started a formal deprecation window affecting older features and the legacy HTTP streaming transport. Roots, sampling, and logging remain available temporarily, but new implementations should avoid depending heavily upon those deprecated capabilities. Organizations now have at least twelve months before removal, creating time for deliberate migration rather than hurried replacement work.
That migration should not become a simple protocol upgrade handled entirely as another platform engineering maintenance task. The new design changes where trust decisions happen, meaning yesterday’s security architecture may not match today’s operating assumptions. Companies adopting the new version should review authorization, handle validation, rendered interfaces, and endpoint monitoring together during migration.
The most important lesson is that MCP security has moved closer to the actual decisions agents make during work. Stateless infrastructure improves scale, but it also removes assumptions security teams could previously attach to persistent transport sessions. Enterprises treating this shift seriously will be better prepared as agent systems gain wider access across critical business environments.
