MCP 2.0: How the 2026-07-28 Release Changes Agent Governance in the Enterprise

The 2026-07-28 release, the MCP 2.0, is the largest MCP revision since launch. It lands eight months after the November 2025 revision we covered in detail, and most of it is about making MCP easier to run at scale.

Three of the changes go further than scale, with real implications for the work security and risk teams already own. This piece covers what each change means for enterprises running agents in production, and what to do next:

• More servers and context to keep track of, now that servers no longer track who is connected
• The login is verified, the caller’s claims are not, so your servers still have to check the identity, role, and tenant on every request
• Monitoring needs a new anchor when the session is gone, now that one tool call can run for hours
• Implementation playbook for MCP builders and users

What changed in MCP 2.0

• Sessions are gone. A client, meaning the application connecting to an MCP server, used to open a connection and keep it alive. Now every request carries everything the server needs to answer it.
• Authorization is harder to abuse. Clients have to confirm which authorization server answered them, and credentials no longer work anywhere except where they were issued.
• Tool calls can pause and resume. A call that needs more information comes back and gets retried, rather than holding a connection open while it waits.
• Gateways get easier to run. Routing and caching information now sits in request headers, so a gateway can act on it without reading the whole request.
• Extensions are formalized. Long-running work and server-rendered interfaces are official add-ons now, alongside Enterprise Managed Authorization.
• Nothing disappears without warning. Anything being removed gets at least twelve months of notice, starting with Roots, Sampling, Logging, and the old HTTP+SSE transport.

The full changelog lists every major and minor change. We focus on the first three below, as those are the ones we expect to have the biggest impact on security and risk teams.

More servers and context to keep track of

Until now, a client and an MCP server opened a conversation and kept it going. The server held onto who it was talking to for as long as the connection lasted, which meant every request from that client had to come back to the same server.

MCP 2.0 drops that. Every request now carries its own identity and capabilities, so any server in a pool can answer any request. That makes MCP servers as easy to run as any other web service: behind an ordinary load balancer, across regions, without shared state. Enterprise Managed Authorization ships alongside, giving IT central control over which servers employees can connect to.

More servers also means more of what feeds your agents. MCP servers are how an agent gets its context, the data and tools that shape what it does next, so a wider, shifting set of servers means less certainty about what informed a given decision.

TLDR: you will have more of these servers, in more parts of the business. Most teams already struggle to keep their MCP inventory current, let alone the other tools an agent can reach, and now there is more to track. Keeping an always up-to-date inventory of what your agents can reach has to become a standing job for the security team.

The login is verified, the caller’s claims are not

With MCP 2.0, a client now has to confirm which authorization server answered it before accepting a login, which closes off a class of attack that MCP’s one-client-to-many-servers pattern made easier. Credentials only work with the server that issued them. The old self-registration process is being replaced by something more verifiable, so a client’s claimed identity can be checked against a published record. What happens after that moment is unchanged.

Details like which user, which role, and which tenant still travel in a field on every request that the client fills in itself, and nothing proves those values are real, no signature, no check against a trusted source.

A server that takes those values as given is trusting a claim no one has checked, which means anything able to reach that server can present itself as a different user, a higher-privileged role, or another tenant, and act with that authority. The hardened login does not stop this, because it happens after the login, on requests the connection already trusts.

TLDR: before, your team verified a caller once, when the connection opened, and it was trusted for everything that followed. Now that trust does not carry past a single request, so the same check has to happen on every one: the identity, role, and tenant a caller presents, checked against a source you trust rather than taken as given. That obligation holds whether the server is yours to configure or a vendor’s to answer for.

Monitoring needs a new anchor when the session is gone

Agent activity used to fit inside a request and a response, which changes with MCP 2.0. A tool call that needs more information comes back, waits for the answer, and gets retried. Long-running work moves to a job the client checks in on, and that job survives a dropped connection. One interaction can span many requests and pick up hours later.

That breaks how a lot of teams currently follow what an agent is doing. Sessions were never designed to be a governance boundary, but they became a convenient one, and now they are gone.

Correlation is only part of what is missing. We made the point when the November 2025 specification landed that a single request was never the full picture for an agent, and this release widens the gap. The protocol describes who an agent is talking to. It does not describe how the agent reasons, what it intends, or why it chose this sequence over another. MCP is also one path among several. APIs, hard-coded commands, browser plugins, knowledge sources, and skills sit alongside it, and none of those changed on July 28.

TLDR: one agent action now stretches across many requests and a gap of hours, so watching a single connection no longer shows you a single action. Your team needs a way to follow the whole sequence (versus in any one call), since that’s where the risk shows.

Implementation playbook for MCP builders and users

If your teams build and run their own MCP servers, this means migration work you need to schedule. If you only use servers your vendors run, it’s a set of things to watch for and questions to ask as those servers move to the new spec. Most organizations do both, and we tried to call each one out in our implementation guidance.

For the MCP servers you run

1. Find what breaks. Identify the clients and servers that still depend on session IDs, the old error codes, the experimental Tasks API, or the newly deprecated features. That gives you the real migration scope rather than the specification in the abstract.
2. Check what clients claim. Confirm your servers verify the identity, role, and tenant values arriving on each request rather than acting on them as given.
3. Re-test your inspection coverage. Tooling built to follow a session can lose the thread now that consecutive requests land on different instances.

For the MCP servers you only use

1. Ask which version each one speaks, and when the vendor plans to move. Old and new implementations do not interoperate, so mixed environments need a deliberate plan rather than an assumption.
2. Ask whether they verify client-supplied state. This is a fair question for a vendor review, and the answer tells you how much of the improvement above you actually get.
3. Use Enterprise Managed Authorization to set which servers your people are allowed to connect to, before the footprint grows on its own.

What to build agent governance on as the protocol keeps evolving

Governance built on protocol mechanics has to change every time the protocol does, and MCP has now changed twice in a year. Think about what that means for a risk decision written against session-based traffic, a policy catalog scoped to a fixed set of servers, or a detection that keys on a specific error code. Each one works today but needs reworking the moment the specification moves, by the same team that wrote it.

We advise anchoring a level up instead. Our research into what agents reach in production comes down to three principles that hold regardless of the protocol version:

• Keep a full inventory of what an agent can reach.
• Watch how those connections change.
• Understand not only what a tool is permitted to do, but what it actually does.

As the protocol underneath evolves, governance aligned to what an agent can do, the capabilities it holds and how it behaves, rather than to how it reaches a tool, will hold steady. Every revision rewrites the mechanics: transports, sessions, error codes. But what a tool lets an agent do, and how the agent behaves once it does, outlasts future protocol versions.

Controls built at that level, on capability and behavior, rather than on the path a call takes, spare your team the rework each time the spec moves.

Read more about the three principles, and the wider toolset they apply to, in our guide, Beyond the MCP: Three Foundational Principles for Governing the Agentic Toolset.