Stateless MCP moves security enforcement to the endpoint

MCP’s scaling upgrade is also a security-architecture migration

The July 28 Model Context Protocol revision makes enterprise agent infrastructure easier to scale, but it also removes a boundary that many security decisions previously relied on. The release, MCP’s largest revision since its initial launch, introduced stateless operation over ordinary HTTP, OAuth-native authorization, and server-rendered interfaces through MCP Apps. Its 12-month deprecation clock also started that day, putting affected platform teams on a migration path through at least mid-2027.

That migration began amid rapid adoption. All four Tier 1 SDKs supported the version by the end of its first day, while Cloudflare provided day-zero support through its Agents SDK and said customers including Sentry and Linear adopted it straight away. Cloudflare has a commercial interest in MCP adoption because it provides infrastructure for building agents through that SDK. Across the wider ecosystem, MCP’s Tier 1 SDKs clear close to half a billion downloads each month, while its TypeScript and Python SDKs have each exceeded one billion total downloads.

That scale makes the architectural consequence more important than release velocity. Experience from two years of building agent systems that connect enterprise tools through MCP shows that the revision transfers more security enforcement from protocol sessions to endpoints and the developers operating them. Stateless MCP makes enterprise-scale agents practical on commodity infrastructure, but the same design changes where identity, state, content, and execution have to be trusted.

As those responsibilities move, a superficially successful protocol upgrade can preserve security controls built for the previous architecture. A team can migrate its servers, adopt OAuth, and scale horizontally while retaining controls that depend on persistent sessions and network visibility. The governing principle of the new design is explicit: “The protocol does not enforce security for you.” Migration therefore has to account for where that enforcement went.

Stateless MCP removes the session as the control boundary

The first place enforcement moves is the session. Under the stateless design, an MCP session no longer determines where a request belongs: the Mcp-Session-Id header and the initialize/initialized handshakes that previously connected a client to a particular server instance are removed. Protocol version, client information, and client capabilities instead travel inline with every request, so any compatible server instance can handle the next call.

That request independence makes the design attractive at scale. Traffic can move through round-robin load balancing, and instances can be added or removed through autoscaling without preserving an MCP conversation on a specific machine. Application state that must survive between calls can travel through portable handles, references that carry state between tool calls, rather than residing implicitly in a transport session. Infrastructure can consequently treat MCP requests much more like independently routable HTTP work.

Because requests are now independent, security decisions that once lasted for a session have to be established at the appropriate new boundary. A gateway could previously approve a client when a session began and carry that decision forward within the session context. With independent calls, each request has to carry enough information for the receiving system to decide how to treat it.

The same movement appears across the revision’s main changes:

The Tasks extension makes the identity consequence especially clear. A long-running task can outlive the connection that initiated it, so its authorization needs an identity that persists after the connection ends. The task can then remain bound to that identity, with its permitted scope enforced whenever subsequent activity refers to it.

The same need for explicit binding applies to portable state. Because state moves between calls, possession of a state reference becomes security-relevant independently of the transport that delivered it. The endpoint receiving the reference therefore has to validate both the reference and the identity presenting it.

These changes mean a platform team can implement the July 28 protocol correctly while keeping security assumptions tied to sessions. A session-dependent gateway paired with stateless servers preserves controls whose original trust context has disappeared. Statelessness improves scaling precisely because requests become independent, and that independence requires enforcement to follow them.

The old security baseline was already under strain

The movement of enforcement matters because MCP security problems were visible before the control model changed. Existing concerns included permissive MCP servers, deployments without authentication, and tool poisoning, in which malicious tool descriptions or outputs influence an agent’s behavior. The July 28 revision changes where defenses have to intercept these risks while adding state portability and client-side rendering to the environment security teams must govern.

Censys supplied one measure of existing exposure in a late-April scan, finding 12,520 MCP services accessible from the public internet. That exposure sat alongside MCP’s characteristic of requiring no authentication by default. Public reachability alone does not establish exploitability, but the finding shows why implementers need authentication and authorization as explicit application controls.

OX Security reported a different problem in MCP’s STDIO transport, estimating that a single design flaw put as many as 200,000 servers at risk. STDIO runs MCP communication through a process’s standard input and output rather than over a conventional network transport, making the finding relevant to endpoint security as well as server security. Its location also shows a key limit of network defenses: significant MCP behavior can occur locally on a host.

