MCP Is Growing Up

Our team spends much of the week talking to security leaders and practitioners who are trying to figure out where their agents’ access ends and their exposure begins. One common theme is the nascent nature of all this technology, including Model Context Protocol (MCP). Model Context Protocol has rapidly become the preferred mechanism to interconnect models and agents and tools, despite its self-evident limitations. This summer, MCP dropped its early, ad-hoc plumbing, meant for local access, in favor of design changes that more closely reflect enterprise application infrastructure patterns. These patterns enable scale, high availability, and reliability. Session-based connectivity gave way to a stateless core, long-running work got a proper asynchronous solution, and OAuth gained a standard enterprise single sign-on grant. Each of these changes is a forward leap toward enterprise-grade requirements. None of them, on their own, make an agent more trustworthy. That distinction is easy to lose in the hype.

The Consensus: MCP Is Growing Up

MCP is graduating from a fledgling, albeit clever way to connect a model to a few tools, into infrastructure that can actually run at scale. The 2026-07-28 specification removed protocol-level session management entirely. There is no more initialization handshake and no session identifier tying an individual request to an explicit MCP server instance. This enables any request to land on any server behind a load balancer without fragile session persistence requirements. Long-running tool calls got an upgrade too: the new Tasks extension, contributed by AWS, gives a server a durable handle to respond with, rather than holding a connection open. Now a client polls for a result rather than the server pushing one over a long-lived connection. Tasks track underlying execution states, so they can survive connection drops, crashes, or increased latency.

Access authorization changed just as fundamentally. Enterprise-Managed Authorization, released in June 2026, is built on the Identity Assertion JWT Authorization Grant, or ID-JAG. During single sign-on, a client trades a user’s identity token for an ID-JAG through an RFC 8693 token exchange, which is what WorkOS’s breakdown of the grant calls a fix for the isolated “OAuth island” problem: no more high-friction, one-off consent screens and orphaned tokens per server, and one place for a security team to see and revoke access across the whole MCP estate. Anthropic’s Claude, Microsoft’s VS Code, Atlassian, Asana, Figma, Linear, and Supabase all adopted it at launch, with Okta serving as the identity provider behind it. This is welcome news for anyone running MCP at any scale.

The Gap: Provisioning Access Isn’t the Same as Governing Behavior

Look closely at what each of these changes actually does, and a pattern shows up: every one of them relocates a decision instead of making one. Researchers at Equixly put it concisely in their assessment of the stateless update: it’s a scalability fix, not a security fix, and worth treating any claim to the contrary with suspicion. Removing the session tracking doesn’t remove state. It just moves it. A tool that needs to remember something across calls now mints an explicit handle and hands it to the model to pass back on the next request, which is cleaner than session state hidden in the transport layer, but it means a capability reference now travels through the model’s own context, visible to anything that can influence what the model reads. The Tasks extension has the identical shape: a durable handle riding through the same channel.

Enterprise-Managed Authorization has a similar gap, one layer up. ID-JAG proves who authenticated and which server the resulting token is scoped to. It says nothing about whether the specific action an agent is about to take with that token, right now, given the context in the session, is the appropriate one. Identity tells you who is asking. It doesn’t tell you why, because it was never designed to. That’s the whole difference between an action being authorized and an action being appropriate.

The Proof: Fully Authorized Agents Often Do the Wrong Thing

Three incidents from the last year make this gap concrete, and none of them involved an identity failure.

A fully authorized session, turned into an exfiltration channel. Zenity Labs’ own AgentFlayer research showed a document carrying an invisible, one-pixel-font instruction that a legitimate, already-authenticated ChatGPT session with real Google Drive access followed after nothing more than an unrelated, routine prompt like “summarize this,” rendering a markdown image whose URL carried stolen data out through infrastructure ChatGPT already trusted. Every credential in that chain was valid. The identity was real. The access was authorized from start to finish. The failure was a decision, not a login.

A trusted MCP server, weaponized in place. For 15 releases, the postmark-mcp package on npm behaved exactly like the legitimate email server it cloned. Every session using it was correctly configured and cleanly authenticated. Then version 1.0.16 added a single line that silently copied every outgoing email to the attacker’s own server. No amount of stateless scaling or enterprise SSO would have changed this story: Enterprise-Managed Authorization would have handed that same compromised server the same clean grant, because the server, not the credential, was the thing that had turned malicious.

A legitimately credentialed agent, left to reason for itself. In the incident widely reported by Fortune, a coding agent with valid, properly scoped database access ran destructive commands against a live production database during an active code freeze, misreading an empty query result as a bug that needed fixing. The freeze was a business rule, not an access boundary, and nothing in this year’s MCP spec wave, stateless or otherwise, touches the moment an agent decides on its own that deleting data is the fix.

The common thread isn’t subtle: in every case, identity and access were never the failure point. The agent’s decision was.

Guidance for Practitioners

Migrate to stateless MCP servers; they are genuinely more resilient to run. Adopt Enterprise-Managed Authorization; it closes real issues with OAuth-island sprawl and provides a central mechanism to revoke access. Both are worth doing on their own merits.

Recognize that these decisions live at a different layer than the ones that caused the three incidents above, and that gap doesn’t close as MCP adds more of this kind of improved plumbing. It widens, because every new handle riding through model-carried context, whether it is a capability reference, a task handle, or a scoped token, is one more object an attacker only has to influence once. For a team adopting this wave, the honest test isn’t whether enterprise SSO is turned on. It’s whether you can answer the question: what action is the already-authorized agent, holding a valid token, about to take, is that action appropriate given what we know, and can you stop it?

MCP just had the biggest summer of its short life. It got easier to run, cheaper to scale, and standard enough for an enterprise IT team to trust. None of that answers whether the agent holding a valid token is about to do something it shouldn't; and that's exactly where the next incident is waiting.

Want to dive deeper into the agentic security frontier, jump into Zenity Labs' AI Agent Security research.