A release that sets the foundation
The 2026-07-28 Model Context Protocol release is a genuine milestone. It is the kind of foundational change a maturing protocol earns the right to make once, and the MCP team made it cleanly. MCP is now stateless. The old initialize handshake and the Mcp-Session-Id header are gone, and the protocol metadata previously established during initialization now travels with each request. As the specification puts it, "any MCP request can land on any server instance, and the sticky routing and shared session stores that horizontal deployments needed before are no longer required at the protocol layer."
In practice that is a large step forward. An MCP server can now run behind an ordinary round-robin load balancer, with no sticky sessions and no shared session store required at the protocol layer, on commodity HTTP. Applications may still keep durable or shared storage for their own state; what the release removes is the protocol's requirement for it. The team calls it "the foundation we expect it to grow on for a long time," and the surrounding work backs that up: an extensions framework so new capabilities arrive without breaking the core, and a formal deprecation policy that gives implementers a year of runway. This is what a protocol looks like when it grows from clever demos into production infrastructure.
The release also took trust seriously. Authorization is tightened toward OAuth 2.0 and OpenID Connect, closing a class of mix-up attacks and binding credentials to the right authorization server. Observability got a real upgrade: W3C Trace Context is now formally specified, so a single request can be followed across SDKs, gateways, and downstream calls in any standard tracing backend. The release did not treat trust as an afterthought. It built trust in.
The question the release invites
All of that trust machinery answers questions from inside the system. Authorization and distributed tracing both cross organizational boundaries routinely, and they are not weaker for it. They answer different questions from the one attestation answers.
Authorization answers a question about permission: is this client allowed to make this call? The release made that front door much stronger. Observability answers a question about visibility: what did my system report that it did? That is a clear, connected view for the operator and their team, and like any record it is exactly as trustworthy as the party who kept it. Both are essential, and neither is built to do a third job that the release quietly makes more relevant than before.
When an agent reaches through MCP to a tool or a dataset, can a party who does not trust the operator still verify what actually happened? Not "was the client allowed," and not "what did the operator's logs say," but: is there evidence of the tool call that a skeptical outsider, an auditor, a counterparty, or another organization's agent, can check without taking the operator's word for it?
This is a frontier the release's own success brings forward. Agents are now going to run statelessly, at scale, on ordinary infrastructure, and increasingly across organizational boundaries where the parties do not share a trust relationship. The question is older than this release. What the stateless design changes is the shape of a good answer: it makes per-request evidence the natural form for one to take. When there was a session and a sticky gateway, at least one vantage point saw a whole interaction. Now any request can land on any instance, so no single component sees the full picture, and evidence of what happened is most naturally carried with the call rather than reconstructed afterward. This is the natural next thing to build, and it sits squarely in the identity, trust, and traceability work the community already cares about.
Confidential MCP, from the ground up
The answer starts with a simple distinction: software you trust because someone tells you to, and software you can verify without trusting anyone.
Ordinary software runs in the open on a machine. Whoever controls that machine, a cloud operator, a privileged administrator, or malware that has gained control, can read the software's memory and change what it does. Encryption helps while data is stored or moving across a network, but the moment a program processes that data it sits in memory as plaintext the owner of the machine can see and alter. So a policy check, or a log, running as ordinary software is only ever as trustworthy as the operator running it.
Modern processors add something that changes this: a sealed room inside the chip, called a Trusted Execution Environment. Code and data inside are kept encrypted in memory and shielded from everything outside, including the operating system and the operator. Within that boundary, the operator of the machine cannot read or alter what runs there. The chip can also produce a hardware-signed statement, called an attestation, that says exactly which code is running in that sealed room. Anyone can check that statement against the chip maker's published keys, which moves the question from trusting the operator to trusting the hardware vendor's root and the measurements themselves. It is the difference between a claim and a receipt that someone else can check.
That guarantee is bounded, and the bounds are worth stating. An attestation proves which code and which policy were measured, under a specific set of assumptions: the hardware vendor's trust root, the firmware and microcode beneath the enclave, and the integrity of the measured workload. It does not prove that the policy is the right policy, and it does not remove platform or side-channel risk. It also assumes a remote or rogue-administrator adversary rather than one with physical possession of the machine; TEE.fail has demonstrated attestation-key extraction from fully patched SEV-SNP and TDX systems using a sub-$1,000 DDR5 interposer. Verifiable evidence narrows the set of parties you have to trust. It does not reduce that set to nobody.
Confidential MCP is the pattern of putting the MCP policy check inside that sealed room and turning each tool call into a signed record that anyone can verify. cMCP is an open-source implementation of the pattern, and the mechanics are the whole point.
An agent points at cMCP instead of calling tools directly. Every tool call is checked, inside the sealed room, against a written policy, and the result is to allow it, block it, or redact part of it. Before any of that runs, the policy is fingerprinted into the hardware attestation, so a verifier can confirm that the rules that ran were the exact rules that were approved, not a version swapped in later. The call itself is handled inside the sealed room, so the network layer carrying the traffic sees only ciphertext, and the only thing that ever leaves the room is a signed evidence record. That record states which tools ran and how the policy decided each call, and it can be checked offline against the hardware root of trust, with no operator trust required.
This is exactly the shape a stateless protocol wants. The evidence is anchored to the individual call, so it does not matter which server instance handled it or that there is no longer a session tying the interaction together. Verifiability is restored at the level of the individual tool call, which is the level the protocol now operates at.
It is worth being precise about what that means in the implementation today. Every tool call is appended to a hardware-sealed audit chain as it happens. The signed TRACE claim that carries those entries is produced per session by default, and per call when it is configured that way, so evidence at per-call granularity is a deployment choice rather than an automatic property of the design. What a claim covers today is the gateway boundary: which tools were called, how the policy decided each one, and which policy bundle was loaded. Extending attestation across the tool server itself is Phase 2 work.
Open evidence, community trust
A deliberate line runs through this, and it is worth naming plainly. In the model cMCP proposes, generating the evidence is open, and being the authority that vouches for it at scale is commercial.
The certificate authority is the right analogy. Anyone can create a key and a certificate request with open, free tools; that part is not the business. The value is in the authority that vouches for the binding and that systems choose to rely on. Confidential MCP has the same shape. The substrate that produces verifiable evidence stays open and community-governed, so anyone can implement it and no one is locked in. The web standardized on an open certificate format without ever tying itself to a single authority, and an open evidence format could work the same way. An open format is what lets independent implementations interoperate on proof rather than on trust, and it keeps any commercial layer optional and swappable.
This is one proposed model rather than a settled one, and its trade-offs deserve to be stated alongside it. A commercial trust authority reintroduces some of the concentration an open format exists to avoid, and a format governed in practice by its largest implementer tends to drift toward that implementer's needs. Whether the ecosystem wants a trust-authority tier at all, and how a shared evidence format should be governed if one emerges, are questions for wider technical and community review rather than for any single project to answer on its own.
Where it is today, and where it goes next
None of this is a whiteboard idea. cMCP is a working, MIT-licensed, openly governed project, and the runtime is available today. It runs in software mode without special hardware, and on real confidential hardware the same record verifies against the chip vendor's root of trust. The code, the quickstart, and the open roadmap all live at github.com/agentrust-io/cmcp.
The direction from here is what makes this worth building together. cMCP is a Developer Preview, and the foundations are in place: a policy engine that runs inside the enclave, hardware-sealed audit chains, signed records, and a standalone verifier anyone can run offline. The AMD SEV-SNP and Intel TDX verifiers have now been validated end to end against genuine hardware evidence, an Azure confidential VM report and a GCP C3 TDX quote, with both runs recorded in the project's hardware-validation notes. That validates the verifier against real quotes; generating a quote still requires the corresponding silicon, and the TPM path has not yet been validated the same way. In flight is public auditability, anchoring each record in a transparency log so a record can be checked by anyone, not just its holder. Ahead lies extending attestation to the far side of the tool call so the tool server's own response is covered, conforming to the emerging IETF remote-attestation standards so records are portable across implementations, adding supply-chain build provenance for the runtime itself, and reaching the confidential GPUs that AI workloads increasingly run on.
These are the areas still open for development and review. None of it is exotic: policy bundles for common tools, verifiers in more languages, and reports from running the runtime against real workloads. An open evidence format only becomes a standard when more than one party relies on it, and that only happens through open review.
The complement to a strong release
The 2026-07-28 release built the foundation the ecosystem will grow on, and it strengthened trust for the parties working inside a system together. Verifiable evidence is the complement to that work: it extends trust to the parties who stand outside the system and cannot simply take the operator's word. As agents begin to act across organizational boundaries on this new stateless infrastructure, that is exactly the trust that lets them do business rather than merely function.
The argument here is meant to be checked rather than believed, and the record format is designed so that checking it does not require trusting the party that produced it.
References
- Model Context Protocol, "The 2026-07-28 MCP Specification Release." Model Context Protocol Blog. https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/
- Model Context Protocol, specification and changelog. https://modelcontextprotocol.io/specification and https://github.com/modelcontextprotocol/modelcontextprotocol/releases
- Agentic AI Foundation, "MCP Is Growing Up." https://aaif.io/blog/mcp-is-growing-up/
- cMCP: Confidential MCP Runtime. https://github.com/agentrust-io/cmcp and https://pypi.org/project/cmcp-runtime/
- OWASP Agentic AI Top 10. https://genai.owasp.org/
Share
Author
Imran Siddique
