TL;DR: MCP deployments push OAuth Dynamic Client Registration back into focus because manual client setup does not scale for AI agents and non-technical users, according to Tailscale. The core issue is not registration alone but who is allowed to create clients, because that governance decision defines the real security boundary for MCP access.
At a glance
What this is: This is an analysis of Dynamic Client Registration for MCP and AI agent access, with the key finding that scalable registration only works when client creation itself is tightly governed.
Why it matters: IAM and NHI teams need to treat client registration as an access control decision, because MCP adoption shifts the security boundary from manual setup to who can issue and manage OAuth clients.
Context
Dynamic Client Registration is an OAuth pattern that lets a client register with an authorization server through an API instead of manual portal-based setup. In MCP environments, that matters because the protocol assumes more automated onboarding than traditional application integrations, especially when AI agents or non-technical users need access.
The governance problem is not registration alone. Once client creation becomes programmable, teams must define which users, groups, gateways, or intermediary services are allowed to create OAuth clients, and that decision becomes part of the identity boundary for MCP access.
Key questions
Q: What breaks when MCP client registration is left open to anyone?
A: Open registration turns OAuth client creation into an unaudited trust decision. In an MCP environment, that can produce shadow clients, unclear ownership, and access paths that look legitimate even when they were never approved for the server or gateway they reach.
Q: Why does Dynamic Client Registration create governance problems for MCP?
A: 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.
Q: How should teams govern intermediary gateways in MCP deployments?
A: Treat the gateway as a separate trusted actor with its own permissions and accountability. Do not assume that direct server ACLs cover delegated access, because the gateway may need to represent users or agents through token exchange and therefore deserves its own policy boundary.
Q: Should organisations use direct ACLs or OAuth registration for internal MCP servers?
A: Use the simpler pattern only when the deployment is small, direct, and easy to govern. Once gateways, multiple users, or agent intermediaries enter the design, OAuth registration with explicit control over who can create clients becomes the safer operating model.
Technical breakdown
Why DCR matters for MCP onboarding
OAuth Dynamic Client Registration replaces manual app registration with an API-driven process that can create clients on demand. That matters for MCP because the protocol is designed for machine-friendly, repeatable setup, and manual click-ops break down quickly when many users, servers, or agents need access. DCR does not remove authorization, however. It only changes how a client is created and handed credentials, so the security model still depends on strong rules around who can register, where registration happens, and what the resulting client is allowed to do.
Practical implication: Treat registration as a governed control point, not an onboarding convenience.
Why client issuance becomes the security boundary
When an authorization server supports DCR, the sensitive step is no longer just login or token use. The sensitive step is client issuance, because each registration creates a new OAuth identity with its own trust relationship. In MCP deployments, that trust relationship can be exercised by a human, a service, an internal gateway, or an AI agent. If registration is open or loosely controlled, the environment can accumulate unaudited clients that are hard to distinguish from legitimate integrations.
Practical implication: Restrict who can create clients and inventory every registered MCP-facing client.
Where intermediary gateways change the trust model
The article highlights MCP gateways and intermediary agents as a harder pattern than direct server access. In that model, the user, the gateway, and the backend do not share the same identity path, so simple direct-access ACLs stop being sufficient. Token exchange becomes relevant because the intermediary needs a way to act without copying the user’s full trust context into every backend interaction. That introduces a layered delegation chain, which is a different governance problem from direct client registration.
Practical implication: Map delegated access paths separately from direct MCP server access.
Threat narrative
Attacker objective: Obtain a registered OAuth client that can reach MCP resources through an apparently legitimate access path.
- Entry occurs when an MCP client or intermediary is registered through a dynamic process rather than a controlled manual review path.
- Escalation occurs if unauthorized users or broad groups can create OAuth clients that inherit access into internal MCP services or gateways.
- Impact follows when loosely governed clients become trusted integration points for agents or backends that were never meant to be broadly reachable.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Dynamic client registration shifts the control boundary from app onboarding to identity issuance. The article is not really about making setup easier. It is about the fact that every new OAuth client is a new trust decision, and MCP makes that decision more frequent and more operationally visible. The practitioner implication is that registration policy now belongs in identity governance, not in a developer convenience workflow.
MCP exposes a governance gap that traditional OAuth deployments could ignore. In low-volume integrations, manual client creation hid the control problem inside administrator workflows. MCP changes the scale and cadence, so teams must now govern who may create clients, under what identity, and for which internal scope. That makes client issuance a first-class security object.
Intermediary gateways turn simple access control into delegated trust management. Direct ACLs can work for small internal deployments, but the gateway pattern introduces a separate actor that can mediate requests and exchange tokens. That means the real question is not only whether a user may reach an MCP server, but whether the intermediary is allowed to represent that user safely. The implication is that delegation chains need explicit governance, not implied trust.
MCP access control is becoming a workload identity problem as much as an OAuth problem. Once AI agents, gateways, and servers all participate in the path, the organization is governing machine-to-machine trust, not just user sign-in. That requires treating registered clients as managed non-human identities with scope, ownership, and lifecycle, especially when the deployment is internal and the temptation is to relax controls.
Secure DCR is a policy problem, not a protocol problem. The protocol can register clients, but it cannot decide which users or groups deserve that capability. That assumption belongs to the enterprise control plane. Practitioners should therefore align DCR with access policy, client inventory, and revocation discipline before scaling MCP adoption.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
- Read next: AI Agent Authorisation Guide
What this signals
Client issuance is the new control point for MCP: once registration is programmable, access governance has to move upstream from token use to client creation. Teams should expect MCP onboarding to expose policy gaps that were invisible in manual app-registration workflows.
MCP deployments also make delegation harder to ignore because gateways and intermediary agents create a separate trust path from the original user. That means inventory, ownership, and revocation must follow the registered client, not just the person who requested access.
For practitioners
- Define who may register MCP clients Limit DCR to named users, groups, or trusted gateways, and require explicit approval for any client that can reach internal MCP services.
- Inventory every dynamic client Track each registered OAuth client as a governed identity with owner, scope, and purpose so that stale or shadow registrations can be removed.
- Separate direct access from delegated access Document when an MCP server can be reached directly and when an intermediary gateway must represent the user, then apply distinct controls to each path.
- Review token exchange requirements Where gateways or intermediary agents sit in front of MCP backends, define how STS token exchange preserves least privilege without copying user trust too broadly.
Key takeaways
- MCP access risk is shifting from manual setup friction to governance over who can create OAuth clients and where those clients can be used.
- Dynamic registration only remains safe when registered clients are treated as managed identities with explicit ownership, scope, and revocation.
- Gateway-based MCP architectures add a delegation layer that needs its own access policy, not just inherited trust from the user or backend.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | DCR changes how MCP clients authenticate and obtain trust. |
| NHI-05 — Overprivileged NHI | Registered clients can quietly accumulate scope beyond their intended MCP use. | |
| Recommendation — Apply NHI-04 controls to restrict which clients can be issued and authenticated into MCP services. Constrain each registered MCP client to the minimum access scope required for its task. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OAuth client credentials and registration lifecycle need governed management. |
| AC-6 — Least Privilege | The article centers on limiting which identities may register clients and reach MCP services. | |
| Recommendation — Use IA-5 to control issuance, storage, rotation, and revocation of MCP client authenticators. Enforce AC-6 so only approved identities can create or use MCP-facing clients. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core issue is who is authorised to create and use dynamic clients. |
| Recommendation — Review MCP registration permissions as entitlements and remove broad client-creation rights. | ||
| NIST Zero Trust (SP 800-207) | Policy Enforcement Point — Policy Enforcement Point | The article relies on policy to gate client registration and delegated access paths. |
| Recommendation — Place DCR and gateway access behind a policy enforcement point with explicit authorization rules. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Client registration is an API function that must be restricted to authorised users or groups. |
| Recommendation — Lock down registration endpoints so only entitled identities can invoke client-creation functions. | ||
Key terms
- Dynamic Client Registration: Dynamic client registration is a protocol pattern that allows a software client to register itself with an authorization system automatically. For AI agents, it can reduce manual setup, but it also creates new identities at speed, which makes ownership, policy checks, and revocation essential.
- Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.
- Access Issuance: Access issuance is the process that creates credentials, tokens, or short-lived privileges for a subject at the moment they are needed. For machine and autonomous actors, this is where trust should be evaluated because the decision to mint access can be abused even when the resulting credential expires quickly.
- Intermediary Gateway: A service that sits between a user or agent and an MCP backend, translating or brokering requests. It changes the trust model because access is no longer direct, so governance must cover both the gateway and the resources it represents.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org