DCR vs CIMD for agentic identity: what changes for MCP security

At a glance

What this is: This is an analysis of DCR versus CIMD for agentic identity in MCP environments, with the central finding that CIMD fits dynamic client fleets better while DCR still suits tightly governed, long-lived clients.

Why it matters: It matters because identity teams now need to decide how agents register, how their metadata is trusted, and how much lifecycle control belongs in the server versus the client across NHI, autonomous, and human programmes.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Descope's analysis of DCR vs CIMD for agentic identity in MCP systems

Context

Dynamic client registration and client metadata documents are both identity patterns for machine and agent onboarding, but they make different assumptions about where trust lives. DCR centralises registration state on the server, while CIMD shifts identity metadata to a client-hosted document that is fetched on demand.

For identity and access teams, the real question is not which protocol is newer. It is whether the organisation can govern short-lived clients, dynamic agent fleets, and metadata validation without creating a registration bottleneck or weakening assurance for MCP-connected systems. The same governance pressure appears in the broader NHI lifecycle problem, where discovery, verification, and offboarding rarely keep pace with runtime change.

Key questions

Q: How should security teams decide between DCR and CIMD for agent registration?

A: Use DCR when clients are long-lived, curated, and manageable through a persistent registry. Use CIMD when the environment has frequent client churn, distributed discovery, or many agentic components that need on-demand identity publication. The decision should follow the client lifecycle and trust model, not vendor preference or implementation convenience.

Q: Why do dynamic agent environments make registration governance harder?

A: Dynamic agent environments create more identity objects, more trust changes, and more validation events than static systems. That means the registration model must handle churn, verification, and revocation at runtime. When governance still assumes slow-changing clients, the result is control drift, registry overload, or unsafe shortcuts.

Q: What breaks when client identity depends on weak metadata validation?

A: Weak validation turns metadata into a trust bypass. If a system cannot reliably confirm who controls the document, where it is hosted, and whether the fetch path is safe, attackers can impersonate clients or redirect discovery into untrusted infrastructure. In practice, that weakens the entire authentication flow.

Q: Who is accountable when agent registration fails or is abused?

A: Accountability sits with the team that owns the identity control plane, not with the protocol name. Security, platform, and IAM functions must agree on who approves client classes, who reviews anomalies, and who responds when registration or metadata trust is abused. Frameworks such as Zero Trust and NHI governance help define those boundaries.

Technical breakdown

DCR registration state and why it becomes brittle at scale

Dynamic Client Registration creates a server-managed registry of clients that can be discovered, approved, and stored before use. That model works when the client population is stable and the registration surface is controlled. In MCP-style environments with short-lived runners, agent submodules, or frequent ephemeral clients, the registry itself becomes the burden: storage grows, operational review becomes slower, and the trust model depends on maintaining accurate server-side state. The protocol is not broken. The operating assumption is that the set of clients is manageable enough to keep in a persistent registry.

Practical implication: treat DCR as a governed onboarding pattern for stable clients, not a default for high-churn agent ecosystems.

CIMD metadata fetching and the trust shift to URLs

Client ID Metadata Documents replace server-side registration with a client-hosted JSON document available at a stable HTTPS URL. The identity check moves from persistent registry management to validating that the metadata source is authentic, reachable, and not being manipulated. That improves scalability, but it also creates a different control surface: domain control, URL integrity, cache behaviour, and document authenticity now matter more than registry size. In other words, the client becomes its own identity publishing point, which is useful only if the organisation can validate what it is fetching and why.

Practical implication: build URL authenticity and metadata validation controls before adopting CIMD for broad agent registration.

Registration abuse, impersonation, and SSRF are different failure modes

The article correctly separates DCR’s operational abuse from CIMD’s fetch-path risk. DCR can be stressed by junk registrations and impersonation attempts, especially when open endpoints are accepted without enough source validation. CIMD reduces registry churn, but it introduces URL-based attack paths, including server-side request forgery if metadata fetches can be redirected or tampered with. The security issue is not simply registration. It is whether the trust boundary is anchored to a durable authority or exposed through a dynamically fetched identity document.

Practical implication: model DCR and CIMD as different threat surfaces and apply different controls to each.

Threat narrative

Attacker objective: The attacker’s objective is to turn a registration or metadata trust mechanism into a path for unauthorized client identity and downstream access.

1. Entry occurs when an attacker abuses exposed registration endpoints in a DCR environment or manipulates a metadata URL in a CIMD environment to enter the identity flow.
2. Escalation follows when the attacker leverages weak validation to impersonate a client, overwhelm the registry, or redirect metadata fetching into an untrusted trust path.
3. Impact is unauthorized agent registration, compromised client identity, or malicious access into MCP-connected systems through a trusted identity channel.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

DCR and CIMD are not competing features so much as competing trust assumptions. DCR assumes the identity authority should hold persistent state about clients. CIMD assumes the client can safely publish its own identity metadata and that the receiving system can validate it on demand. That difference matters because identity governance fails when teams confuse convenience with assurance. Practitioners should decide which side of the trust boundary they are prepared to operate on, not just which flow is easier to ship.

