MCP 2026-07-28 authorization hardening

The document exists. The ledger fetched it at its publisher and quotes it.

Record ID

AAL-2026-0006

Kind

Standard or protocol

Jurisdiction

Global

Last verified

15 September 2026

Added

15 September 2026

• The release post states that authorization servers should return the iss parameter per RFC 9207, and clients must validate it before redeeming a code.
• It states that client credentials are bound to the issuer that minted them, with no reuse across authorization servers.
• It states that Dynamic Client Registration is now formally deprecated in favor of Client ID Metadata Documents.
• Clients set application_type during dynamic client registration so authorization servers stop rejecting localhost redirects for desktop and command line apps.
• The specification keeps RFC 9728 protected resource metadata as a must for servers and adds OpenID Connect Discovery as an accepted discovery mechanism.

Identity, Authorization, Limits. Stated means the document you can open below says it; silent means the ledger read the document and it does not.

IdentityStated

A client identifies itself by an HTTPS URL that resolves to its own metadata document, so the client's identity is fetched rather than self asserted at registration time.Model Context Protocol specification 2026-07-28, Authorization, primary source, 28 July 2026.

AuthorizationStated

The issuer of the authorization response must be recorded and compared before the code is redeemed, which closes the mix up attack.Model Context Protocol specification 2026-07-28, Authorization, primary source, 28 July 2026.

LimitsStated

Scope challenges are authoritative for the current operation, and clients union previously granted scopes rather than losing them on a step up.Model Context Protocol specification 2026-07-28, Authorization, primary source, 28 July 2026.

If you pinned an MCP client to the 2025 revision, the upgrade is not cosmetic. Two behaviours are new work: validating the issuer on every authorization response, and moving off dynamic client registration to a metadata document you host. Both reduce the chance that your agent hands a code or a credential to the wrong authorization server.

1. Model Context Protocol blog, 2026-07-28 releasePrimary · 28 July 2026
2. Model Context Protocol specification 2026-07-28, AuthorizationPrimary · 28 July 2026

• VerifiedStandard or protocolAAL-2026-0004

  Model Context Protocol authorization

  Global · verified 15 September 2026

  Authorization servers must implement OAuth 2.1 with appropriate security measures for both confidential and public clients.

• VerifiedGuidanceAAL-2026-0005

  Model Context Protocol security best practices

  Global · verified 15 September 2026

  Token passthrough is an anti pattern where a server accepts a token from a client without validating it was issued to that server, and the document forbids it.

• VerifiedStandard or protocolAAL-2026-0011

  RFC 7591, OAuth 2.0 dynamic client registration

  Global · verified 15 September 2026

  The specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers.

• Open questionOpen questionAAL-2026-0034

  Does a spending limit belong to the agent or to the principal

  Global · verified 15 September 2026

  The Visa Trusted Agent Protocol addresses recognising an approved agent and its intent, and does not itself carry a spending ceiling.

• Open questionOpen questionAAL-2026-0033

  How does a sub agent's authority attenuate

  Global · verified 15 September 2026

  RFC 8693 lets a token record that one party is acting for another, but does not require the exchanged token to be narrower.

• Open questionOpen questionAAL-2026-0032

  Can an agent hold a credential of its own

  Global · verified 15 September 2026

  NIST SP 800-63-4 states that for that publication, person refers only to natural persons.