For the last year, most of the conversation around MCP security has been about servers. How do you authenticate them? How do you authorize them? How do you audit what they did? How do you make sure an agent stays within its intended boundaries once it has access? Good questions, all of them — and all squarely the implementer’s problem to solve.
Then two developments arrived within months of each other. Anthropic published Zero Trust for AI Agents, a practical framework for securing agentic systems. Around the same time, the MCP working group shipped the largest protocol revision since MCP launched. At first glance, they look like unrelated events. They’re not.
Several of the controls Anthropic describes as implementation responsibilities aren’t purely implementation responsibilities anymore. The protocol now provides standard mechanisms for them. That’s the interesting part — not that MCP got new features, but that the line between what the protocol owns and what the implementer owns just moved.
This is a look at where that line sits today, and what remains firmly on the implementer’s side of it.
What the protocol just absorbed
Map the MCP 2026–07–28 change list against the Anthropic pillars and five of the framework’s recommendations change character: they stop being controls you design from scratch and become controls the protocol now hands you a standard mechanism for. You still have to adopt them — but you’re implementing a spec, not inventing one.
Traceability got a standard mechanism instead of a per-vendor one: Anthropic’s traceability ladder runs request-IDs → distributed tracing (OpenTelemetry) → full provenance, and explicitly names OTEL as the Enterprise-tier mechanism. The new spec documents W3C Trace Context propagation in _meta (SEP-414), pinning the traceparent, tracestate, and baggage key names so a trace can follow a call from the host app through the client SDK, the server, and whatever it calls downstream — as one span tree. In the same release, the old MCP logging capability is deprecated in favor of OpenTelemetry. The protocol is no longer neutral about observability; it points at the exact tool the framework recommends. The work isn’t free — a server still has to actually propagate the context and export the spans — but it no longer has to invent the scheme first.
Step-up authorization got real plumbing: Anthropic’s access-control tier wants context-aware, step-up authentication for sensitive records. The authorization hardening in this release — scope accumulation during step-up (SEP-2350), plus RFC 9207 iss validation to defang the mix-up attacks that thrive in MCP’s “one client, many servers” topology — gives that pattern a standardized shape instead of a per-vendor improvisation.
Parameter validation got a real schema. The framework asks for schema-and-length validation at Foundation and pattern matching at Enterprise. Tool inputSchema is now full JSON Schema 2020–12 (SEP-2106): oneOf, anyOf, conditionals, $ref/$defs. More of your validation can live declaratively at the boundary — with the spec’s own caveats (don’t auto-dereference external $ref, bound schema depth and validation time) that are themselves Zero Trust thinking about denial-of-service.
Out-of-band prompting got closed off at the transport. Anthropic treats escalation triggers and human-in-the-loop approval as design choices. The new spec requires that a server may only issue a request to the client while it is actively processing a client request (SEP-2260). A user can no longer be prompted out of nowhere through the MCP transport; every elicitation traces back to something they started. It’s a clean example of the design test running through Anthropic’s whole framework — does a control make the attack impossible, or just tedious? — landing on the impossible side at the protocol layer: a whole class of unsolicited-prompt social engineering loses its ride on the wire. (It doesn’t address prompts a compromised application injects by other means; the transport is just no longer one of those means.)
Cross-tenant cache bleed got a declaration. The paper warns about shared-context poisoning in multi-tenant environments. List and read results now carry ttlMs and a cacheScope (SEP-2549) that states whether a response is safe to share across users. Multi-tenancy hygiene that used to be an implementation worry is now something the protocol lets a server declare.
None of this makes the framework redundant. The protocol gives you the mechanism; the framework still decides the policy — which scopes count as sensitive, what your retention window is, when a human must sign off. But the cost of reaching those pillars dropped, and the floor rose for everyone who simply adopts the spec correctly.
The stateless core changes your threat model, not just your load balancer
The headline of the release is that MCP is now stateless at the protocol layer. The initialize handshake is gone (SEP-2575); the Mcp-Session-Id header and the protocol-level session it carried are gone (SEP-2567). Any request can land on any instance.
The operational read is obvious — round-robin load balancing, no shared session store, tools/list responses that cache for as long as ttlMs allows. The security read is the one worth dwelling on.
Anthropic devotes real space to memory-based privilege retention and shared context poisoning — attacks that work precisely because state persists across calls and sessions. A protocol-managed session store is one instance of exactly that kind of shared, long-lived state. Removing it from the protocol layer takes the transport off the board as a place where poisoned context can quietly accumulate.
What it doesn’t do is solve poisoning. An application that keeps its own conversation memory, a vector store that feeds RAG, an agent that persists context between runs — all of those still carry the same risk they did before, and the framework’s controls around them still apply in full. The stateless core narrows the attack surface to the layers you actually own; it doesn’t shrink the problem to zero.
The spec also doesn’t abolish state; it makes it explicit. When a server needs continuity, it mints a handle — a basket_id, a browser_id — and the model passes it back as an ordinary argument. State stops hiding in transport metadata and becomes visible to the model, auditable, and bounded to the call chain that created it. That’s the framework’s “design for breach” instinct expressed in protocol shape: there’s less hidden shared state to poison, and what state remains is passed in the open where you can audit it. Servers already built this way mostly get to recognize their design in the spec; servers leaning on protocol sessions to carry state now have a cleaner pattern to migrate toward.
Where MCP Apps cut the other way
It would be too tidy to claim the spec only tightens things. It also opens a door.
MCP Apps (SEP-1865) let a server ship interactive HTML that the host renders in a sandboxed iframe. The design is careful — tools declare their UI templates ahead of time so hosts can prefetch, cache, and security-review them, and every UI-initiated action runs back through the same JSON-RPC audit and consent path as a direct tool call. Good plumbing.
But Anthropic is emphatic that any agent processing untrusted content — web pages, documents, rendered markup — belongs in a sandbox, and treats indirect prompt injection as “the more insidious threat.” Server-rendered UI is a new surface for exactly that. The spec hands you the sandbox (the iframe) and the audit path; the framework reminds you a sandbox is table stakes, not a finish line, and that the content inside it is untrusted until proven otherwise. Adopt MCP Apps for the capability, and keep the framework’s input-isolation discipline pointed straight at the iframe.
A reference point: the maturity models are tracking the same target
Anthropic’s paper isn’t the only framework circling this space. The Cloud Security Alliance’s AI Security Maturity Model (AISMM), is a useful contrast because it sits one layer up — a security-program maturity model, not a protocol guide. Yet several of its control objectives name MCP directly: OAuth-scoped authorization at Level 3, fine-grained per-operation scopes with deny-by-default policy-as-code at Level 4, agent-and-delegation-chain tracing that cites OpenTelemetry by name. The mechanisms it puts at its upper tiers are, increasingly, the ones the spec now standardizes.
One detail makes the point: the AISMM pins its MCP authorization references to the 2026–03–15 spec — the version this release candidate supersedes. Not a flaw; the model calls itself a living document. But it’s a dated illustration of the thread running through all of this. The protocol moves; the frameworks built on top of it run a step behind. Read the maturity models for where the bar should sit; read the spec for where the floor just moved.
What stays the implementer’s job
It’s tempting to read all this as the protocol quietly closing the gaps, but it’s worth being precise about which gaps. The spec standardizes mechanisms. It says nothing about policy, and policy is most of the work.
The clearest line is the one Anthropic itself draws in Part V: securing the agents you deploy is only half the job, and the other half is security operations. A whole set of the framework’s pillars — SIEM streaming, anomaly detection, SOAR playbooks, a governance committee — live in that second half. No protocol revision touches them, the same way a database doesn’t ship its own SIEM. They belong to the program around the server, not the server, and certainly not the wire.
Even the mechanisms the spec does hand you only become controls once someone decides how to use them. Trace context is propagation, not a retention policy or an alerting rule. A cacheScope of user is a declaration, not a decision about which data is sensitive enough to warrant it. Scope accumulation on step-up is a flow, not a judgment about which operations deserve a second factor. The protocol moved the mechanism into reach; the framework still decides when it fires, who approves the exception, and what happens when it trips. That division — protocol owns the mechanism, implementer owns the policy — is the thing to hold onto.
The takeaway
The thesis is simple: Anthropic’s paper defines the security bar; MCP 2026–07–28 moves part of that bar into the protocol — but the protocol only standardizes mechanisms, while policy, enforcement, governance, and operational response still belong to implementers.
The line that made this concrete was the logging deprecation — easy to skim past in a changelog, but it’s the protocol telling an entire category of servers that their home-grown observability is now a migration target, and naming the replacement in the same breath. That’s the whole pattern in miniature: the spec doesn’t add a security feature so much as relieve every server of inventing the same one independently.
What this changes in practice
For anyone maintaining a server, the practical implications are concrete. The home-grown request-ID logging becomes a migration toward W3C Trace Context in _meta and OTEL export — the same observability the framework wanted, now with a wire format you don’t define. Any code leaning on Mcp-Session-Id or the initialize handshake to carry state becomes a candidate for explicit handles passed as arguments, which removes a shared-state surface rather than securing it. Bespoke parameter checks can move toward declarative JSON Schema at the boundary; ad-hoc authorization can adopt the standardized step-up scope flow instead of a per-vendor one; multi-tenant cache behavior becomes a cacheScope you declare rather than a property you hope holds. And if MCP Apps are on the roadmap, the iframe is new untrusted-input surface that belongs in your threat model from the start, not after.
None of those are switches you flip. They’re places where the spec now gives you a standard to implement instead of a problem to solve from scratch — which is exactly the point. The mechanism arrives standardized; the decision to adopt it, and the policy wrapped around it, is still the work.
Final thought
A protocol matures not when it adds features, but when it starts absorbing the responsibilities that everyone building on it was solving separately. That is what this MCP revision quietly does. The controls that used to live in scattered implementations — trace propagation, scoped step-up, schema validation, cache boundaries — now have one agreed shape, which means they can be reasoned about, audited, and trusted in a way that a thousand bespoke versions never could.
That narrows what each implementer has to build. It does not narrow what each implementer is accountable for. The spec can hand you a standard mechanism; it cannot decide when that mechanism should fire, what counts as sensitive, or who answers for it when something goes wrong. Those decisions don’t move. They were the hard part before this release, and they remain the hard part after it.
So the practical reading is straightforward: treat Anthropic’s framework as the statement of where the bar sits, and the protocol as a growing set of mechanisms for reaching it at lower cost. The work that remains is the work that was always yours: deciding policy, drawing boundaries, and owning the response. The protocol just stopped making everyone build the same plumbing first.
References:
- Anthropic — Zero Trust for AI Agents
- Model Context Protocol — 2026–07–28 Specification Release Candidate
- Cloud Security Alliance — AI Security Maturity Model
What the MCP 2026–07–28 Spec Means for Zero Trust Security was originally published in System Weakness on Medium, where people are continuing the conversation by highlighting and responding to this story.