MCP 2026-07-28: Real Auth for AI Agents

On July 28, 2026, a major update to the MCP (Model Context Protocol) spec ships under that very date: 2026-07-28. The release candidate landed on May 21, and the final spec arrives July 28. Its headline change is a rebuild of authentication and authorization for AI agents — moving from "bring your own token" to a unified, protocol-level security model.

The problem that grew with agents

Early on, authorization in MCP was essentially undefined: each server figured it out alone. That works with one server, but the real world now has a single agent talking to many MCP servers at once. In that world, weak authorization semantics are the difference between a useful agent and a security incident: a token issued for server A could be misused to reach server B, or replayed across servers. This isn't a small implementation detail — it's the core of trust.

What actually changed

The update makes MCP servers formal OAuth 2.1 resource servers, with clear rules:

• Protected Resource Metadata (RFC 9728): every server exposes a .well-known/oauth-protected-resource endpoint or adds resource_metadata to its WWW-Authenticate header, so the client knows where to ask for authorization.
• Audience binding (RFC 8707): the client explicitly states which server a token is for, so a malicious server can't obtain a token meant for another.
• Issuer verification: the client validates the authorization server's identity and binds credentials to it, closing cross-server replay.
• CIMD over dynamic registration: Client ID Metadata Documents are now preferred over DCR (RFC 7591), which stays for backward compatibility.

And it isn't only auth: the protocol moves to a stateless design, adds full JSON Schema 2020-12 for tool schemas, and introduces an extensions framework with reverse-DNS identifiers.

A practical example

The flow starts with a 401 that points the client onward:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

The client reads the protected-resource metadata:

{
"resource": "https://mcp.example.com",
"authorization_servers": ["https://auth.example.com"],
"scopes_supported": ["tools.read", "tools.call"],
"bearer_methods_supported": ["header"]
}

Then it requests a token bound to that specific server via the resource indicator:

POST /token HTTP/1.1
grant_type=authorization_code&code=...&resource=https://mcp.example.com

Real-world caveats

• The spec is still a release candidate until July 28, with a ~10-week window for SDK maintainers to validate and adopt.
• DCR still works, but CIMD is the preferred path; desktop and CLI clients need registration that matches real deployment (for example, localhost redirect URIs).
• Existing servers carry migration work: exposing metadata, validating audience and issuer, and defining scopes.

The takeaway

Pushing security down to the protocol turns auth from something every server reinvents into a shared, enterprise-ready foundation. Safer agents can do more, and secure tooling multiplies a developer's reach rather than replacing it — much like the new QUERY HTTP method we looked at recently, the standards layer keeps maturing step by step. Prepare your servers now, and you walk into July 28 ready.

Primary source: the official MCP specification repo.