MCP moved client identity to a URL. The allow-list is yours to write.
The July 2026 specification deprecates dynamic client registration in favour of a metadata document the client hosts itself. That makes the calling application identifiable for the first time, and it makes deciding which applications are acceptable a decision nobody in most organisations currently owns.
An engineer connects an assistant to an internal document server over the Model Context Protocol. A browser window opens, the organisation’s own sign-in page appears, and behind it a consent screen asks whether an application may read files on this person’s behalf. The application has a name and a logo. Somebody clicks approve, the connector works, and the ticket closes.
Nobody in that organisation decided the application was allowed to appear on that screen. There was no register it had to be in and no review it had to pass — and until the specification published on 28 July 2026 a client the organisation had no prior relationship with carried no durable identifier to put on a list, even if somebody had wanted to keep one.
The claim: the MCP authorisation specification has given the calling application a stable, resolvable identity for the first time, and it has left the question of which identities are acceptable entirely outside the protocol. That question is answered by a trust policy in your own authorisation server. It is a small piece of configuration, it is currently nobody’s job, and it is the difference between an MCP estate that can be reviewed and one that cannot.
What changed on 28 July
The 2026-07-28 authorisation specification deprecates Dynamic Client Registration and points new implementations at Client ID Metadata Documents instead. Registration is, in the specification’s words, “retained for backwards compatibility with authorization servers that do not support Client ID Metadata Documents”.
The mechanics matter more than the deprecation. Under a metadata document the client identifier is an HTTPS URL, and that URL resolves to a JSON document the client hosts. The document has to carry a client identifier, a client name and a list of redirect URIs, and the identifier inside it has to match the URL exactly. The authorisation server fetches the document when it sees a URL-shaped identifier, checks that match, checks the redirect URI in the request against the list the document declares, and then shows the user a consent screen carrying the client name.
- 01 Client hosts A JSON document at an HTTPS URL it controls, naming itself and its redirect URIs.
- 02 Client presents The URL is the client identifier in the authorisation request.
- 03 Server resolves The authorisation server fetches the document and checks the identifier matches the URL.
- 04 Server validates Redirect URI against the document, document structure, and whatever domain policy the enterprise has set.
- 05 User consents The screen shows the name from the document. A token follows, bound to one resource.
Two properties follow from that, and both are worth having. The identifier is stable: the same client presents the same URL to every authorisation server, and the client registration rules note that identifiers of this kind are “portable across authorization servers” with no re-registration when the server changes. And the identifier is resolvable, so anyone can fetch the document and read what the client says about itself before a token is ever issued.
| Dynamic Client Registration | Client ID Metadata Documents |
|---|---|
| The identifier is opaque and minted per authorisation server | The identifier is an HTTPS URL that resolves to a document |
| Credentials are bound to the issuer and re-registration follows a change of server | The identifier is portable, and a change of server needs no re-registration |
| Nothing to put on a list, because the identifier did not exist before the request | A domain to put on a list, known before anything is approved |
| What the client says about itself is a registration payload nobody kept | What the client says about itself is a document anyone can fetch and re-read |
| Deprecated, and retained for servers that cannot do the other thing | The mechanism the specification directs new implementations towards |
The name on the consent screen is one the client chose
This is the part a security review has to get right, and it is easy to read past. The document is hosted by the client. The client name is a string the client wrote. The logo is an image the client serves. What the authorisation server validates is internal consistency — that the identifier matches the URL, that the redirect URI is on the declared list, that the JSON parses — and not that the application behind it is the one the person approving it believes they are approving.
The specification is honest about this. In its own worked flow, the validation steps are the identifier match, the redirect URI check and the document structure, followed by an item marked optional: the domain being allowed via a trust policy. The trust policy is the control. It is optional in the protocol because it cannot be anything else — only the enterprise knows which domains it is willing to see on a consent screen.
An identifier that says where a client comes from is an improvement. It becomes a control only when somebody writes down which origins are acceptable.
That is a different position from the one registration left behind. Under Dynamic Client Registration an unknown client obtained an opaque identifier and there was nothing to allow-list, so the honest answer to “which applications may ask my staff for access to internal systems” was that the question could not be asked. Under metadata documents the question can be asked, and the machinery to enforce the answer sits in an authorisation server the organisation already runs. What is missing is the list.
What to do about it
Two of those carry most of the value. The first is the origin list, because it is the only item that converts an identifier into a decision, and because it is cheap while the estate is small and expensive once forty connectors are in use. The second is the re-read. Metadata documents are cached according to ordinary HTTP cache headers, which means the document that was reviewed is not necessarily the document that will be resolved next month. A client approved on the strength of its declared redirect URIs can publish different ones, and nothing in the protocol will tell you that it did.
The procurement consequence is blunter. A supplier statement that a product “supports MCP” answers nothing that a reviewer needs, because authorisation is optional in the specification, the local transport is excluded from it, and the authorisation machinery an enterprise is most likely to want — Enterprise-Managed Authorization among it — sits in extensions the specification describes as optional and additive rather than in the core. Three questions replace the assurance: which transport, which registration mechanism, and which extensions.
What this does not tell you
The metadata document mechanism rests on an IETF draft rather than a published RFC, and the specification cites it at its initial draft revision. Drafts change, and a control built on one is a control to revisit rather than to write once.
None of this reaches the part of the estate most organisations should worry about first. The specification states that authorisation is optional for MCP implementations, and that implementations using the local transport “SHOULD NOT follow this specification, and instead retrieve credentials from the environment”. The servers running on employee laptops with a key in an environment variable are outside every paragraph above, and they are where the unmanaged surface actually is.
Client identity is also not agent identity. Knowing which application is asking does not tell you on whose authority it acts, what it may reach, or when its credential expires. The protocol’s roadmap of 22 August 2026 puts proof of possession and workload identity federation next, which is an acknowledgement that the delegation problem is still open rather than a solution to it.
And this is an architecture control, not evidence. Configuring an authorisation server does not discharge an obligation under any regime, and nothing here should be read as a legal position on one. It reduces the number of parties who can ask your staff for access, which is worth doing on its own terms.
The person who decides differently is whoever owns the authorisation server the assistant redirects to — usually the identity platform team rather than the AI programme, which is exactly why this has not been decided. Ask them for the list of origins. If the answer is that any client that can host a JSON file may reach the consent screen, that is the current policy, and it was set by a default rather than by anyone.