MCP stateless sessions open new endpoint attack surfaces

At a glance

What this is: This analysis says the next MCP spec shifts security risk from the network layer to the endpoint layer, where handle replay, filesystem scope loss, and IDE-rendered HTML can bypass existing controls.

Why it matters: IAM, PAM, and NHI teams need to treat MCP identities and handles as governable access objects, because the control points move when state is carried in conversation context instead of server-side session state.

By the numbers:

• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Backslash Security's analysis of new MCP spec attack surfaces

Context

MCP security is now an identity governance problem as much as a protocol problem. When the protocol moves session state into conversation context, the thing being governed is no longer just traffic between systems, but the portability of access itself across prompts, tool calls, logs, and shared transcripts.

The core issue is that the old enforcement points disappear while new ones become opt-in. That leaves security teams with an endpoint-layer trust boundary they may not currently inventory, monitor, or review, especially when MCP servers run locally on developer devices and the IDE becomes part of the attack surface.

Key questions

Q: What breaks when MCP access state moves into conversation context?

A: The main break is that access objects become portable, visible, and replayable in places session-based controls were never designed to inspect. If the handle is inside a prompt or log, it can be copied across users and requests unless the server validates identity, context, and expiry on every call.

Q: Why do MCP servers create governance problems for endpoint security teams?

A: Because the effective control boundary moves onto the developer endpoint, where local files, IDE rendering, and tool execution all sit outside network inspection. That makes MCP a governance issue for both identity and device policy, especially when servers run locally and can reach secrets on the workstation.

Q: What do security teams get wrong about filesystem controls in MCP?

A: They assume filesystem scope is still structurally enforced when in fact it may be optional and inconsistent across servers. Once the protocol no longer provides a common boundary, path restrictions become a local implementation decision, which is far easier to miss during review and much harder to detect centrally.

Q: Who is accountable when a server-rendered MCP interface tricks a developer?

A: Accountability sits with the organisation that approved the server, the team that allowed endpoint-level rendering, and the governance function that failed to classify the IDE as part of the trust boundary. Once interactive HTML can trigger tool calls, standard web assumptions no longer protect the user.

Technical breakdown

Stateless MCP sessions and handle replay risk

In the new MCP model, the server no longer maintains a sticky session that can be invalidated centrally. Instead, the client carries portable handles inside the conversation, which makes the handle itself part of the security boundary. If the server does not bind that handle to the original user and context, any leaked string can be replayed from a different request path. That is a different failure mode from classic session hijacking because the sensitive value is now visible to the model, logs, and collaboration tools. The protocol has shifted from opaque server-managed state to conversation-held access material.

Practical implication: Bind every handle to user context and expiry, and treat conversation leakage as a direct access-control issue.

Filesystem scope gaps after Roots is removed

Roots used to provide a structural way to constrain which paths an agent could reach. Once that capability disappears, filesystem scope becomes an implementation choice, not a protocol guarantee. That matters because local file access is where credential stores, .env files, and API keys often sit. Without a common enforcement point, one MCP server may enforce path limits while another quietly exposes the whole workstation. The control failure is not that the agent is clever. It is that scope is now fragmented across server authors instead of enforced by the protocol itself.

Practical implication: Inventory every MCP server's filesystem boundaries and treat missing path controls as a direct exposure of secrets and local credentials.

MCP Apps and trusted HTML inside the IDE

MCP Apps introduces interactive HTML rendering inside the development environment, with tool calls triggered from within an iframe. That changes the trust model because the IDE is not a browser with mature origin protections and user caution cues. A malicious or compromised server can present UI that looks native, solicit credentials, and steer actions back into the server context. The risk is endpoint-local UI deception, not network intrusion. In practice, the browser security model cannot be assumed simply because HTML is involved. The rendering context is the IDE, which has privileged access to code, terminals, and connected tools.

Practical implication: Review rendered MCP UI the same way you would third-party web content, and restrict which servers may ship interactive HTML.

Threat narrative

Attacker objective: The attacker wants to turn conversation-held state and local endpoint trust into unauthorized access to secrets, data, or actions.

1. Entry occurs when a handle, filesystem path, or rendered UI element is introduced into the conversation or IDE from an MCP server.
2. Escalation occurs when the agent reuses a portable handle, reaches beyond intended filesystem scope, or follows a deceptive server-rendered interface.
3. Impact occurs when secrets, credentials, or privileged local data are accessed or exfiltrated from the endpoint without network-layer visibility.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Stateless access breaks the assumption that identity state stays server-side. MCP's move from session IDs to handles reverses a long-standing control premise: that access state is stored and enforced outside the model's conversational surface. Once the handle lives in prompts, tool outputs, and logs, the access object becomes portable in ways classic session governance was not built to absorb. The implication is that identity teams must stop treating conversation context as a neutral transport layer and start treating it as part of the access control plane.

