Table of Contents
When a Model Context Protocol (MCP) client needs to connect to a remote MCP server, it faces a fundamental security challenge: How does it get authorized to access protected resources? Unlike local MCP servers (which communicate through Standard Input / Output or stdio), remote servers exposed over HTTP need protection—and, according to the MCP authorization specification, that means using OAuth.
Traditionally, OAuth offers two paths: manual pre-registration and Dynamic Client Registration (DCR). Manual pre-registration works fine for a handful of known clients: developers register through a portal, receive credentials, and configure their applications accordingly. But MCP’s promise is enabling countless AI agents to connect with unlimited servers, so this is a clear limitation. DCR, on the other hand, allows clients to register themselves automatically at runtime, receiving credentials on the fly. But while DCR’s openness makes it impressively scalable, this also exposes security gaps and makes it vulnerable to attack.
Today, the challenge isn’t whether or not to use DCR; in production MCP at scale, it’s the only viable option available. Instead, the question is how to harden it against potential threats. Read on to learn how.
DCR challenges in MCP deployment
Your security considerations for DCR change dramatically based on where exactly your MCP server runs. Local MCP servers have several natural advantages, like the fact that only clients sharing the same network can even see them. But while the threats are fewer, local deployment significantly limits MCP’s potential because you can’t connect with external partners, customers, or third-party services. Conversely, internet-exposed servers face a global attack surface where any client worldwide can potentially register.
If you’ve previously relied on local deployment for its inherent security benefits, transitioning to remote can be daunting. Here, DCR becomes essential for scaling, but it introduces numerous security challenges. Once your MCP server is exposed online, every malicious actor and automated scanner can discover and target your registration endpoints. This underscores the core dilemma with DCR: You need remote servers to unlock MCP’s full potential, but remote servers with default DCR configurations are woefully underprepared for the modern threat landscape.
Confusion at scale
Using DCR on a remote MCP server, you’re effectively letting anyone in the world register as a client with your OAuth provider. There are no guardrails in place to protect this interaction. There’s a fundamental trust paradox at the root of this: Servers must accept registration requests from clients they’ve never seen before. Unlike typical OAuth scenarios where there’s often some pre-existing relationship, MCP’s value depends on discovering and connecting to new services.
This “stranger danger” situation means anyone who can reach your DCR endpoint can register as an OAuth client, including malicious actors. Without proper safeguards, attackers could register millions of clients or malicious applications with the same name as legitimate ones. Even if a threat actor doesn’t find any data worth exfiltrating on your system, they could still fire off harmful commands.
Permissions complexity
Traditional API security operates with endpoint-level granularity. This means users either have access to (for example) /api/users, or they don’t. MCP requires function-level permissions since individual tools within a server may need different authorization scopes. A database MCP server might expose tools for “read customer data,” “modify records,” and “delete tables.” Each of these requires distinct authorization even though they access the same underlying API.
Most enterprises haven’t designed permissions at this specific level. Your existing RBAC (Role-Based Access Control) policies grant access to entire applications or datasets, not individual AI tool capabilities. This mismatch creates a gap where AI agents might receive excessively broad permissions because fine-grained controls don’t exist, allowing even non-malicious actors to perform damaging actions (like deleting an entire production codebase).
Audit and visibility gaps
When agents register dynamically at scale, understanding who’s accessing what becomes your first line of defense against potential threats. MCP events are novel and don’t integrate easily with existing SIEM systems. Organizations need to distinguish between verified and unverified agents, track consent grants, and identify anomalous registration patterns, all while operating at machine speed and scale.
While traditional OAuth scenarios are well-defined when it comes to audit trails, MCP (and DCR within the context of MCP) are still relatively new and present unique visibility challenges. Anyone can see when an IP range is firing off registration requests at a suspicious rate. But what if a calculating threat actor slowly and meticulously registers hundreds of puppet clients from behind known proxies? Manual review is unlikely to clue you in.
Emerging standards for client trust
DCR challenges can be addressed by understanding as much about the MCP client as possible. This means it’s particularly important to know whether the information you’re getting about the client is trustworthy. The MCP community is actively driving toward solutions that resolve this trust problem, and one such development is SEP-991.
While this pull request (PR) is currently under review in the MCP specification, it proposes adopting OAuth Client ID Metadata Documents as additional client registration mechanisms. This approach would allow OAuth clients to use HTTPS URLs as client identifiers, where the URL points to a JSON document containing client metadata. SEP-991 specifically addresses the common MCP scenario where servers and clients have no pre-existing relationship (the most typical application of DCR). Instead of requiring manual coordination, complex verification workflows, or a totally unsecured DCR implementation, Client ID Metadata Documents enable servers to trust clients based on verified metadata while maintaining full control over access policies.
Under this proposal, a client could register using (for example) https://example-ai-company.com/client-metadata.json as its identifier. The server would fetch this document to verify the client’s claims about its name, redirect URIs, and intended scopes. Because the metadata is hosted at the client’s domain, it provides cryptographic proof of the client’s identity and intentions.
While SEP-991 promises to improve trust mechanisms for MCP deployment, it’s not an official part of the specification at the time of writing. Organizations will need immediate, practical solutions now to harden their DCR implementations.
It’s also worth noting that if MCP clients or agents are locally hosted or coming from unverified domains, then SEP-991 won’t be sufficient since you can't verify the authenticity of the hosted metadata that identifies the client. There have been proposals to solve this by adopting software statements as part of OAuth RFC 7951, but discussions are ongoing without clear resolution at the time of writing.
Tips to harden your DCR implementation
Fortunately, hardening DCR against potential threats isn’t as difficult as it sounds. It involves a combination of several foundational security pillars:
Build a layered verification process
Create a programmatic process to evaluate client trustworthiness and determine appropriate access levels. Validate client metadata against your policies, checking that redirect URIs follow expected patterns and that requested scopes align with the client’s stated purpose. Implement different verification workflows for different types of clients; for example, public clients should have stricter validation than confidential clients. Consider requiring additional documentation or approval processes for clients requesting specific, sensitive scopes.
When SEP-991 becomes an official part of the MCP specification, leverage the new Client ID Metadata Documents to verify client claims against their own hosted metadata. That said, SEP-991 will be useful for backend-to-backend requests but will fall short of addressing security concerns if the request / client is a local application (since the callback URL can be faked in that case). One way to solve this challenge is to use device attestation to confirm the validity of the device / client.
Set limits based on source
Use IP reputation services like AbuseIPDB to automatically block registration attempts from known malicious sources (VPNs, proxies, etc.). Implement geographic restrictions if your use case allows, such as high-risk regions where you don’t expect legitimate clients. Institute different rate limits based on whether the client is verified or not.
For enterprise deployments, restrict DCR to known IP ranges, or require VPN access. Consider implementing allowlists for redirect URI domains, accepting only registrations from clients using approved callback URLs.
Implement risk-based controls
Use threat intelligence to proactively identify suspicious registration patterns. Flag rapid-fire registration attempts, unusual metadata combinations, or requests from mixed-reputation IP ranges for additional security review.
Deploy progressive restrictions: Clients that trigger multiple security flags face increasingly strict limitations. Implement CAPTCHA challenges for registration attempts that meet certain risk criteria.
Use short-lived sessions
Configure sessions to be short-lived for DCR-registered clients. Avoid issuing refresh tokens to public clients, and force re-authentication at regular intervals to limit the impact of compromised credentials.
Implement different session policies based on client verification status. Unverified clients face the most restrictive session management policy, while verified clients might receive slightly longer sessions. Build capabilities for immediate credential revocation when suspicious behavior is detected.
How Descope helps harden DCR deployment
The path to production-ready MCP deployment requires solutions that address DCR’s fundamental vulnerabilities without compromising the protocol’s core benefits. Organizations need comprehensive identity infrastructure that can bridge the gap between MCP’s technical potential and enterprise security requirements.
Descope’s Agentic Identity Control Plane provides end-to-end solutions for enterprise DCR and MCP adoption. Instead of building custom solutions, the Agentic Identity Control Plane enables organizations to implement all the hardening strategies we’ve discussed through integrated capabilities.
DCR support with built-in hardening: Descope supports RFC 7591-compliant DCR while enabling customers to implement verification workflows, IP reputation checks, and integrations with threat intelligence services. Organizations can configure different registration policies for verified versus unverified clients without needing custom development.
Granular access control: The Agentic Identity Control Plane provides function-level management that maps OAuth scopes to specific MCP tool permissions. Role-based scope assignment ensures that AI agents receive only the permissions appropriate for their bound users. JWT claim-based authorization enables dynamic permission decisions based on client context and verification status.
Comprehensive auditing and lifecycle management: All DCR registrations, consent grants, and tool usage generate detailed audit trails that integrate with existing SIEM systems. Organizations can track which agents were created via DCR, monitor their access patterns, and quickly identify anomalies. Additionally, organizations can leverage bulk management capabilities for handling large numbers of dynamic registrations and emergency revocation procedures for compromised agents.
DCR is essential for MCP scalability, but its openness demands thoughtful security steps. By implementing the proper controls, it’s possible to balance that openness with mature safety mechanisms that will ensure a productive remote MCP deployment.
Descope supports a wide range of AI use cases, from securing remote MCP servers to turning apps into OAuth providers for seamless AI agent connectivity. You can explore Descope’s AI-focused demos on this microsite, or jump directly into the Descope experience with a Free Forever account and by joining our developer community, AuthTown.
