On May 17, 2026, MCP SEP-2468 landed in the Model Context Protocol specification—proposed March 25 and accepted May 5. The change adopts RFC 9207's iss parameter for OAuth authorization responses, requiring clients to validate that the issuer field matches byte-for-byte what they recorded when starting the flow. It's a small addition with an outsized security payoff: it closes the OAuth mix-up attack family in any MCP host that trusts more than one identity provider at the same time.

The Problem SEP-2468 Solves

Picture this: your MCP host trusts corporate SSO, a partner IdP, and a developer-local identity provider for local testing. Three ASes, all legitimate, all trusted. An attacker who controls—or just has a valid registration at—any one of them can swap authorization codes between servers. The client completes the flow thinking it's talking to idp-a.example, but the access token was minted from an attacker's session at idp-b.evil. No scope was abused. No tool was compromised. The stack's guardrails never fired because the confusion happened one layer above where those checks live—in the client's uncertainty about which AS actually replied.

The Doorman Metaphor

Think of it as a club with one name on the guest list. A guest walks up, but without a wrist stamp, the doorman has no way to know if they came from the right venue or the bar next door. He has to guess from session state—which is exactly what an attacker exploits. RFC 9207's iss parameter hands the client a stamped wrist: the authorization server prints its own name on the response. The client reads it, compares letter for letter against what it recorded when initiating the flow (per RFC 3986 §6.2.1 simple string comparison), and decides on the spot. Match → proceed to token exchange. Mismatch → reject, no matter how legitimate the rest of the payload looks.

Why Capability Scoping Can't Fill This Gap

Here's the part that trips people up: capability scoping limits blast radius if a tool gets compromised, but it does nothing for mix-up attacks because the attacker isn't touching tools at all. They are exploiting which IdP authenticated the user—a question no scope setting answers. You could lock down every tool to read-only with zero exfiltration vectors, and an attacker still wins if they swap responses between your corporate SSO and a partner's IdP. The eventual access token will look completely valid because it was issued by a legitimate AS—just from the wrong user's session. That's why SEP-2468 sits below capability scoping in Layered Guardrails: it's structural defense that removes confusion at the protocol level, not another policy knob to tune.

What Actually Changes

The diff is small but precise: authorization servers advertise iss support in their metadata and include it on responses; clients compare response.iss against recorded issuer using simple string comparison; for ASes that don't advertise iss support, clients may apply local policy. Single-IdP flows are unaffected—the comparison becomes https://idp-a.example == https://idp-a.example and continues as before. The boundary is multi-IdP topology: the exact scenario production MCP hosts are increasingly running into with hybrid corporate-plus-partner deployments.

Key Takeaways

  • SEP-2468 adopts RFC 9207's iss parameter, requiring byte-for-byte validation against recorded issuer
  • Structural defense that removes OAuth mix-up confusion at the protocol layer—no policy tuning required
  • Capability scoping remains complementary but can't substitute for issuer verification
  • Single-IdP flows unaffected; multi-IdP topology is where the check earns its keep
  • Simple string comparison per RFC 3986 §6.2.1 makes it hard to mis-implement

The Bottom Line

This is exactly what defense-in-depth looks like done right—a tiny, fixed-shape addition that's easy to implement correctly and nearly impossible to botch in a way that reintroduces the vulnerability. If you're running an MCP host with multiple trusted IdPs and you haven't audited your authorization flow since before May 17, 2026, this is your signal to check whether your clients are validating iss.