Anton Staykov

Posted on Aug 17

Dynamic client registration and CIMD are not a trust framework

#oauth #security #zerotrust #apimanagement

The MCP specification ships with a strong opinion about how AI clients should onboard with authorization servers: dynamically, at runtime, without pre-coordination (MCP authorization spec). The AI community has largely nodded along. Enterprise security teams have largely not been consulted.

That mismatch is the subject of this article.

DCR and CIMD are genuinely useful protocol mechanisms. They are not a trust framework. And in an era where supply chain attacks are the dominant enterprise threat vector, confusing the two is a governance failure waiting for a specific client name to trigger it.

What DCR was designed to remove

RFC 7591 - OAuth 2.0 Dynamic Client Registration Protocol solves a real problem. The traditional OAuth onboarding sequence requires a developer to pre-register their client application with the authorization server, receive a client_id and client_secret, configure redirect URIs, and coordinate with whoever manages the identity provider before a single token can flow. For SaaS products, open developer ecosystems, and multi-tenant platforms, this ceremony is expensive. Teams wait days for provisioning. Integration partners hit identity-team backlogs. CI pipelines stall on human approvals.

DCR automates the ceremony. The client POSTs a JSON body describing itself to the authorization server's registration_endpoint. The server returns a client_id and client_secret immediately. No human approval. No pre-coordination. Developer velocity restored.

That is a genuine improvement in the right context. Public MCP servers, open developer tooling, and hobbyist integrations benefit from it directly. The friction reduction is real, and dismissing it is wrong.

The problem is not the protocol. The problem is the assumption that registration equals authorization, and that authorization equals trust.

What CIMD adds to the picture

Client Information Meta Data (CIMD) refers to the structured metadata fields a client submits in the DCR request, and through RFC 7592 (Dynamic Client Registration Management), the management endpoint that lets a registered client later read back and update its own registration record.

The metadata fields are richer than they appear at first. A client can declare its client_name, client_uri, redirect_uris, grant_types, scope, logo_uri, and most interestingly a software_statement (RFC 7591 §2.3). A software statement is a signed JWT issued by a third party the authorization server trusts, asserting facts about the client software: who built it, what version it is, what it is intended to do. It is the closest thing RFC 7591 has to attestation.

CIMD improves signal quality. It gives authorization servers structured, machine-readable metadata to work with. It makes client inventory possible in principle: if you log registrations, you at least know the name each client claimed. Software statements, when an authorization server validates them against a trusted issuer, move the model from "self-asserted identity" to "third-party asserted identity."

The critical word is when. Software statement validation is optional in RFC 7591. Most MCP server implementations do not enforce it. A client that omits the software_statement field registers exactly as successfully as one that includes it. The registration endpoint cannot distinguish a vetted corporate tool from a novel command-line script someone assembled over a weekend and pointed at your server.

CIMD raises the quality of information available at registration time. It does not answer whether your organization approved this client to exist here.

The enterprise security gap

Security teams in regulated industries (financial services, healthcare, critical infrastructure, government) operate on a fundamentally different assumption about software trust than DCR's default model. They run approved-software programs. Patch management is gated on testing and change-board approval. In the most security-mature environments I have worked in across thousands of enterprise security conversations, even Windows Updates are staged, validated, and controlled before rollout to the fleet.

This is not bureaucratic paranoia. It is the appropriate operational posture given how supply chain attacks actually work.

SolarWinds demonstrated that a trusted vendor's signed software update is a viable attack vehicle. CVE-2024-3094 (XZ Utils) showed that a two-year social engineering campaign can insert a backdoor into a compression library that ships inside essentially every Linux distribution. The lesson from both is not "trust nothing." The lesson is that how you establish and revoke software trust matters as much as whether a signature is present, and that self-asserted identity for software is precisely the attack surface adversaries aim for.

Against that backdrop, consider what unrestricted DCR on an enterprise MCP server looks like. Any AI client (any command-line tool, any agentic orchestrator, any LLM-driven system) that discovers the server's registration_endpoint can register itself, receive credentials, and start calling your server's tools. The server knows the client's claimed client_name. It does not know whether your security team reviewed the client's code, whether the vendor passed your procurement process, whether the version running is the one that was reviewed, or whether the registration request is originating from inside your network perimeter or from an endpoint that was compromised last week.

The SOC analyst's question is not theoretical: "Show me every MCP client registered on this server, who approved each one, under which policy, and when that approval was granted." Unrestricted DCR makes that question unanswerable, or worse, the answer is "anyone who sent a POST to the right endpoint."

Small organizations face the same question. The compliance regime may be less formal, but the threat is not.

Entra's deliberate answer: explicit registration as a trust decision

This is where the AI community tends to frame a gap. It is not a gap. It is architecture.

Microsoft Entra ID has no RFC 7591 registration_endpoint. There is no URL on login.microsoftonline.com that accepts a DCR POST and returns client_id credentials at runtime. Every application that can receive Entra-issued tokens must be explicitly registered, through the Azure portal, the Microsoft Graph API, the Azure CLI, or ARM templates, by a principal holding at minimum the Application Developer role (register an application in Microsoft Entra ID).

That deliberate registration is not the end of the trust chain. It is the beginning of it. A registered application that has not been explicitly consented still receives no tokens. Consent in Entra is the authorization gate: the act that says "this application is authorized to call this API, with these permissions, under this policy." A well-named AI client with a convincing client_name and a polished client_uri gets nothing from Entra without a human trust decision in the chain. (For the full governance architecture behind this claim, see the article Why consent is the trust contract for Entra Agent ID.)