Filesystem scope without a structural boundary is only policy, not enforcement. Roots existed to make scope real at the protocol level, which is why its removal matters more than a simple feature deprecation. The security failure here is not merely broader reach. It is that scope now depends on each server developer implementing it correctly and consistently, which is exactly where drift and blind spots appear. Practitioners should read this as a governance collapse in the chain between intent and enforcement.

IDE-rendered MCP Apps create an endpoint trust inversion. The security model changes when a server can present interactive HTML directly inside a privileged development environment. That means user judgement, browser sandboxing habits, and web origin assumptions all lose force at the point of highest local privilege. The category is not web app security and not traditional DLP. It is endpoint identity and trust propagation through a tool the user already believes is part of their working environment.

Handle validation and filesystem review now belong in NHI governance, not just platform engineering. MCP makes access portable, but portability is only safe if the receiving system verifies who is using the handle, whether it is still valid, and what scope the request can touch. This is a familiar NHI lesson applied to a new protocol surface: when access objects travel, lifecycle controls must travel with them. Teams that do not extend governance to local MCP servers will miss the places where state now lives.

Endpoint visibility becomes the deciding control plane for agentic tool use. Network gateways were never designed to inspect handles inside conversations or UI rendered inside an IDE. That means detection, review, and containment shift to the host process, local server inventory, and endpoint policy layer. The broader lesson is that agentic systems are not only expanding the number of identities in play. They are relocating the trust boundary, and security programmes need to follow that move deliberately.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface.
• Our research also found that only 44% of organisations have implemented policies to govern AI agents, leaving most deployments ahead of policy maturity.
• For a broader identity baseline, see Top 10 NHI Issues for the governance gaps that recur across machine and agent identities.

What this signals

Conversation-held access is the new governance boundary. If your programme still assumes access state lives only in a server-side session store, MCP-style protocols will bypass that assumption the moment handles move into prompts, logs, and shared workspaces. That is why endpoint inventory and identity lifecycle review now belong together, not in separate workstreams.

The practical signal is that security teams need to map where local tooling can reach secrets, rendered UI, and executable context before adoption spreads further. The risk grows faster than most control refresh cycles, so review cadence needs to move from periodic to change-driven.

For teams building policy around agentic systems, the most useful question is no longer whether the network sees the traffic. The better question is whether the endpoint can prove who holds the handle, what it can reach, and when it should stop working.

For practitioners

• Bind handles to user context and expiry Require every portable handle to validate the creating user, the current requester, and the expected lifetime. Treat any handle that can be reused from a different context as a replayable access object, not a harmless identifier.
• Inventory every local MCP server and its filesystem scope Map which MCP servers run on developer endpoints, what paths they can touch, and whether scope enforcement is structural or optional. Prioritise any server that can reach credential stores, .env files, or other secret-bearing locations.
• Review MCP Apps as privileged endpoint UI Approve only the servers allowed to render interactive HTML in the IDE, and define review criteria for UI mimicry, credential prompts, and action-triggering controls. Treat iframe content as trusted code only after inspection, not by default.
• Extend NHI governance to conversation-held state Add handles, requestState blobs, and other conversation-embedded access artifacts to your access review and incident response procedures. The review target is no longer just a server session store but the full path where access state can be copied or replayed.

Key takeaways

• MCP's stateless redesign turns conversation context into an access-control surface, which breaks assumptions behind classic session governance.
• Removing structural filesystem boundaries shifts scope enforcement from the protocol to individual server developers, creating inconsistent protection for secrets and local files.
• Endpoint visibility, handle validation, and IDE UI review now matter as much as network controls for MCP risk reduction.

Key terms

• Portable Handle: A portable handle is a reference string that carries access state across requests instead of relying on a server-side session. In MCP-style systems, the risk is that the handle can be copied, replayed, or exposed in conversation context unless it is bound to user identity and expiry.
• Filesystem Scope: Filesystem scope is the set of paths an agent or server is allowed to touch. In MCP, it is a governance control for local files and secrets, but when it is not structurally enforced it becomes an implementation choice that can drift across servers and environments.
• Endpoint Trust Boundary: The part of the security model where a device is treated as sufficiently trusted to hold or use sensitive data locally. For offline vault access, the endpoint becomes part of the identity control plane, so device loss, reassignment, and malware risk all matter.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.

What's in the full article

Backslash Security's full post covers the endpoint-level detail this analysis intentionally leaves for the source:

• A deeper walkthrough of the new MCP stateless model and the exact handle replay conditions it creates.
• The full filesystem-scope discussion, including how Roots removal changes enforcement across local and remote servers.
• Specific examples of MCP Apps UI abuse patterns, including credential mimicry inside the IDE.
• The article's before-July-28th checklist for teams that need to inventory local servers and review exposure.

👉 Backslash Security's full post covers the stateless session change, filesystem scope gap, and MCP Apps risk in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.