Why does Dynamic Client Registration create governance problems for MCP?

Dynamic Client Registration works well for isolated apps, but MCP environments can produce many short-lived or duplicated client instances. That creates identity sprawl, larger expiry burdens, and a broader review surface for operators. The governance problem is not the protocol itself, it is the number of managed identities it can generate.

Why This Matters for Security Teams

dynamic client registration is attractive because it removes friction for legitimate integrations, but MCP changes the governance problem by multiplying the number of clients that can appear, disappear, or be duplicated. In a normal app estate, that may be manageable. In an MCP estate, it can create identity sprawl, weak ownership, and a review burden that grows faster than the security team’s ability to track it. NHI Management Group’s Top 10 NHI Issues and the NIST Cybersecurity Framework 2.0 both point to the same operational reality: unmanaged non-human identities become a control gap long before they become a policy exception. The risk is not theoretical. The 2024 ESG Report: Managing Non-Human Identities found that 72% of organisations have experienced or suspect a breach of non-human identities, which is a strong signal that governance failures are already common, not edge cases.

For security teams, the issue is not whether client registration is allowed, but whether each registered client has a clear owner, purpose, expiry, and revocation path. Without those controls, MCP can turn convenience into a standing inventory problem that no one can confidently attest to during review or incident response. In practice, many security teams encounter the problem only after hundreds of short-lived clients have already been created, rather than through intentional lifecycle design.

How It Works in Practice

In MCP environments, Dynamic Client Registration can be used to onboard tools, assistants, or automated workflows without pre-provisioning each client by hand. That is useful, but it also means the number of identities is no longer bounded by a traditional application catalogue. Each new registration may introduce a new client ID, secret, redirect URI, scope set, and expiry date, which all become governance objects that must be tracked.

Practitioners usually reduce the risk by treating registration as a controlled lifecycle event instead of a convenience feature. That means requiring explicit approval for new client classes, limiting self-service registration to tightly scoped use cases, and enforcing short-lived credentials with automatic expiration. Best practice is evolving, but most guidance aligns on a few practical controls:

• Assign a named business owner to every client registration.
• Use policy checks at registration time for allowed scopes, callback patterns, and tenant boundaries.
• Prefer short-lived secrets and rotate or revoke them on task completion.
• Continuously inventory active clients and reconcile them against expected workloads.
• Log registration, token issuance, and scope changes for audit and incident response.

For agentic and tool-heavy environments, the better control model is closer to workload identity than app identity. The OWASP Agentic AI Top 10 and the OWASP Agentic Applications Top 10 both reinforce the need to govern runtime behaviour, not just initial onboarding. That is why many teams pair DCR with stronger runtime policy, such as approval gates, constrained scopes, and revocation triggers when a client is no longer needed. These controls tend to break down when self-service agents can generate clients faster than inventory, approval, and revocation processes can keep up.

Common Variations and Edge Cases

Tighter registration control often increases operational overhead, requiring organisations to balance developer agility against auditability and blast-radius reduction. That tradeoff is real, especially for platform teams supporting many internal tools or ephemeral automation jobs. Current guidance suggests there is no universal standard for how much registration should be automated, so the right answer depends on trust boundary, data sensitivity, and how quickly a client can act once created.

Some environments can tolerate broader registration if scopes are narrow and tokens are short-lived. Others, especially those handling regulated data or high-value operational systems, should treat every new client as a governed asset with mandatory review. This is where Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs becomes relevant: lifecycle discipline matters more than the registration mechanism itself. For audit-heavy programmes, Ultimate Guide to NHIs — Regulatory and Audit Perspectives helps frame why ownership, evidence, and deprovisioning must be provable, not assumed.

Another edge case appears when clients are duplicated across environments, tenants, or CI/CD pipelines. That can be acceptable if the identities are intentionally isolated, but it becomes a governance problem when no one can say which registration is authoritative. In those cases, the control objective is not fewer registrations at any cost, but fewer unmanaged registrations with clearer expiry and accountability.

Related resources from NHI Mgmt Group

• How should security teams handle Dynamic Client Registration in remote MCP deployments?
• Should organisations keep dynamic client registration enabled for older MCP clients?
• Why do MCP environments create new identity governance problems at scale?
• Why does manual evidence collection create governance risk in IAM programmes?