The MCP authorization specification is careful here: it states that clients SHOULD attempt DCR when the authorization server's RFC 8414 metadata includes a registration_endpoint. "Should," not "must." A well-behaved MCP client encountering an authorization server that publishes no registration_endpoint (which is what every Entra tenant presents) falls back to static registration. That fallback is the intended behavior. The friction is intentional, and its source is a governance posture, not a missing feature.

The honest tradeoff: Entra's model maximizes governance precision and eliminates runtime surprise about who can request tokens. It creates real friction for MCP clients that expect to self-register on first contact. That friction is a feature for regulated enterprise deployments. It is a genuine obstacle for open, developer-facing MCP servers where the audience is trusted developers and the stakes per registration are low. Both statements are true simultaneously.

APIM AI Gateway: the bridge, and where the gap remains

When you place Azure API Management's AI Gateway in front of your MCP server, you gain a set of controls that together approach what a governance-controlled DCR layer would look like, without implementing one. Understanding exactly what APIM provides, and what it does not, is what allows you to design the right architecture rather than assume a gap has been closed when it has not.

The first piece is discovery integration. APIM can expose the .well-known/oauth-protected-resource endpoint defined in RFC 9728, which tells DCR-capable MCP clients where to find the authorization server protecting this resource (secure access to MCP servers). When APIM points to Entra as the authorization server, the MCP client reaches Entra, discovers no registration_endpoint in Entra's RFC 8414 metadata, and falls back to static registration. The discovery flow runs correctly. The governance gate holds. APIM participates in the DCR protocol dance without becoming a DCR endpoint.

The second piece is runtime client enforcement via the validate-azure-ad-token policy. This policy accepts a <client-application-ids> block, an explicit allowlist of Entra application IDs whose tokens are valid at this gateway:

<validate-azure-ad-token tenant-id="your-entra-tenant-id"
    header-name="Authorization"
    failed-validation-httpcode="401"
    failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
    <client-application-ids>
        <application-id>approved-mcp-client-app-id</application-id>
    </client-application-ids>
</validate-azure-ad-token>

A client that was registered in Entra and consented (both explicit human decisions), but whose application ID is absent from this list, still cannot pass the gateway. That is two distinct human approval steps between "an AI client exists" and "that AI client can invoke your MCP server tools." This is the runtime equivalent of an enterprise approved-software list, enforced at the gateway rather than in application code.

For scenarios where Entra registration still introduces too much friction (third-party client integrations, short-lived automation, partner tooling), APIM's subscription key model is the highest-control alternative. Every MCP client consumer receives a key provisioned explicitly by an APIM administrator. No dynamic discovery. No self-registration. Full explicit provisioning per consumer, with gateway-level revocation that does not wait for a consent withdrawal to propagate through the identity layer.

The observability dimension is underweighted in most governance architecture conversations. APIM routes all MCP tool invocations through a single plane with Application Insights integration and the llm-emit-token-metric policy for per-consumer token tracking. The SOC analyst's question, "show me every client calling this server, what it consumed, and when", becomes answerable from a single observability plane. That audit trail is precisely what unrestricted DCR alone never provides.

The honest gap deserves explicit naming. Neither APIM nor Entra today offers a governance-controlled RFC 7591 registration endpoint: a /register that issues credentials only to clients that have passed a policy gate: an Entra consent check, an access package approval, or a security review workflow. APIM and Entra together approximate this behavior through a different mechanism: explicit Entra app registration as the consent prerequisite, gateway policy as the runtime enforcement layer. The interoperability friction with DCR-native MCP clients is real. The architectural slot for a "governed DCR endpoint" is currently unoccupied in the Microsoft stack.

That gap is worth naming because it is where the tooling will likely evolve. An architecture where APIM exposes an RFC 7591-compliant /register endpoint that, on receiving a DCR request, triggers an Entra app registration, initiates an admin consent workflow, and optionally assigns an access package, before returning credentials to the registering client, would close it elegantly. That architecture does not exist today as a native product feature. What exists is the layered governance model described above.

A governance stack, not a binary choice

The practical architecture decision is not "DCR or no DCR." It is: what governance controls stand between a client expressing interest and a client receiving credentials?

For open, developer-facing MCP servers where the audience is trusted developers, the data sensitivity is low, and the expected client population is diverse and changing, DCR with software statement validation and a lean consent model is appropriate. Lean does not mean absent: even here, logging registrations, validating software statements when present, and auditing active clients periodically are the minimum defensible posture.

For enterprise MCP servers that expose organizational data, internal APIs, financial workflows, or records subject to regulatory requirements, the bar is different. Every client should be named. Every registration should be a deliberate trust decision. Every token scope should be consented explicitly under a policy that your security and governance teams own.

APIM plus Entra delivers that model today. Entra's explicit registration and consent layer ensures no client receives tokens without a human decision in the chain. APIM's AI Gateway enforcement layer ensures no token-bearing client bypasses your runtime policy. The observability layer ensures that "who approved this, with which permissions, and when" remains answerable across the full client lifecycle.

CIMD metadata enriches the picture on the way in: software statements, declared grant types, client URIs. Use them where your authorization server or gateway policy can act on them. Do not treat "richer metadata at registration time" as a substitute for governance state. Those are different properties, and conflating them is the precise mistake that makes a SOC analyst's life difficult six months after a pilot launches.

DCR is useful. CIMD is useful. Neither is a trust framework. The security teams that built enterprise software approval programs did not do it for the friction. They did it because supply chain attacks are real, and the moment you stop asking "who approved this software to exist here" is the moment a well-named binary with a convincing client_name receives credentials to your organizational data.

APIM AI Gateway and Entra's explicit registration model is the closest the Microsoft stack comes today to answering that question at MCP server scale. The remaining gap is a named target. The governance floor is already in place.

DEV Community