Dynamic registration breaks the assumption that the authorization server only interacts with trusted clients. In production, it creates a public onboarding surface that can be abused for registration floods, SSRF, and client impersonation. The safest response is to treat DCR as a legacy compatibility path, not the default trust model for MCP.
Why This Matters for Security Teams
dynamic client registration changes MCP from a controlled onboarding model into a runtime trust decision, and that is where production risk begins. If a server accepts registration without strong pre-approval, it becomes possible for unknown clients to appear, claim capability, and immediately request tool access. That is a poor fit for environments that expect predictable inventory, enforced ownership, and auditability.
This problem is not theoretical. NHIMG’s The State of MCP Server Security 2025 notes that only 18% of MCP server deployments implement any form of access scoping for tool permissions, which means onboarding gaps quickly become privilege gaps. The issue also aligns with the risks called out in the OWASP Agentic AI Top 10, where runtime trust and tool misuse are recurring failure modes.
Security teams often assume registration is just an administrative convenience, but in production it becomes part of the attack surface. In practice, many teams encounter registration abuse only after a flood of unexpected clients, not through intentional governance design.
How It Works in Practice
Dynamic registration lets a client self-register with an authorization server or MCP ecosystem at runtime, often by presenting metadata, redirect URIs, or client capabilities on demand. That is acceptable in low-risk development settings, but production changes the threat model. The server must now decide whether the registering entity is legitimate before it has any durable trust anchor, which is exactly where attackers look for weak defaults.
Safe production patterns usually separate discovery from authorization. A common approach is to keep registration pre-approved and use DCR only for tightly controlled onboarding paths, such as internal automation, vetted integrations, or migration compatibility. For all other cases, the better model is static client inventory with per-client policy, scoped secrets, and explicit approval workflows. Guidance from OWASP Top 10 for Agentic Applications 2026 reinforces that autonomous tool access should be bounded by least privilege and runtime checks, not by trust in a registration event.
- Require human or system approval before a new client receives production scopes.
- Bind client identity to workload identity, not just a self-declared name or redirect URI.
- Use short-lived credentials and revoke them automatically when onboarding is incomplete or unused.
- Log registration attempts separately from token issuance so abuse is visible.
- Apply allowlists for callback endpoints and metadata fields to reduce impersonation and SSRF risk.
NHIMG’s AI Agents: The New Attack Surface report shows how quickly agent governance breaks down once access is broad and visibility is uneven. These controls tend to break down when dynamic registration is exposed to the public internet because the server must defend both onboarding and authorization before it can establish trust.
Common Variations and Edge Cases
Tighter registration control often increases integration overhead, requiring organisations to balance onboarding speed against abuse resistance. That tradeoff is real, especially for partner ecosystems, sandbox-to-production promotions, and legacy clients that were built around self-service registration.
Best practice is evolving, but current guidance suggests treating DCR as a compatibility path rather than a default production trust model. For internal labs, ephemeral test tenants, or developer sandboxes, self-registration may be acceptable if registration is isolated, rate-limited, and never shares credentials or scopes with production. For regulated systems, the safer path is to separate a public discovery endpoint from a private approval plane, then issue production credentials only after policy checks, ownership verification, and scope negotiation.
Edge cases often appear in multi-tenant MCP deployments, where one tenant’s registration workflow can become another tenant’s attack vector if metadata is reused or callback validation is weak. The same concern applies when agents or automation pipelines can create clients on their own behalf, because autonomous systems can amplify registration abuse much faster than human operators. NHIMG’s Analysis of Claude Code Security is useful here because it highlights how tool-using AI systems can expand trust boundaries in ways that are easy to miss during initial design.
There is no universal standard for this yet, but the practical rule is simple: if a registering client can affect production tools, the registration flow itself must be treated as a high-value control point, not a convenience feature.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Covers unsafe tool access and trust boundaries in agentic runtimes. |
| CSA MAESTRO | TR-2 | Addresses runtime trust decisions for autonomous systems and their tool access. |
| NIST AI RMF | MAP | Supports mapping AI system risks, including exposed onboarding surfaces and misuse. |
Separate onboarding, authorization, and execution so self-registration cannot grant immediate production reach.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