That local risk sat beside broader warnings as adoption grew. By May, the NSA’s Artificial Intelligence Security Center had published MCP guidance warning that adoption had moved faster than the protocol’s security model. Backslash and Akamai separately mapped attack-surface changes associated with the newer specification; both companies sell security products and services, so they have a commercial interest in demand for defenses against those risks. Microsoft’s research into tool poisoning adds a related mechanism: an agent that can act through connected tools can turn manipulated instructions into consequential actions elsewhere.

Against that existing baseline, the July 28 design places more decisions in individual requests, applications, and hosts. Permissive access and poisoned content remain relevant, while portable state and client-side rendering create additional decisions outside a persistent transport session. Security teams therefore need controls wherever identity, state, content, or execution becomes meaningful.

Three endpoint surfaces show the limits of request authorization

That need can appear to have a simple answer: use standard OAuth correctly, put an identity-aware gateway in front of every MCP server, and authorize every request. Independent calls do need independent authorization, making those controls necessary. Yet three endpoint surfaces require decisions beyond whether the caller has permission to make the server request: rendered content, portable state, and execution associated with an authenticated identity.

MCP Apps expose the rendered-content surface. An MCP server can provide interactive HTML for the AI client to render, placing server-supplied application content inside the environment where a user works with an agent. The content runs inside a sandboxed iframe, which constrains its behavior, but the client still renders it after the gateway has approved the MCP request.

Once rendering occurs in the client, stored cross-site scripting, or stored XSS, becomes a concern: malicious HTML or JavaScript is saved and later executed when someone views the stored content. An attacker can persist such content through an MCP tool; later, an agent or another user retrieves and views it, causing the code to execute inside the app interface. The iframe sandbox limits a complete takeover, yet the surrounding AI client operates above sensitive resources that can include source code, terminals, filesystems, and other connected MCP servers.

Because authorization precedes that rendering step, security teams need a separate content decision about what an authorized server may cause the client to display and how that content can behave in the host environment. Backslash and Akamai’s mapping of the new attack surface applies here, with their commercial security interests disclosed above. The endpoint has become part of the effective security perimeter.

Portable handles create the second endpoint surface. A handle carries state explicitly between tool calls, but at the conversation layer it is a string that can be copied or inserted into another context. Anyone who obtains the relevant string may be able to present state that would previously have been associated implicitly with an established session.

Prompt injection can provide the path by which such a handle moves. A malicious instruction embedded in a Jira ticket, for example, can be consumed by an agent, while a tool response gives injected material another entry point. If the instruction causes a valid handle to be disclosed, copied, or planted where another actor can use it, an instruction-integrity problem becomes a credential-like state-possession problem.

That sequence separates the enabling mechanism from the delivery mechanism. Portable state makes a handle reusable across calls, while prompt injection can move that handle into the wrong context or hands. Conversation hygiene can reduce exposure to planted instructions, while ownership still has to be established independently when the handle is presented.

Handle validation therefore belongs on every request that uses one. An endpoint has to check the presenting identity against the identity for which the handle was issued and enforce the intended scope. Without that binding, a correctly authenticated OAuth principal could present application state belonging to another identity or scope, so request authentication would succeed while application authorization failed.

OAuth forms the third part of the model because those independent requests need reliable identity. OAuth-native authorization gives MCP standard identity flows, while OAuth 2.1 with PKCE protects the authorization flow against important interception and code-substitution scenarios. Per-client consent and strict redirect-URI matching further restrict where authorization can go.

That identity control also depends on token audience. A token issued for one MCP server must be rejected by another because acceptance across unrelated MCP services would broaden the access created by a token disclosure. An identity-aware gateway can validate the audience on every incoming server request and reject a token intended for a different server.

Long-running Tasks carry the same identity requirement beyond the lifetime of a request. Asynchronous work can continue after the initiating connection ends, so ownership needs to attach to an identity and authorized scope. Later calls that query, modify, or consume the task can then be evaluated against that persistent authorization relationship.

Together, these controls make OAuth plus an identity-aware gateway a strong request-authorization baseline, while the other surfaces still need their own controls. Malicious HTML reaches a client for rendering, local MCP servers can act on a workstation, and an IDE can execute subsequent operations without generating another gateway event. Handle ownership likewise requires explicit application binding between the handle, identity, and scope.

The resulting threat model follows the full path of agent action. Each independent request needs an authorization decision, each portable handle needs integrity and identity checks, and each rendered interface brings content under client governance. As agents gain authority to act through tools, Microsoft’s tool-poisoning findings make those distinctions operationally important because compromised instructions and state can lead to actions.

