As AI agents move from chat interfaces into production systems, the security question is no longer limited to what a model can say. It is now also about what the agent can reach, what tools it can invoke, and which user-linked accounts sit behind those tool calls.
That shift is what makes the Model Context Protocol, or MCP, so security-relevant. MCP has become a common way for AI clients to connect to external tools, databases, SaaS platforms, cloud resources, and enterprise services. In local deployments, that connection may stay inside a user-controlled environment. In remote deployments, MCP becomes a network-exposed service boundary, often sitting between an AI agent and sensitive business systems.
A recent paper, “A First Measurement Study on Authentication Security in Real-World Remote MCP Servers,” examined this exact layer. The researchers identified 7,973 live remote MCP servers and found that 40.55% exposed tool interfaces with no authentication at all. Among authenticated servers, 2,428 used OAuth-based authorization and 2,312 relied on static tokens or API keys. The paper then tested 119 OAuth-enabled MCP servers and found at least one confirmed authentication flaw in every server evaluated, with 325 confirmed flaws in total. The researchers also obtained 9 CVE IDs through responsible disclosure.
MCP Has Moved From Local Tooling to Remote Authorization
MCP was introduced as an open standard for connecting LLM-based applications to external tools and data sources. Its architecture includes hosts, clients, and servers. The host is the user-facing AI application, the client handles communication inside that host, and the server exposes tools, resources, or prompts over a defined protocol. MCP supports local standard I/O deployments and network-accessible HTTP-based deployments.
That deployment difference matters. A local MCP server may run on the same system as the AI client, often under the same user context. A remote MCP server is closer to a conventional web service. It receives network traffic, exposes callable capabilities, and may connect into SaaS applications, ticketing systems, code repositories, CRM records, databases, cloud APIs, and other high-value resources.
The paper’s findings show that many deployments have not fully absorbed that change in threat model. The researchers found 3,233 live remote MCP servers with no authentication. In one anonymized case, an unauthenticated MCP server exposed CRM data containing more than 5,000 internal enterprise records, including names, email addresses, phone numbers, and physical addresses.
For defenders, the lesson is direct: an MCP endpoint is not just an AI feature. It is an access path. If it exposes tools that can query, modify, retrieve, or trigger business data, it needs the same level of authentication, authorization, logging, and exposure management applied to any externally reachable production API.
Why OAuth Becomes Riskier in Remote MCP
OAuth is meant to support delegated access. A user authorizes a client, an authorization server issues tokens, and a protected resource accepts those tokens. In remote MCP, this pattern becomes more complex.
The MCP client may be a desktop app, IDE, command-line tool, browser-based client, or cloud agent frontend. Many of these are public clients that cannot safely store a long-term secret. The MCP server may then act as a protected resource for the MCP client, and at the same time act as an OAuth client to another upstream service such as GitHub, Slack, Notion, or a database platform. This creates a multi-hop authorization chain with more places for state, identity, redirect handling, and token binding to break.
The current MCP authorization draft reflects this risk by treating a protected MCP server as an OAuth 2.1 resource server, requiring protected resource metadata, requiring access-token validation, and stating that clients must obtain a client ID through client ID metadata documents, pre-registration, or dynamic client registration. The draft also says dynamic client registration is deprecated and retained for backward compatibility in the draft version.
The paper shows why that matters in practice. Dynamic client registration, or DCR, is convenient for MCP, since the ecosystem contains many different clients and deployment models. RFC 7591 defines DCR as a way for clients to programmatically register metadata with an authorization server and receive a client identifier. Yet in MCP deployments, an overly permissive registration endpoint can become an attacker-controlled routing primitive.
If an authorization server accepts arbitrary callback destinations during registration, an attacker may register a malicious client, receive a legitimate client ID, and craft an authorization URL that sends the victim’s authorization code to attacker-controlled infrastructure. The paper found malicious DCR binding in 114 of the 119 tested servers, or 95.8%.
The Core Authentication Failures Identified in the Paper
The researchers organized the MCP OAuth findings into four categories: dynamic client registration flaws, delegated authorization flaws, open client environment flaws, and common OAuth misconfigurations. Across those categories, they identified nine concrete flaw types.
The first major category involved DCR. Malicious DCR binding occurs when a registration endpoint accepts attacker-supplied callback destinations without strong boundary checks. Blind client trust occurs when an authorization server accepts a supplied client ID without verifying that it was actually registered. Both flaws weaken the association between a client identity and its permitted callback destination.
The second category involved delegated authorization. Layer inconsistency occurs when the first MCP authorization layer enforces PKCE, but the upstream OAuth layer does not. Nested context pollution occurs when an MCP server places downstream routing context inside a client-visible state value, then accepts altered routing data without integrity protection or allowlist validation.
The third category involved open client environments. PKCE downgrade occurs when an authorization server accepts requests that omit the code challenge or accept the weaker plain method. PKCE exists to protect public clients from authorization-code interception attacks by binding the authorization request to a later token exchange through a verifier and challenge. RFC 7636 states that S256 or another cryptographically secure challenge method is required to mitigate stronger interception scenarios.
The fourth category involved traditional OAuth mistakes that become more damaging in the MCP setting. These include open redirect behavior, weak or predictable state values, and authorization code replay. On their own, these are known OAuth problems. In an MCP flow, they can combine with DCR, public-client assumptions, delegated service access, and agent tool execution.
PKCE Downgrade Is Especially Dangerous for Agent Tooling
PKCE is one of the main controls protecting OAuth flows for public clients. The client creates a verifier, sends a derived challenge during authorization, then presents the original verifier during token exchange. If an attacker steals the authorization code but lacks the verifier, the token exchange should fail.
That protection collapses when the authorization server accepts authorization requests with no challenge or accepts a downgrade to the plain method. In the paper’s tested dataset, 81 of 119 servers, or 68.1%, had confirmed PKCE downgrade flaws.
This is a high-impact finding for agent deployments. An attacker who can redirect an authorization code to an attacker-controlled endpoint may be blocked if PKCE is enforced correctly. If PKCE can be stripped or downgraded, the code itself may become enough to obtain a token. In an MCP environment, that token can represent access to agent tools, linked SaaS resources, project data, documents, tickets, repositories, or other connected systems.
The paper’s third case study showed this exact composition: an MCP server exposed both an open redirect and weak PKCE enforcement. The attacker removed the PKCE parameters, changed the callback destination, caused the victim to authorize the request, and exchanged the resulting authorization code for a token. The researchers reported the issue and obtained CVE-2025-69898.
Consent Pages Are Part of the Security Boundary
The paper also calls out consent-page bypass, which was confirmed in 72 of 119 tested servers. In these cases, the authorization flow failed to show the user enough information about the final callback destination.
This matters for MCP since many clients use localhost callbacks or custom URI schemes. A user may see a familiar MCP authorization screen and assume the flow is safe, even when the authorization result is being routed to a malicious local port or attacker-controlled callback path. If the interface hides the callback destination, the user has no clear way to spot that the approval flow has been altered.
Consent is not just a UX feature in this context. It is part of the authorization defense model. A secure flow should show the exact callback destination, warn on localhost-only callbacks, and make client identity clear enough that users are not approving a spoofed or attacker-registered client.
Delegated Authorization Creates Multi-Hop Failure Modes
Remote MCP servers often act as both a resource server and an OAuth client. The MCP client authenticates to the MCP server, then the MCP server authenticates to an upstream service. This pattern was present in 81 of the 119 tested OAuth-enabled servers. Among those delegated deployments, 40 used nested state parameters to carry routing context across authorization layers.
That creates a subtle but serious problem. OAuth state values are commonly used to bind a request to a callback and prevent cross-site request forgery. In delegated MCP flows, state may also carry routing information across layers. If that routing information is stored client-side without integrity protection, an attacker may alter it.
The paper’s nested context pollution case study describes an MCP server that placed downstream routing data inside state. The attacker decoded the state value, changed the nested callback destination to an attacker-controlled domain, and sent the forged authorization request to the victim. After the upstream authorization flow completed, the MCP server trusted the altered nested value and forwarded authorization credentials to the attacker.
For enterprise deployments, this is the type of issue that can be missed by normal OAuth testing. The first authorization layer may appear sound. The upstream identity provider may also behave correctly. The failure occurs in the glue logic that connects both layers.
Unauthenticated MCP Servers Are an Exposure Management Problem
The most direct finding in the paper is also the easiest to grasp: thousands of remote MCP servers were live on the public internet, and more than 40% of validated servers exposed tools without authentication.
Some of those servers may be demos, tests, or intentionally public services. That does not make the pattern safe. MCP tools often abstract sensitive backend actions behind simple callable methods. A server may expose a tool named in harmless language, yet that tool may query CRM data, read project documents, enumerate tickets, trigger workflows, or access logs.
This creates an exposure management problem for security teams. MCP endpoints should be inventoried alongside APIs, admin panels, remote management interfaces, and SaaS integrations. Security teams should know which MCP servers exist, where they are reachable from, which tools they expose, which identities they run under, and what downstream systems they can access.
What Security Teams Should Do Now
Organizations adopting MCP should treat remote MCP authentication as production security infrastructure, not developer plumbing.
The first step is asset discovery. Identify all MCP servers across development, staging, and production. Confirm which ones are publicly reachable, which use HTTP-based transports, and which expose tools tied to sensitive systems. Any unauthenticated remote MCP server should be treated as a potential external exposure until proven low impact.
The second step is OAuth flow review. Security teams should test whether the authorization server strictly validates callback destinations, rejects arbitrary DCR submissions, blocks unregistered client IDs, requires PKCE with S256, rejects authorization-code reuse, and displays meaningful consent details to users.
The third step is delegated-flow review. Any MCP server that brokers access to an upstream service should keep routing state server-side or protect it with integrity checks. Client-visible state should be opaque from the attacker’s perspective. The MCP layer and upstream layer should enforce consistent PKCE, state, redirect, and audience checks.
The fourth step is token and audience validation. The current MCP authorization draft requires MCP servers to validate that access tokens were issued for the MCP server as the intended audience, and states that clients must not send tokens to MCP servers other than tokens issued by that server’s authorization server. That control is necessary in agent ecosystems where a single client may interact with multiple tools, services, and authorization servers.
The fifth step is logging and detection. MCP authorization flows should produce security telemetry for registration attempts, callback mismatches, PKCE failures, weak state values, token exchange failures, unexpected localhost callbacks, and repeated authorization-code redemption attempts. These events should feed into the same monitoring stack used for web authentication and API abuse.
How Can Netizen Help?
Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally.
Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.
Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.
Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.
