The Model Context Protocol has quietly become the way AI agents talk to business tools. Anthropic introduced it in 2024, and inside about sixteen months it went from a developer curiosity to something with thousands of production servers behind it. If you are building agents that touch real systems, you are almost certainly using it, directly or through a vendor, which is exactly why enterprise MCP security now deserves your attention.
On 28 July 2026 it changed in a way that matters for anyone running this in production. The specification moved to a new version, MCP 2026-07-28, with a twelve month deprecation window for the older versions. The headline is that MCP is now stateless at the protocol layer, which is what makes it viable for enterprise-scale, cloud-native deployments rather than the single-user local tool it started as.
That is genuinely good news. It also comes with a catch that is easy to miss in the excitement, and it turns enterprise MCP security from an afterthought into the main event.
The protocol standardises the plumbing, not the safety
Here is the part worth sitting with. MCP standardises how a model discovers and calls tools. It does not, by itself, enforce security at the protocol level. Authentication, authorization and transport security are left to whoever implements each host, client and server.
The new enterprise-ready specification does not change that division of labour. If anything it sharpens it. Making the protocol stateless and cloud-native removes friction and unlocks scale, and in doing so it pushes more of the security responsibility onto developers and platform operators. The protocol got more capable. The obligations that come with running it did not go away. They moved closer to you.
Enterprise MCP security: where the trust boundaries actually sit
Because MCP sits between a model and your enterprise systems, enterprise MCP security means thinking about trust at every hop in the flow. A few of the boundaries that need real attention:
Identity. An MCP server should be reachable by an agent through a known identity, whether the agent’s own or a user-delegated one. Anonymous or over-broad access is where a lot of the risk concentrates. This is exactly the area the protocol’s roadmap is working on next, with workload identity federation and token exchange, which tells you it was underspecified before.
Tool descriptions. This one is subtle and important. A tool description that changes between the version you reviewed and the version the model actually reads is, in effect, unreviewed instruction running with model-level trust. A sensible control is to hash tool descriptions at deployment and verify those hashes before the descriptions ever reach the model. If you are not doing this, you are trusting that nothing between review and runtime altered what the model sees.
Data classification. Not every tool should be able to reach every dataset. A practical pattern, and one that public-sector security guidance now recommends, is to align tools with data classification zones. Group public tools for public data, and explicitly segregate the tools that touch sensitive or regulated information. When the data is genuinely sensitive, a local instance of the server rather than a remote one reduces the exfiltration surface.
What this means if you are on AWS
The stateless, cloud-native direction lines up well with how you would want to run this on AWS in the first place. A remote MCP server in the new model is closer to a normal HTTP workload, which means the security tools you already trust apply: identity through your existing provider, network segmentation, request logging, and the same rigor you would put around any API. The protocol becoming a standard HTTP workload is what lets you treat it with standard cloud discipline rather than inventing something bespoke.
The mistake would be to read enterprise-ready as secure-by-default. It is not. It is scalable-by-default, with the security left as an explicit exercise for the operator. That is a reasonable design choice, and it is one that rewards teams who treat the MCP layer with the seriousness they already give to APIs and cloud infrastructure.
The twelve month window is a planning window
The deprecation clock is not just a migration deadline. It is a chance to build the identity, validation and logging controls in properly rather than retrofitting them onto a legacy setup later. Teams that use the window to get their trust boundaries right will come out with agents that are both more scalable and more defensible. Teams that only port the transport and skip the security work will have moved their problem to a bigger, faster platform without fixing it.
