Dynamic client registration for MCP and AI agent access

At a glance

What this is: This is an analysis of why OAuth Dynamic Client Registration matters for MCP and AI agent access, with the key finding that registration must be constrained by identity-aware policy.

Why it matters: It matters because IAM, NHI, and agentic AI teams need a practical way to govern who can create and use OAuth clients without turning every deployment into manual click-ops.

👉 Read Tailscale's analysis of secure dynamic client registration for MCP and AI agents

Context

MCP access becomes an identity governance problem as soon as client registration, authorization servers, and intermediary gateways are introduced. The primary challenge is not simply authenticating a caller, but deciding which users, groups, or delegated identities are allowed to create OAuth clients in the first place.

For internal MCP deployments, manual client setup creates friction for developers and an even bigger barrier for non-technical users. That friction pushes teams toward shortcuts, which is why dynamic client registration and policy-scoped access control have become central to MCP security discussions.

When MCP is used by AI agents, the governance model gets sharper, not simpler. The question becomes how to let agents or gateways participate in authorization flows without creating an open registration path that expands the attack surface beyond what IAM teams can actually oversee.

Key questions

Q: How should security teams handle Dynamic Client Registration in remote MCP deployments?

A: Security teams should treat Dynamic Client Registration as a high-risk identity workflow, not a convenience feature. Require layered verification, limit where registration can originate, bind permissions to specific tool functions, and make revocation immediate. The goal is to preserve scale without letting unknown clients inherit trust before they have earned it.

Q: Why do AI agents make OAuth client registration harder to govern?

A: AI agents can multiply the number of clients, gateways, and delegated access paths that need oversight. That turns registration into a lifecycle problem, because each client must be traceable, scoped, and revocable. Without that governance, automation creates trust sprawl faster than teams can review it.

Q: What breaks when MCP gateways sit between users and backend servers?

A: The original user context can disappear unless the delegation chain is preserved explicitly. Once a gateway intermediates access, the backend needs a way to know who initiated the action, what was delegated, and which scope was passed through. Without that, auditability and accountability weaken.

Q: How do organisations keep MCP access flexible without opening registration abuse?

A: Use policy to allow only approved users or groups to create clients, then separate that from broader server access decisions. Pair registration rules with expiration, revocation, and audit requirements so client creation remains a controlled identity lifecycle event rather than an ungoverned self-service path.

Technical breakdown

Why dynamic client registration changes MCP authorization

Dynamic Client Registration, or DCR, replaces manual app-by-app registration with an API-driven flow that lets a client obtain its own OAuth client identity. In MCP environments this matters because the client is often created per tool, per agent, or per deployment, not once for a stable enterprise application. DCR is therefore an identity lifecycle control as much as an authentication convenience. If registration is uncontrolled, the authorization server becomes a self-service trust factory. If it is policy-bound, it can support automation without surrendering governance over who can connect to what.

Practical implication: treat DCR as a governed onboarding path for OAuth clients, not a convenience feature.

Why identity-aware policy is the real control point

The article shows a pattern where the network or identity layer asserts who the requester is before allowing registration. That is the important design shift: DCR itself does not provide trust, the surrounding policy does. By binding registration to SSO-backed user or group identity, teams can limit client creation to approved populations such as engineering or internal operators. This is especially relevant for internal MCP servers, where the risk is often not public exposure but uncontrolled expansion of machine-to-machine access through easy registration.

Practical implication: gate client registration with identity and group-based policy, then log every registration event as a governance record.

Why intermediary MCP gateways need a different identity model

The article notes that simple direct identity checks break down once an intermediary gateway or agent sits between the user and backend MCP servers. That is a classic delegation problem: the backend no longer sees the original user directly, so the trust chain must survive the handoff. Token exchange becomes the likely control pattern because it preserves delegation context while avoiding full user re-authentication at every hop. For identity teams, the issue is not just access control but preserving auditability across the proxy boundary.

Practical implication: design gateway identity flows so delegated access remains traceable from original user to intermediary to backend.

Threat narrative

Attacker objective: The attacker objective is to create or abuse OAuth clients that gain broader MCP access than governance intended.

1. Entry occurs when an MCP client can register or obtain authorization without a constrained policy boundary, turning the registration endpoint into the first trust decision.
2. Escalation follows when an intermediary gateway, agent, or loosely governed registration flow expands access beyond the original user or intended tool scope.
3. Impact is unauthorized MCP access, expanded OAuth client sprawl, and weakened auditability across the agent-to-server delegation chain.

