MCP shipped its biggest specification update on 28 July 2026, and the framing in the release notes is worth reading carefully. The protocol got easier to run in an enterprise. It did not get safer on its own. Those are different things, and the gap between them is now explicitly your problem.
What actually changed
The core went stateless. This is the headline and it is the most consequential change for anyone running MCP at scale. Previously, session state in the protocol made MCP servers awkward to run behind standard infrastructure: sticky sessions, connection affinity, load balancers doing things load balancers should not have to do. The new core works the same on a laptop and behind an API gateway, which means your MCP servers can now run on the Kubernetes and DevOps tooling you already have, with the observability and policy enforcement that comes with it.
Authorisation aligned with OAuth 2.1 and OIDC. MCP servers now connect to enterprise identity providers such as Entra or Okta without custom glue. If you built your own token handling because the old spec did not map cleanly onto your IdP, that code is now technical debt.
Capabilities became versioned extensions. Rather than a growing core, the spec now has a small stable centre and an opt-in extensions framework. MCP Apps and Tasks are the first two official extensions. This matters for procurement and for security review, because “does this server support MCP” becomes a more precise question: which extensions, at which versions.
A real deprecation policy. Minimum 12 months between deprecation and removal. Unglamorous, and the change most likely to make a platform team comfortable committing to MCP for something load-bearing.
What this moves onto operators
SecurityWeek’s read of the release was that it shifts critical security responsibility from the protocol to developers and platform operators. That is accurate and it is deliberate. A stateless core aligned with OAuth is a core that assumes you have an identity provider, a gateway and a policy layer, and that you will use them.
Concretely, five things are now unambiguously yours.
Identity per agent, not per application. OIDC alignment gives you the mechanism. It does not decide your model. An agent calling an MCP server should present its own identity with its own scopes, so that the server can make an authorisation decision about that agent rather than about the application it happens to live in. This is the same argument I made about the six control layers for agent security, and MCP is where it becomes concretely enforceable.
Tool scope. MCP servers commonly expose far more than any single agent needs, because the server author does not know your use case. Scope at the gateway. An agent whose job is reading invoices does not need the write methods, even if the server offers them.
Gateway policy. Now that servers run behind standard infrastructure, put the enforcement there: rate limits, argument validation, destination allowlists, and blocking on data classification. This is the layer that survives a compromised or misbehaving server, and it is the main practical benefit of the stateless change.
Supply chain review. An MCP server is executable code running with your agent’s authority. CVE-2025-6514, a shell command injection in the mcp-remote package, compromised over 437,000 developer environments. Pin versions, review before you install, and maintain a list of approved servers. Treat a community MCP server the way you would treat any unvetted dependency with production credentials, because that is what it is.
Output handling. Content returned by a tool call enters the model’s context and can carry instructions. Indirect prompt injection through tool results is the injection path most people forget, precisely because the tool is one they trust. Trusting a server is not the same as trusting the data it returns from somewhere else.
Should you migrate now?
| Situation | Recommendation |
|---|---|
| Small number of internal servers, simple auth | Migrate this quarter. Low risk, and you get gateway deployment |
| Custom authorisation code written around the old spec | Plan a quarter. This is a rewrite of the auth path, not a version bump |
| Consuming third-party servers only | Wait for your vendors, but ask them for a date now |
| MCP in pre-production, not yet live | Build on 2026-07-28 directly. Do not ship on a version you will migrate off |
| Large estate, mixed ownership | Inventory first. Migrate the servers touching sensitive systems first |
The 12 month deprecation window means nothing breaks in a hurry. That is a licence to plan, not a licence to ignore. The one case where I would move fast is a server that handles regulated or personal data on custom authorisation code, because the new OIDC alignment materially improves what you can prove about who did what.
The adoption picture
MCP is past the point where you can treat it as an experiment. Roughly 28% of Fortune 500 companies have implemented it in under 18 months. Forty-one percent of surveyed software organisations report limited or broad production use. CData estimates 30% of enterprise application vendors will launch MCP servers during 2026. Named production deployments include Cisco, MongoDB, PayPal and Raiffeisen Bank, the last reporting a 40% improvement in risk assessment through MCP-integrated AI.
And in the same surveys, security is the leading blocker. That is not a contradiction. It is a normal adoption curve for an integration standard: the capability arrives, the controls follow, and the gap between them is where incidents live. The 2026-07-28 release is the controls arriving.
If you are building your first servers, the MCP server handbook for enterprise covers the design decisions that matter before you write any code, and the n8n MCP guide covers the workflow automation path specifically. Both predate this spec release; the architecture advice holds, the authorisation section is the part to read against the new OIDC model.
The part I would emphasise
MCP solved a real problem. Before it, every agent-to-system connection was bespoke, and the integration cost was the reason most agent projects stalled at demo. That is genuinely fixed.
What the standardisation also did was give every agent in your organisation a common, easy, low-friction path to every system you connect. That is the point, and it is also the risk. The attack surface did not appear because MCP is badly designed. It appeared because MCP made connection cheap, and cheap connection means more connections than anyone is tracking.
The organisations that will do well with MCP over the next two years are the ones that inventory their servers the way they inventory their APIs, scope them the way they scope service accounts, and put a gateway in front of them the way they would put a gateway in front of anything else that talks to production. None of that is exotic. It is just work that nobody did during the phase when MCP was a clever thing you could get running in an afternoon.
Sources
- The 2026-07-28 Specification, Model Context Protocol blog
- MCP 2026-07-28 spec: stateless core, coming to Claude, Anthropic
- New enterprise-ready MCP specification brings new security challenges, SecurityWeek
- The MCP 2026-07-28 release, explained for enterprise teams, CData
- MCP adoption statistics 2026, Digital Applied