Hardening MCP dynamic client registration for remote AI agents

At a glance

What this is: This is a security guide on hardening Dynamic Client Registration in remote MCP deployments, with the core finding that scalable registration can create a broad trust and verification gap.

Why it matters: For IAM and NHI practitioners, the issue is that autonomous clients need machine-speed onboarding without giving unknown agents standing trust or overly broad tool permissions.

👉 Read Descope's guide to hardening Dynamic Client Registration in MCP servers

Context

Remote Model Context Protocol deployments change the identity problem from a small set of known integrations to a large, dynamic pool of clients that may register at runtime. That is an NHI governance problem as much as an OAuth problem, because every AI agent or tool client becomes a non-human identity that needs to be verified, scoped, audited, and revoked with more precision than classic application access.

The article focuses on Dynamic Client Registration because it is often the only practical way to scale remote MCP, but that same openness weakens the assumptions behind enterprise RBAC and conventional registration workflows. The governance question is no longer whether clients can connect, but whether the organisation can prove who registered, what they received, and how quickly it can contain misuse. That starting position is typical for teams moving MCP beyond localhost.

For background on the agent-side risk model, see the OWASP Agentic AI Top 10 and the OWASP NHI Top 10. Those frameworks help place MCP registration risk in the broader category of tool misuse, identity abuse, and privilege escalation across autonomous systems.

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: What is the difference between application RBAC and function-level permissions for MCP?

A: Application RBAC grants access to an entire system, dataset, or service, while function-level permissions control individual tool actions inside that system. MCP needs the finer model because one client may be allowed to read records but not modify or delete them. Coarse roles usually over-grant when tools have mixed risk levels.

Q: When does ephemeral access reduce MCP risk, and when does it fall short?

A: Ephemeral access helps when the main concern is limiting blast radius after a client is already trusted. It falls short when the core problem is proving the client should be trusted in the first place. Short sessions contain damage, but they do not replace identity proof, scope validation, or auditability.

Q: Why do remote MCP servers create more identity governance risk than local ones?

A: Remote MCP servers expand the potential client population from a small local set to any client that can reach the network endpoint. That wider exposure increases the chance of malicious registration, impersonation, and scale abuse. The governance burden shifts from simple reachability control to continuous verification and lifecycle management.

Technical breakdown

Why Dynamic Client Registration creates a trust problem in remote MCP

Dynamic Client Registration lets a client register itself at runtime instead of being pre-registered through an admin workflow. In remote MCP, that matters because the server may be exposed on the internet and can no longer assume a small, known client population. The security issue is not registration itself, but the lack of prior trust signals. If the registration endpoint accepts anyone, then identity proof, scope validation, and callback review must happen after the fact or be enforced inline. That shifts the burden onto policy, telemetry, and revocation rather than perimeter assumptions.

Practical implication: Treat DCR as an identity control point and require policy checks before registration completes.

Function-level permissions vs traditional RBAC

MCP tool access is narrower than the application-level permissions most enterprises model today. A single server may expose multiple tools with very different outcomes, such as read, modify, and delete actions, so endpoint-level roles are too coarse. Traditional RBAC often grants access to an application or dataset, while MCP needs control at the function level. That mismatch can lead to overprivileged agents even when the registration flow itself is legitimate. The architectural problem is not only authentication, but mapping tool invocation rights to the minimum usable scope.

Practical implication: Break tool permissions into explicit scopes and review them separately from application access roles.

Why auditability and session lifetime matter in MCP auth

Dynamic registrations create a moving identity population, so audit quality becomes a core control rather than a compliance afterthought. Security teams need to track verified versus unverified clients, consent grants, unusual registration bursts, and later tool use. Short-lived sessions reduce the impact of compromised credentials, especially when the client is newly registered or not yet trusted. This is where lifecycle discipline matters: identity creation, trust elevation, and revocation must all be observable. Without that, MCP security becomes a volume problem that outpaces manual review.

Practical implication: Use short-lived sessions, revocation hooks, and audit events that tie registrations to later tool activity.

Threat narrative

Attacker objective: The attacker wants a trusted-looking MCP client identity that can execute tools or commands without triggering immediate suspicion.

1. Entry occurs when an attacker reaches an internet-exposed DCR endpoint and registers as a client without prior vetting.
2. Escalation follows when the registered client receives scopes broad enough to invoke sensitive MCP tools or act under a trusted name.
3. Impact comes from the malicious client using legitimate-looking access to issue harmful commands or manipulate protected resources at scale.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

Open DCR turns MCP registration into an NHI trust problem, not just an OAuth setting. When any remote client can register, the organisation is effectively accepting unknown non-human identities into its control plane. That makes identity proof, policy enforcement, and revocation part of the initial design, not add-ons after deployment. Practitioners should assume registration itself is a security boundary.

