Notifications
Clear all
Topic starter
06/07/2026 9:40 am
TL;DR: Dynamic Client Registration and Client ID Metadata Documents are emerging as two approaches to agent identity onboarding in MCP environments, with DCR better suited to curated, long-lived clients and CIMD better suited to dynamic fleets, according to Descope. The governance question is no longer registration convenience but which model can hold up under agent churn, validation, and URL-based trust assumptions.
NHIMG editorial — based on content published by Descope: DCR vs CIMD for agentic identity in MCP environments
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.
Questions worth separating out
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.
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.
Q: What breaks when client identity depends on weak metadata validation?
A: Weak validation turns metadata into a trust bypass.
Practitioner guidance
- 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.
- Validate metadata before trusting CIMD Require HTTPS integrity, domain ownership checks, and validation rules for any client-hosted metadata document.
- 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.
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
👉 Read Descope's analysis of DCR vs CIMD for agentic identity in MCP systems →
DCR vs CIMD for MCP clients: is your identity model keeping up?
Explore further
06/07/2026 9:56 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: DCR vs CIMD for agentic identity: what changes for MCP security