Runtime identity governance for MCP clients: the real issue is whether the organisation can govern clients that appear, authenticate, and disappear at machine speed. DCR is shaped for slower lifecycle control, while CIMD is shaped for on-demand discovery. That makes CIMD attractive in dynamic ecosystems, but it also means lifecycle controls such as verification, source trust, and revocation must be designed for continuous change, not periodic administration. Teams should treat this as a governance model decision, not a protocol preference.

Open registration is a scaling decision with security consequences, not a neutral convenience. The article notes that DCR can be vulnerable to registration endpoint abuse and client impersonation, while CIMD must defend against metadata authenticity issues and SSRF. Those are different failure modes with different control expectations. The takeaway for identity programmes is that the more dynamic the agent population, the more the organisation must move from static entitlement thinking to runtime trust validation.

Hybrid client registration is the most realistic operating model for many enterprises. Long-lived enterprise clients may still justify DCR, while ephemeral or frequently instantiated agents may need CIMD. That split is not a compromise in maturity; it is a recognition that different identity classes require different governance paths. The practitioner implication is to define registration policy by client behaviour, not by a single protocol standard applied everywhere.

Agent identity is already crossing from NHI governance into autonomous-system governance. The article centres on registration, but the strategic signal is broader: if agentic systems register dynamically, then identity teams need a model that can follow runtime behaviour as well as initial onboarding. That is where NHI lifecycle, authentication assurance, and emerging agentic controls begin to converge. Practitioners should plan for identity governance that can span human, machine, and agentic contexts without collapsing them into the same control pattern.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how quickly machine identity oversight breaks down at scale.
• That visibility gap is why lifecycle control needs to be grounded in Ultimate Guide to NHIs - Lifecycle Processes for Managing NHIs rather than in registration convenience alone.

What this signals

Runtime trust will matter more than registration simplicity as MCP ecosystems expand. DCR and CIMD are both workable, but they force programmes to choose where the authoritative identity state lives. Teams that still manage machine identities as static objects will struggle when agents register, disappear, and reappear faster than review cycles can keep up.

Identity teams should start treating client metadata as a governed control surface. That means logging metadata source changes, validating ownership, and deciding when a host-published document is trustworthy enough to participate in authentication. The same discipline applies whether the subject is a service account, workload, or agentic client.

Agent registration policy should be written alongside NHI lifecycle policy, not beside application onboarding. If DCR is used for long-lived clients and CIMD for dynamic ones, the programme needs one consistent model for verification, revocation, and exception handling. Without that, the organisation will have protocol choices but no real governance.

For practitioners

• Define registration policy by client behaviour Use DCR only for long-lived or tightly curated clients, and reserve CIMD for dynamic fleets that actually benefit from on-demand discovery. Document which identity classes belong in each path so teams do not improvise registration choices during deployment.
• Validate metadata before trusting CIMD Require HTTPS integrity, domain ownership checks, and validation rules for any client-hosted metadata document. Treat the metadata fetch as an identity control point, not a routine lookup, because that is where trust can be redirected or poisoned.
• Limit open registration exposure Restrict who can hit registration endpoints, add source-based controls, and review client creation events for impersonation patterns or abnormal churn. Open registration without guardrails turns onboarding into an attack surface.
• Separate lifecycle controls from protocol choice Write one lifecycle policy for verification, revocation, and review that applies across DCR and CIMD, then define the operational differences needed for each. That keeps governance consistent while allowing the execution model to vary.

Key takeaways

• DCR and CIMD solve the same onboarding problem but assume very different trust models, so protocol choice is an identity governance decision rather than a technical preference.
• CIMD improves scalability for dynamic agent fleets, but it shifts security pressure onto URL authenticity, metadata validation, and fetch-path control.
• Identity teams should govern client registration by lifecycle and risk, not by whether the protocol is familiar to developers.

Key terms

• Dynamic Client Registration: Dynamic Client Registration is a protocol pattern that lets clients register themselves with an authorization server programmatically instead of being preloaded by hand. It reduces onboarding friction, but it also creates a persistent registry that must be governed, monitored, and protected like any other identity control plane.
• Client ID Metadata Document: A Client ID Metadata Document is a client-hosted identity record, usually fetched from a stable HTTPS URL, that describes who the client is and how it should be trusted. It shifts authority from server-side registration to published metadata, which makes validation, ownership, and fetch-path security central to the control model.
• MCP: MCP, or Model Context Protocol, is an interoperability layer for connecting AI models and agents to tools and data sources. In identity terms, it matters because the protocol expands the number of clients that need trustworthy onboarding, authentication, and lifecycle control.
• Client identity impersonation: Client identity impersonation occurs when an attacker convinces a system that a malicious client is a trusted one. In machine and agent environments, this often happens through weak registration controls, poor metadata validation, or trust placed in identifiers that were never strongly bound to a real authority.

What's in the full article

Descope's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step explanations of the DCR and CIMD flows for MCP client onboarding
• The article's protocol comparison table showing registration model, state management, scalability, and security considerations
• Descope's implementation discussion for supporting DCR, CIMD, or both inside an agent identity hub
• The registration risk-assessment flow, including IP, geo, and third-party risk checks

👉 Descope's full post covers the protocol trade-offs, security considerations, and implementation flow in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.