Breaches seen in the wild

• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

DCR is now an identity governance control, not just an OAuth feature. MCP has moved client registration from a rare administrative task into a repeatable access pattern for agents, gateways, and internal tools. That changes the governance question from "can we automate onboarding?" to "who is allowed to mint new trust relationships at runtime?" Practitioners should treat registration policy as part of the access model, not as an implementation detail.

Identity-aware registration is the only sane way to scale internal MCP. The article correctly points to SSO-backed user and group identity as the control boundary for DCR. That is the right place to anchor governance because the registration path must inherit enterprise accountability, not bypass it. For IAM teams, the practical conclusion is that MCP cannot be operated safely as an open self-service surface without a policy layer that binds client creation to named identities and approved roles.

Intermediary gateways expose an unaddressed delegation gap. Once an agent or gateway sits between the user and the MCP backend, existing authorization assumptions become fragile because the backend no longer sees a stable end-user context. This is where token exchange and delegated identity traceability become necessary. The implication is that current MCP access models are already more complex than the specs fully describe, so teams should expect audit and attribution gaps if they ignore the intermediary layer.

MCP access is converging with workload identity governance. The same lifecycle questions that apply to service accounts now apply to agent-facing OAuth clients: who created them, who can use them, when they expire, and how they are revoked. That makes DCR part of a broader NHI governance program rather than a standalone protocol choice. Practitioners should align MCP onboarding, client approval, and offboarding with existing NHI lifecycle controls.

Policy without delegation visibility will fail in agent-heavy environments. A registration rule can block obvious abuse, but it will not solve the harder problem of tracing access once an agent, proxy, or gateway begins making downstream requests. That is the governance gap this article surfaces most clearly. The field is heading toward identity models that must prove not just who registered a client, but how delegated access is preserved across hops.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That is why our OWASP Agentic Applications Top 10 is the right next resource for teams translating agent risk into control design.

What this signals

Dynamic client registration is becoming part of the agent governance stack. As MCP adoption grows, teams will need to decide whether client creation belongs with developers, platform teams, or identity governance. The organisations that separate registration policy from server access policy will be better positioned to keep agent onboarding fast without making every client a permanent trust artifact.

The next control frontier is delegation traceability across intermediaries. If a gateway or proxy is involved, security teams should assume the audit problem is no longer just authentication, but attribution across the full access path. That is where identity lifecycle controls, token exchange, and logging discipline will determine whether MCP remains governable at scale.

For practitioners

• Constrain client registration with identity policy Limit DCR access to specific SSO-backed groups, and require every registration request to map to an approved operator or team. Use the registration event as a governance checkpoint, not a background system action.
• Separate direct access from delegated access paths If an MCP server can be reached directly, keep that path simple. If a gateway or intermediary is involved, define a separate delegated identity flow so the backend can still attribute actions to the original requester.
• Add lifecycle controls for OAuth clients and agent gateways Track who created each client, what scope it has, and when it should be revoked. Apply joiner-mover-leaver thinking to machine-created trust relationships so stale clients do not persist after the need has passed.
• Log registration and token-exchange events together Correlate client creation, token exchange, and backend access in the same audit trail. That makes it possible to reconstruct delegation chains when an MCP gateway or AI agent is involved.

Key takeaways

• MCP client registration is now an identity governance decision because it controls who can create trust relationships at runtime.
• Identity-aware policy and delegated traceability are the two controls that determine whether MCP remains auditable once gateways and agents are added.
• AI agent growth makes uncontrolled registration riskier, so lifecycle thinking must extend to OAuth clients, not just human and service identities.

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.
• Delegated Identity: Delegated identity is when one actor acts on behalf of another with explicit permission and bounded authority. In AI-assisted commerce, it requires clear consent, limited scope, and traceable records so the retailer can distinguish authorised delegation from unauthorised automation.
• Token Exchange: Token exchange is an OAuth pattern that swaps one credential or token for another with narrower scope or different trust context. In NHI governance, it is useful when a workload must cross boundaries without carrying broad, reusable privileges into downstream systems.
• MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.

What's in the full article

Tailscale's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples for using DCR with a locally hosted OAuth authorization server and MCP clients.
• Practical ACL policy examples showing how to restrict registration to approved identities and groups.
• Identity-aware gateway patterns for cases where direct MCP access is not enough.
• Implementation discussion of STS token exchange for intermediary agents and proxies.

👉 Tailscale's full post covers the DCR flow, policy examples, and gateway identity model in more operational detail.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.