MCP rewrites itself. Here's what to ask your vendors now.

Governance Watch — our take on the news a compliance owner actually has to answer for.

Today the Model Context Protocol — the plumbing that lets AI tools reach your data — lands the largest revision in its history. You are not going to read a protocol changelog, and you shouldn't have to. But this one is worth ninety seconds, because it changes what you are entitled to ask an AI vendor. Until now, "we support MCP" was a claim with no version number attached, which made it a claim you couldn't test. That is about to stop being true.

What happened

The MCP revision dated 2026-07-28 is the biggest rewrite since the protocol launched in late 2024. The specification and its full changelog are published at that dated address, and the protocol's current revision moves from 2025-11-25 to this one around today.

That timing is worth understanding, because it tells you what to expect from your vendors. This was not a surprise drop. The revision was locked as a release candidate on May 21 with an explicit ten-week window for SDK maintainers to validate it against real workloads; beta SDKs followed on June 29. The date on the specification is the end of that schedule, not the start of one — which means the text is settled well ahead of the software. Your vendors' SDKs and connectors will catch up over the following weeks. A vendor telling you in August that they haven't migrated yet is describing the plan, not dodging you; a vendor who can't tell you which revision they're on is a different conversation.

MCP versions are dates rather than numbers: the identifier is the last day backwards-incompatible changes were made.

The session is gone. MCP no longer has one. The initialize handshake and the Mcp-Session-Id header are both removed, and connection details now ride along on every individual request. This is good engineering — servers can scale on ordinary infrastructure instead of pinning each user to one machine. It also means the thing that tied a run of AI actions together into one identifiable episode is no longer part of the protocol. In its place the spec documents W3C Trace Context — the same traceparent your engineers know from distributed tracing, now carried in the message body.

Four features were formally deprecated, and one of them is the protocol's own logging. The normative list, from the specification's deprecated features registry:

Alongside that, the authorization rules tightened in your favor — clients must now verify which authorization server answered them, closing a class of attack where a client connected to many servers can be tricked into handing the wrong one a token.

Why it matters

The honest read: this release makes MCP safer to connect and makes the evidence more clearly your problem. Both at once. Don't let anyone sell you only one half of that.

The safety half is real, and the most under-reported item is the one an identity person will care about. Dynamic Client Registration let software show up at an authorization server and enroll itself on the spot, with no prior relationship. Client ID Metadata Documents invert that: a client's identity becomes a URL it publishes and controls, which you can go read. "Which software is holding this token, and who publishes it?" moves from unanswerable to a link you can open — a direct improvement to the agent identity problem.

The evidence half is the one that lands on your desk. Be precise, because this is easy to overstate: MCP's logging feature was never your audit trail. It was debug messages from a server to whatever app was driving it; nobody's compliance file was built on it. What changed is that the protocol has now put in writing, with a date on it, that observability is somebody else's job — pointing at OpenTelemetry rather than keeping a feature of its own. Combine that with the session going away, and the record of what your AI did is assembled entirely by your vendor's engineering choices, with no protocol default underneath. If they instrument it, you can be handed a trail. If they don't, there is nothing to request.

The uncomfortable translation: whether you can answer "can you show me what your AI touched?" now depends entirely on a vendor's engineering choice — which you can find out by asking.

MCP is now a dated, citable thing. Every server implements a revision with a date, every deprecation carries a published removal date, and the lifecycle policy is public — which turns a vague technology question into one your program already knows how to file.

What it means for you

If you're a credit union or community bank — nothing in your obligations changed today; the specificity available to you did. Your TPRM program already covers these connectors, or should — that argument is MCP servers as third-party vendors. What's new is that "which MCP revision do you implement, and how do you emit audit telemetry?" is now a fair question with a right answer, not a conversation that dead-ends in adjectives. Add it as a field on the questionnaire, not as a project. And keep proportionality: a read-only calendar connector does not need a telemetry architecture review, and NCUA diligence has always been explicitly proportional (07-CU-13 / SL 07-01).

If you're an RIA or broker-dealer — Reg S-P's requirement for ongoing oversight of service providers (17 CFR 248.30(a)(5)) is where this bites, and the biting edge is the 72-hour breach-notice clock. Ongoing oversight of a vendor mid-way through its largest-ever breaking revision is not a box you checked last year. Two questions, both answerable in an email: which revision are you on, and when you migrate, what changes about the record I can get from you? A vendor who can't answer the first is telling you something. A vendor who answers the second with "we export OpenTelemetry traces" is handing you the thing Reg S-P wants you to have.

How to get ahead of it

1. Add one line to your AI vendor questionnaire. "Which MCP specification revision does your product implement, and what is your migration plan for 2026-07-28?" One sentence, and the quality of the answer tells you how seriously a vendor takes the protocol they're built on.
2. Ask who holds the log now. The follow-up: "What record exists of actions your product takes on our data, how long do you keep it, and can we receive it?" The word to listen for is OpenTelemetry — it means the trail exists in a standard format your tooling can ingest, rather than in a vendor's private dashboard until they decide otherwise.
3. Re-check anything that registered itself. Dynamic Client Registration is now on the clock. Ask your identity team whether any AI client enrolled itself that way, and flag those to revisit as vendors move to Client ID Metadata Documents — a small, finite piece of work that only gets bigger by waiting. (Our playbook on reading OAuth grants walks the mechanics.)
4. Write the date down: 2027-07-28. That's the earliest any of today's deprecated features can actually be removed. A full year of runway, published — the kind of concrete answer that settles a risk committee. Put it in the file with your reasoning; that record is the deliverable.

None of this is a project. It's four questions and a calendar entry. Doing it this quarter costs you an afternoon; doing it during an exam costs you the exam.

What to watch out for

• "We're on the latest MCP" is a better claim than it used to be — and still not a security claim. A revision number tells you a vendor keeps up. It says nothing about whether they scope tokens sanely, what they retain, or whether they'd tell you if they were breached — one input to diligence, not a verdict.
• Deprecated is not removed — don't let anyone panic you into a rip-and-replace. All four features keep working, and the policy guarantees at least twelve months. But read the exception: the feature lifecycle policy includes an expedited path with a ninety-day floor for an active security risk. Twelve months is the normal case, not a promise to plan three years around.
• Read the coverage as carefully as the spec. If you see an article saying this release newly mandates OAuth Resource Indicators (RFC 8707), that's wrong — that requirement dates to the 2025-06-18 revision, more than a year ago. When a vendor cites an article rather than the specification to explain their own posture, that's worth a second question.
• "Stateless" doesn't mean the tool forgets you. The protocol dropped its session; the application behind it retains whatever it likes. Don't read an engineering change as a data-retention improvement. Retention is a contract question, and it always was.

The bottom line

MCP spent twenty months becoming the default way AI reaches your data, and today it tightens the parts that protect you while stating plainly that the record-keeping belongs to somebody else. That somebody is your vendor, and the homework is small: which revision, and what trail can you give me. The institutions that come out of this well won't be the ones with an MCP policy — they'll be the ones who can produce a dated list of every AI connector touching their data. That inventory is what a Discover scan produces. Request your Discover scan — we run it with you.

Related: MCP, explained for people who get audited · MCP servers as third-party vendors · The agent identity problem · Reading OAuth grants