Only as a tightly controlled exception. If older clients require DCR, isolate them, log all registrations, and limit where they can operate. New deployments should move to protected resource metadata or CIMD so the default architecture no longer depends on a public registration endpoint.
Why This Matters for Security Teams
dynamic client registration (DCR) was designed to reduce onboarding friction, but older MCP clients turn that convenience into an exposure point. When a public registration endpoint remains available, the organisation inherits a live trust boundary that can be abused for rogue client creation, token abuse, or uncontrolled tool access. That risk is especially relevant in agentic environments, where a compromised client can become a launch point for broader workflow and data access.
Current guidance increasingly treats public registration as an exception, not a default. The control problem is not just authentication, it is proving which client should exist, what it can register, and where it can operate. That is why modern guidance in the OWASP Agentic AI Top 10 and NHIMG’s OWASP Agentic Applications Top 10 both emphasise tighter governance around autonomous clients and their privileges.
SailPoint’s AI Agents: The New Attack Surface report notes that 80% of organisations report AI agents have already performed actions beyond intended scope, including revealing access credentials. In practice, many security teams discover DCR misuse only after an older client has already registered, been trusted, and started operating outside the intended boundary.
How It Works in Practice
For older MCP clients, DCR should be treated as a compatibility bridge, not a standing capability. The safest pattern is to keep it enabled only for a narrow allowlist of legacy clients, isolate the registration surface, and require logging strong enough to reconstruct who registered what, when, and from where. Where possible, the registration endpoint should be separate from the production MCP runtime so it can be monitored and throttled independently.
Operationally, that means pairing DCR with explicit client allowlisting, transport-level restrictions, short-lived credentials, and post-registration review. If a legacy client must register dynamically, the registration record should be tied to a known workload identity and a scoped policy that limits tool invocation, data access, and tenant reach. The practical goal is to prevent an old client from becoming a general-purpose trust anchor.
- Use DCR only for named legacy clients that cannot yet use protected resource metadata or CIMD.
- Require full audit logging for registration requests, metadata changes, and subsequent token issuance.
- Constrain registered clients to minimal scopes and short TTLs.
- Segment registration paths from general MCP traffic and admin interfaces.
- Review all DCR registrations on a fixed schedule and revoke unused clients quickly.
This aligns with the reality highlighted in Astrix Security’s The State of MCP Server Security 2025, where only 18% of MCP deployments implement any form of access scoping for tool permissions. The external standard view is consistent: the OWASP Agentic AI Top 10 pushes for runtime controls rather than trust-by-registration, and the issue becomes hardest to manage when older clients can self-register across shared environments with inconsistent policy enforcement.
Common Variations and Edge Cases
Tighter DCR controls often increase operational overhead, requiring organisations to balance legacy compatibility against registration risk. That tradeoff is real in mixed environments where old MCP clients cannot yet support protected resource metadata, CIMD, or stronger workload identity patterns. In those cases, best practice is evolving rather than settled, and the organisation should document DCR as a temporary exception with a retirement date.
One common edge case is a partner or vendor client that still depends on DCR but must operate across multiple tenants. In that scenario, the registration policy should be tenant-specific, not global, and the organisation should avoid reusing the same client definition across broad scopes. Another edge case is development and test environments, where teams often leave DCR open “for convenience” and later copy the same configuration into production.
Where autonomous agents are involved, the risk compounds because registration may only be the first step in a longer chain of tool use and data movement. The safer stance is to treat DCR as a legacy compatibility control, not as a preferred architecture. New deployments should move toward explicit, constrained onboarding models and rely on runtime policy checks instead of a public registration endpoint.
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 | LLM-04 | Covers insecure client onboarding and unsafe agent trust boundaries. |
| CSA MAESTRO | M2 | Addresses governance for agent onboarding, identity, and tool access. |
| NIST AI RMF | Supports risk-managed governance for autonomous systems and changing access context. |
Use AI RMF to classify DCR as a bounded risk and track compensating controls until removal.
Related resources from NHI Mgmt Group
- When should organisations block or constrain dynamic client registration?
- How should security teams handle Dynamic Client Registration in remote MCP deployments?
- Should organisations treat MCP server collaboration as a Zero Trust problem?
- When should organisations prioritise Zero Standing Privilege for non-human identities?
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