Function-level authorisation is the real governance gap in MCP. Most enterprise access models were built for applications, datasets, or roles, not for discrete tool actions that can produce destructive outcomes. When a server exposes read, modify, and delete operations through the same identity path, coarse RBAC can over-grant by default. Practitioners need permission models that match the tool, not the server.

Ephemeral access is necessary, but it does not solve trust establishment. Short-lived sessions reduce blast radius, yet they still depend on an earlier decision about whether the client should be trusted at all. That is the core reason dynamic registration must be paired with layered verification, source controls, and revocation. Practitioners should treat session length as containment, not as authentication.

Trust-by-domain and trust-by-policy will increasingly shape agent onboarding. The discussion around metadata-based registration shows where the market is heading: away from anonymous runtime sign-up and toward verifiable client identity signals. That direction aligns with broader NHI governance patterns, where discovery, verification, and lifecycle management matter as much as the initial credential exchange. Practitioners should expect more pressure to prove client provenance before permission is granted.

New MCP deployments are creating identity sprawl faster than teams can classify it. Each registered client, agent, and tool-facing integration becomes part of the non-human identity estate, and unmanaged growth quickly turns into access ambiguity. The problem is not only scale, but lack of a consistent lifecycle for creation, review, and removal. Practitioners should plan for NHI inventory control before remote MCP reaches production scale.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 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, according to the same report.
• The governance pattern also aligns with OWASP Agentic Applications Top 10, which is useful when teams need to translate tool access risk into concrete control choices.

What this signals

Identity blast radius: remote MCP forces teams to think about how far a newly registered client can reach before trust is fully established. That means registration policy, tool scoping, and revocation speed are now part of the same control story. For programme owners, the practical shift is to measure how quickly an unknown client can be contained after onboarding.

With 98% of companies planning to deploy even more AI agents in the next 12 months, per our research, the number of machine identities entering the environment will keep rising faster than manual governance can keep up. Teams should prepare for policy automation, better inventory hygiene, and stronger audit linkage between registration and tool use.

The operating model should converge on least privilege, source restriction, and session minimisation, not on trust by default. That approach maps cleanly to the NIST AI Risk Management Framework because the central question is accountability for autonomous action. For practitioners, the near-term goal is to make registration decisions observable and reversible.

For practitioners

• Gate remote registration with layered verification Require client metadata checks, redirect URI validation, and policy review before a new DCR client receives usable access. Separate public and confidential client workflows so the highest-risk registrations face the strictest review.
• Map MCP tools to function-level scopes Define explicit permissions for each MCP tool and avoid reusing broad application roles for read, write, and delete actions. Review whether existing RBAC can express the needed granularity or whether a policy layer is required.
• Restrict the source of registration traffic Use IP reputation, geographic constraints, allowlists, and rate limiting to reduce anonymous internet-wide registration attempts. For enterprise use cases, confine registration to known networks or VPN paths where feasible.
• Shorten trust windows for newly registered clients Issue short-lived sessions, avoid refresh tokens for unverified clients, and require re-authentication at regular intervals. Pair that with immediate revocation so suspicious clients can be cut off without waiting for token expiry.
• Instrument registrations for audit and anomaly detection Log registration events, consent grants, and tool calls in a way that ties each client to later behaviour. Look for bursts of registrations, repeated scope requests, and suspicious name reuse across clients.

Key takeaways

• Remote MCP turns client registration into a governance decision about non-human identity trust, not a mere implementation detail.
• Coarse application roles are too broad for tool-level MCP permissions, which increases the risk of overprivileged AI clients.
• Short-lived sessions, source controls, and immediate revocation are containment measures, but they only work when paired with strong identity verification.

Key terms

• Dynamic Client Registration: Dynamic Client Registration is an OAuth pattern that lets a client register itself at runtime instead of being manually pre-approved. In remote MCP, it solves scale problems but also creates a trust problem, because the server must decide how much confidence to place in an unknown client before granting access.
• Function-Level Permissions: Function-level permissions restrict access to individual tool actions rather than an entire application or dataset. For MCP, this is the difference between allowing a client to read a resource and allowing it to delete or modify that same resource, which is where most of the governance risk emerges.
• Identity Blast Radius: Identity blast radius is the amount of damage a newly trusted non-human identity can cause before it is contained or revoked. In MCP environments, the blast radius depends on how quickly the organisation verifies the client, limits its scopes, and detects unusual tool use after registration.

Deepen your knowledge

MCP dynamic client registration and function-level permissioning are core topics in the NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building remote agent onboarding and governance controls from a similar starting point, it is worth exploring.

This post draws on content published by Descope: Tips to harden OAuth Dynamic Client Registration in MCP servers. Read the original.