The network boundary now ends before relevant MCP activity does

Those endpoint surfaces also create a visibility gap. A gateway can know that an authenticated principal sent an authorized request to the intended MCP server, while subsequent activity continues inside an AI client, local server process, or IDE. Such activity occurs on the endpoint and may produce no additional gateway request for a network control to inspect.

MCP Apps make that visibility limit concrete because the client renders their HTML after receiving it. Local MCP servers present the same limit when operations remain on the host, while IDE execution can act on code or tool results within the developer environment. An identity-aware gateway can enforce each request correctly while lacking direct knowledge of these later events.

Network-only security therefore leaves part of the execution path outside its field of view. A gateway that remembers old session state has an additional mismatch because independent MCP calls no longer provide the session boundary on which that policy depends. The architecture needs visibility and enforcement where state is presented, content is rendered, and local execution occurs.

Migration controls have to follow requests, handles, UIs, and execution

Because rendering is now part of the security perimeter, migration should begin by identifying which MCP servers can send HTML interfaces into clients and IDEs. Teams need an inventory of those rendering paths and a policy for reviewing the HTML those servers deliver. A useful standard is the scrutiny applied to third-party scripts sent to a production website: teams need to understand what externally supplied code can do in the environment where it executes.

With rendering paths identified, gateway design can move from session assumptions to individual requests wherever session state currently influences access decisions. Each MCP call needs inspection and enforcement, with OAuth 2.1 plus PKCE, per-client consent, strict redirect-URI matching, and audience-bound tokens forming the hardened authorization model. An identity-aware gateway should sit in front of every server and reject requests whose tokens are missing, invalid, or intended for a different audience.

After request identity is established, portable handles need their own trust rule because OAuth validation does not establish ownership of arbitrary application state. Treat every handle as untrusted input and verify that its presenter is the identity to which it was issued, including the relevant scope. At the conversation layer, remove or flag instruction-like content in retrieved documents and tool outputs because these are entry points through which an injected instruction or planted handle can reach an agent workflow.

Those request and state controls then need endpoint observability for activity beyond gateway visibility. Instrument the host process, local MCP servers, and client rendering so security teams can observe behavior after authorized data reaches the endpoint. Organizations whose existing MCP controls are entirely network-based need this host-side coverage for local operations and MCP Apps rendering.

With the enforcement points in place, testing has to follow execution into the live agent loop: the repeated cycle in which a real model interprets context, invokes tools, receives results, and chooses its next action. Unit tests can establish that an individual server implements the new protocol correctly, while interactions driven by model decisions emerge only when multiple systems operate together. Run migrated servers with real models performing real workflows, then check for state leaking between server instances, handles being reused across scopes, and UI content appearing where it was not expected.

The deprecation schedule gives this migration a defined platform window. Roots, sampling, and logging are deprecated under the revision, along with the legacy HTTP+SSE transport, which is described as forcing migration work for most platform teams. The 12-month deprecation policy began on July 28, putting the earliest stated removal point in mid-2027 and giving teams a period in which to move enforcement to requests, add endpoint controls, and govern MCP Apps before their use spreads further.

Key executive takeaways

• Move security enforcement to each request: Stateless MCP removes the persistent session as a control boundary, enabling load balancing and autoscaling while shifting authorization decisions to individual calls. Platform teams need request-level inspection, identity checks, and scope enforcement across MCP servers.
• Reassess the existing MCP security baseline: Publicly exposed services, unauthenticated deployments, local STDIO risks, and tool poisoning already create enterprise exposure. Security owners need to account for these risks as portable state and client-side rendering expand the surfaces under their control.
• Secure identity, state, and rendered content separately: OAuth and identity-aware gateways establish who may call an MCP server, while portable handles and MCP Apps create additional trust decisions. Bind handles to identity and scope, govern server-provided HTML, and enforce task ownership throughout asynchronous workflows.
• Extend visibility beyond the network: MCP activity can continue inside AI clients, local servers, and IDEs after an authorized gateway request completes. Security teams need endpoint telemetry covering local execution and rendered MCP Apps to observe that part of the agent workflow.
• Use the migration window to redesign controls: The deprecation schedule gives platform teams through at least mid-2027 to replace session-dependent controls and legacy transport assumptions. Migration plans should combine per-request authorization, handle validation, rendering governance, endpoint observability, and live agent-loop testing.