What does the 2026-07-28 MCP release contain?
First, a status point that matters for planning: the 2026-07-28 specification is marked Current, not Final. The versioning page reserves "Final" for past, complete specifications that will not change. A Current specification may still take backwards-compatible changes.
Three additions that land on enterprise governance
- Multi Round-Trip Requests (MRTR), SEP-2322. A server returns
resultType: "input_required"with a batch ofinputRequestsand opaque state; the client answers by re-sending the original request withinputResponses. It is not mid-call streaming — it is a stateless request/response round trip that lets a server ask a human for confirmation or a missing parameter. - Enterprise-Managed Authorization. Now an official extension, published at
modelcontextprotocol/ext-auth. - Tasks, SEP-2663. Graduated from experimental, redesigned around polling rather than blocking, for reliable long-running agents.
Nine major changes, several breaking
| Change | SEP |
|---|---|
Protocol-level sessions and the Mcp-Session-Id header removed; servers use explicit handles passed as tool arguments | SEP-2567 |
initialize handshake removed, replaced by per-request _meta carrying protocolVersion and clientCapabilities | SEP-2575 |
Blocking tasks/result replaced by polling tasks/get | SEP-2663 |
Every result must include a resultType field ("complete" or "input_required") | SEP-2322 |
subscriptions/listen replaces the HTTP GET endpoint and resources/subscribe | — |
Removal of ping, logging/setLevel, notifications/roots/list_changed | — |
Removal of SSE resumability (Last-Event-ID) | — |
A frequent error worth correcting: server/discover is not the handshake's successor. Servers must implement it, but clients only may call it — it is optional up-front version selection, while the actual replacement for initialize is per-request _meta.
Authorization hardening
- RFC 9207 issuer validation — authorization servers return the
issparameter and clients must validate it before redeeming codes, closing an authorization-server mix-up hole. - Client credentials bound to the issuer that minted them; no reuse across authorization servers.
- Dynamic Client Registration deprecated in favour of Client ID Metadata Documents (CIMD).
The deprecation clock
A feature must remain deprecated for at least twelve months before removal. An expedited path floors the shortened window at ninety days, but it requires an active security risk — a vulnerability with a published advisory or documented in-the-wild exploitation for which no in-place mitigation exists — plus Core Maintainer approval. Roots, Sampling and Logging are deprecated in this release and remain in the specification during the window.
What gap does MRTR not close?
MRTR gives you a mechanism to ask a human. It decides nothing about three questions that determine whether the mechanism is worth anything:
- Whether a given call warrants asking at all. The protocol has no opinion on risk. If your server asks for every operation, humans will approve reflexively; if it asks for none, the mechanism is decorative.
- What the approver is shown. An approval prompt that displays a tool name and an opaque argument blob does not produce an informed decision, and will not read as one in an audit.
- How you prove afterwards what was approved, by whom, and against which policy. MRTR carries the round trip; it does not carry the evidence.
That is the shape of the work the specification hands to implementers, and it maps onto exactly the controls the NSA's guidance asks for.
The NSA control list is a useful benchmark
The National Security Agency published a Cybersecurity Information Sheet, Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation (Ver. 1.0, May 2026, U/OO/6030316-26 | PP-26-1834). Its position is that secure-by-default behaviour must be enforced through implementation rigour rather than protocol guarantees — the same conclusion the specification's own design reaches.
Its recommended controls, verbatim where quoted:
- Logging. "All tool and model invocations should be logged, including the exact parameters, identities involved, and (where feasible) cryptographic hashes of results or output."
- Output handling. "Each output must be treated as untrusted input to the next phase of the pipeline" — filter for length, disallowed keywords, rate limits and indirect prompt injection.
- Trust boundaries. Define them explicitly between agents, plugins, models and end users.
- Data-classification zones. Segregate tools so public tools handle public data and sensitive data has restricted access.
- Sandboxing. OS-level frameworks — AppContainers, SELinux, AppArmor, seccomp — with least privilege for agent processes.
- Message security. Cryptographic signatures inside JSON payloads, expiration timestamps and replay protection; never assume authenticity.
- Inventory. Maintain a versioned inventory of deployed MCP agents with patch history, and scan for unauthenticated or unauthorised servers.
For a vendor or an internal platform team, this list is more useful as a self-assessment than as a marketing checklist — mapping your controls against it, and marking your gaps honestly, is more persuasive to a security buyer than claiming full coverage.
What the vulnerability record actually shows
Prevalence studies across the ecosystem have reported: 82% of 2,614 MCP implementations vulnerable to path traversal (Endor Labs, 2025); 43% to command injection (Equixly, February 2026); 36.7% to SSRF across 7,000+ servers tested (BlueRock, 2026); 33% carrying a critical vulnerability among 1,000 scanned (Enkrypt AI, October 2025). On authentication, an audit of 5,200+ servers found only 8.5% using OAuth, with 53% relying on static API keys or personal access tokens (Astrix, October 2025).
Treat these as directional. They come from vendor-run scans with differing methodologies and populations, and none is a random sample. The consistent signal across all of them — weak authentication and inadequate input handling — is more reliable than any individual percentage.
A worked example of why CVE feeds are not enough
CVE-2026-75130 is instructive. It was published on 18 August 2026 against Upstash's Context7 MCP documentation server, versions through 2.1.2, classified CWE-1427, with documented impacts of credential exfiltration from environment files and destructive file deletion. Scored 9.0 under CVSS 3.1 and 6.4 under 4.0 — both by VulnCheck; NVD has not assessed it.
But public disclosure was actually 5 March 2026, by Noma Security, as "ContextCrush" — and Noma documents a fix deployed to production with rule sanitisation on 23 February 2026. The CVE record carries no patch reference, no fixed version and no vendor advisory. NVD's CPE also misspells the vendor as "Uptash", so vendor-name searches miss it entirely.
So: five months from disclosure to CVE, a fix no advisory links, a misspelled vendor and no NVD assessment. Separately, the community tracker at vulnerablemcp.info appears to stop at early February 2026 — its newest entries are CVE-2026-25536 (4 February) and CVE-2026-23744 (1 February), and it does not list CVE-2026-75130 at all.
An organisation relying on CVE feeds or that tracker to know what its MCP servers are exposed to is reading a broken instrument. That is a stronger argument for runtime enforcement than any single vulnerability, because it does not depend on any particular bug being present.
Which MCP controls survive a spec revision?
Given that the protocol is explicitly still evolving and that the security boundary sits in your implementation, the controls worth building are the ones that do not depend on which version you are on.
1. Decide before you ask
A risk determination — based on the tool, the arguments, the identity and the data classification — that runs before the MRTR round trip and decides whether to ask at all. Without it, MRTR is either noise or theatre.
2. Show the approver something decidable
The approval surface must render what the action will actually do, in terms the approver can evaluate. Record what was displayed, not just that approval occurred. The difference between "approved at 14:32" and "approved at 14:32, having been shown these parameters" is the difference between a log and evidence.
3. Enforce outside the agent
If the model decides whether an operation needs approval, there is no control. The threshold has to live in a layer the agent passes through and cannot reconfigure or bypass — which also means it survives a change of model.
4. Record for the audit, not the debugger
The NSA's formulation — exact parameters, identities involved, cryptographic hashes of results — describes an audit trail, not application logging. It has to be tamper-evident, retained on the compliance clock rather than the log-rotation clock, and it must capture the model and policy version in force, because an agent's behaviour cannot be reproduced by re-running it later.
Where this connects to regulation
None of the above is driven by MCP-specific law, because none exists. It is driven by regimes that already apply to whatever the agent touches:
- UK — UK GDPR Articles 22A–22D since 5 February 2026, where "meaningful human involvement" decides whether the regime engages at all. Full analysis.
- Switzerland — Art. 21 DSG information and human-review rights, plus FINMA's expectation of an AI inventory with risk classification and independent review. Full analysis.
- Denmark — NIS 2-loven § 7, where the management body must approve the measures personally. Full analysis.
- United States — California's ADMT access-to-logic and appeal rights, and FINRA's 2026 report naming scope creep and auditability of multi-step reasoning as supervisory risks. Full analysis.
- EU — the AI Act as amended by Regulation (EU) 2026/1744, in force 27 July 2026, which deferred Annex III high-risk obligations to 2 December 2027 and Annex I to 2 August 2028, while leaving the transparency obligations applying from 2 August 2026.
The through-line across all five is the same requirement stated in five vocabularies: show what the system did, on what basis, with whose authorisation, long after the fact.
Frequently asked questions
What is MRTR?
Multi Round-Trip Requests (SEP-2322). A server returns resultType: "input_required" with input requests and opaque state; the client re-sends the original request with responses. A stateless way to put a human in the loop.
What broke in the 2026-07-28 release?
Nine major changes, including removal of protocol-level sessions and Mcp-Session-Id (SEP-2567), removal of the initialize handshake (SEP-2575), polling instead of blocking tasks/result, and a required resultType on every result.
Is the specification final?
No — it is marked Current. It may still receive backwards-compatible changes.
Does MRTR make my deployment compliant?
No. It provides the mechanism to ask a human. Deciding when to ask, what to show, and how to evidence the answer remains the implementer's responsibility.
How long do deprecated features last?
At least twelve months, floored at ninety days on the expedited path, which requires an active security risk and Core Maintainer approval.
Where this leads
The specification did the part a specification can do: it gave the ecosystem a standard way to pause for a human and a standard way to manage enterprise authorization. What it explicitly did not do — and said so — is decide when to pause, what to show, or how to prove it afterwards.
BarzelVault is built for that layer: pre-execution authorization with immutable action hashing, deterministic risk scoring, policy-as-code with versioning and rollback, human-in-the-loop approval with expiry and escalation, credential isolation so agents never hold plaintext secrets, atomic spend and action limits, an emergency kill switch, and cryptographically signed audit receipts. It sits in front of MRTR rather than replacing it.
In practice
Permission before the action. Evidence after it.
The duties on this page attach to the moment an automated system acts: who permitted it, on which data, under which policy version, and what a person saw before approving. Barzel enforces that decision before execution and writes the record an auditor, a regulator or a data subject can be shown.
MCP 2026-07-28: approval and authorization primitives are now in the protocol
BarzelVault
The AI action firewall: decide what an agent may do before it does it.
- Approval thresholds and policy checks enforced before execution; human approvals that expire and escalate.
- Cryptographically signed audit receipts: trigger, inputs, policy version, approver, outcome.
- Credential isolation, spend and action limits, and an emergency kill switch.
Free tier: 10,000 calls a monthPaid plans from $199 a monthLive on MCPize
Barzel Central Gateway
The AI governance control plane: one inventory and one policy layer across every MCP server and agent.
- Registers and synchronises every tool; enforces identity, policy, region, cost and health per tool.
- Identity mapping through OIDC, Entra ID, Okta, SAML and SPIFFE, with credential brokerage.
- Trace and SIEM export (W3C trace context, OTLP) for the security team and the regulator.
Free tier: 1,000 calls a monthPaid plans from $10 a monthLive on MCPize
Enterprise: written quote by email within two business days. No sales call.
Sources
- Model Context Protocol, The 2026-07-28 Specification and changelog; versioning and feature lifecycle policy — modelcontextprotocol.io.
- SEP-2322 (MRTR), SEP-2567 (sessions), SEP-2575 (handshake), SEP-2663 (Tasks).
- NSA, CSI: Model Context Protocol (MCP) — Security Design Considerations for AI-Driven Automation, Ver. 1.0, May 2026.
- SecurityWeek, New Enterprise-Ready MCP Specification Brings New Security Challenges (Akamai commentary).
- NVD, CVE-2026-75130; Noma Security, ContextCrush, 5 March 2026; VulnCheck advisory.
- Prevalence studies: Endor Labs (2025), Equixly (Feb 2026), BlueRock (2026), Enkrypt AI (Oct 2025), Astrix (Oct 2025).
- Regulation (EU) 2026/1744, in force 27 July 2026.
This article is for information and does not constitute legal or security advice.