Identity and OAuth Trace Analysis for Uncovering Covert MCP Server Registrations

Finding unauthorized MCP servers requires more than an inventory or a watch on new OAuth grants. Security teams need to link traces of OAuth registration to downstream activity and user identity, even when an OAuth record that should be there is missing. Identity-bound audit data reveals which servers are acting, whose session triggered the action, and where an unapproved connection entered the chain.

Why MCP servers are the new shadow IT problem

MCP adoption has outrun the controls around server registration. The protocol includes an OAuth 2.1-based authorization framework, but authorization is optional by default, and mandatory server registration and auditing are absent. Once deployed, a server can inherit permissions already granted without more checks on each agent request. The server is not automatically added to an approved inventory.

The CSA Agentic MCP Security Best Practices Guide reported that researchers had catalogued nearly 7,000 internet-exposed MCP servers by early 2026, with roughly half operating without authentication controls. Exposure is only part of the problem. Unauthorized servers can also be part of normal agent flows, including servers that attackers deploy after initial access to carry out lateral movement, data theft, or privilege escalation. An inventory cannot track registrations it never gets, and a network scan cannot tell whether an agent’s tool connection was approved.

Three registration techniques attackers use to stay off the inventory

Open Dynamic Client Registration, or DCR, lets attackers turn registration into malicious routing when arbitrary callback URLs are accepted. Authorization codes can then be hijacked through the callback. Fudan University’s measurement study documented this weakness in a production MCP server under CVE-2026-26390 and found dynamic client registration flaws in 96.6% of tested OAuth-enabled servers, making this the study’s largest registration attack surface. The MCP specification revision of 2026-07-28 deprecated DCR in favor of Client ID Metadata Documents, or CIMD, but legacy deployments and unpatched servers remain vulnerable.

Local-server exemption abuse takes a different route. A registry may authenticate remote servers but exempt those marked “local.” An attacker registers a malicious server with that type and a plausible description, and the registry accepts it without an authentication check. No OAuth flow takes place at all. The registration bypasses the very event a grant monitor expects to inspect.

Name shadowing instead borrows a trusted server’s identity. A rogue server copies its name so future tool calls intended for the legitimate server reach the fake one. The registration itself is the attack, so inspecting the server’s code may reveal nothing suspicious. Once chosen, it can intercept calls, read their data, or feed results that have been tampered with into the agent’s context.

With supply-chain delivery, these rogue servers can come through a trusted installation channel without a registration that looks out of place. The Sandworm_Mode campaign used npm typosquatting to target Claude Code, Cursor, and Windsurf with packages that installed rogue MCP servers. The UltraViolet Cyber TIDE Team advisory described postmark-mcp, an impersonated email connector modified to silently blind-copy agent-sent email to an attacker-controlled domain. Initial approval did not constrain later behavior. Local exemptions and name shadowing are especially troublesome because they avoid a clean OAuth event for the malicious connection, making a missing expected footprint a detection signal itself.

Why grant-layer OAuth monitoring misses covert servers on its own

Watching OAuth grants is useful, but it is insufficient. At the grant layer, an MCP-mediated connection has the same event shape, fields, and metadata as a traditional OAuth app authorization. Scoring new grants on static attributes does not reveal which MCP servers an authorized agent has loaded.

The split appears after authorization, on the endpoint. An OAuth log records the agent runtime and leaves its loaded servers, exposed tools, and system prompt unrecorded. Two users can authorize the same runtime against the same service while using completely different tool configurations. MCP also propagates the agent’s identity rather than the original user’s identity, leaving downstream tools unable to identify who triggered an action. A covert server inside that runtime needs no anomalous new grant.

Implementation flaws weaken the grant record further. The Fudan study found at least one authentication flaw in every tested server offering OAuth, identifying 325 flaws across its sample. OAuth support alone is not a reliable perimeter. Detection must therefore move beyond the authorization decision to activity logs and identity-bound events downstream of the grant.

How do security teams find employees using unauthorized MCP servers?

Security teams can start by comparing authorization traces with records of approved servers. A DCR registration with an arbitrary or mismatched callback URL points to malicious routing, particularly when the callback does not resolve to a known server. A token issued to a client absent from the approved registry exposes a different mismatch. The grant can look entirely ordinary. Its client identity is what fails the comparison.

Under the specification, clients must identify the resource in authorization and token requests, and servers must reject tokens issued for another server. When a token is accepted outside its intended audience, it points to misconfiguration or possible exploitation. This is the confused-deputy pattern in concrete terms. Server A tricks an agent into using credentials issued for Server B, and the trace exposes the crossed boundary.

Enumerating servers receiving calls and matching them against OAuth registrations identifies local exemptions and supply-chain installations that never entered an authenticated flow. A missing OAuth record is especially revealing where every sanctioned server is expected to have one. It is a gap that requires investigation and corroborating evidence. A familiar server name with a different client ID, endpoint URL, or certificate can also point to name shadowing.

Drive API events, Gmail activity, and Admin SDK login and token events provide evidence beyond the grant. File reads, API calls, or outbound connections inconsistent with the recorded scope can indicate a rug pull or a covert server using a legitimate client ID. The UltraViolet advisory recommends fingerprinting tool descriptions at the proxy layer to find changes in their definitions after registration. Invariant Labs’ open-source mcp-scan detects poisoned descriptions and other MCP configuration vulnerabilities, providing a registration baseline for later comparisons.

Attribution depends on joining these events across the run. The 2026-07-28 specification makes servers stateless, so context cannot be inferred from earlier requests. The links must be made explicit with server-minted handles passed as ordinary tool arguments and with logs in the client, gateway, server, and downstream systems. End-to-end OTEL tracing exposes missing spans where a span is expected. A downstream call without a traceable correlation identifier can indicate a broken pipeline or an inserted covert server, but tying it to an employee also requires the original user session.

How an MCP gateway closes the identity gap that trace analysis exposes

An MCP gateway provides a controlled point for preserving that session. It terminates agent connections and injects a signed JWT containing the original user session into every tool call. Downstream activity can then be attributed to a person and session as well as to an agent runtime. That changes what investigators can establish from the record. A gateway is not a replacement for trace analysis, but infrastructure that makes continuous analysis practical at scale.

Cisco deployed an MCP Catalog and in-path MCP policy control in February 2026, followed by agent zero-trust IAM through Duo in March 2026, with an AI BOM for agent inventory. Microsoft Entra Agent ID reached general availability in April 2026 and treats agent identities as a distinct construct separate from repurposed service principals. Its agents get tokens through a blueprint’s credentials, while the credentials stay off the agent. The distinction limits a compromised agent’s ability to exfiltrate its own keys.

Okta’s Agent SSO reached general availability on August 24, 2026. It uses ID-JAG, the Identity Assertion Authorization Grant, which is exchanged through Cross App Access for scoped access tokens that let it reach downstream applications. Its AI Agent Registration with CIMD uses vendor-hosted metadata URLs, automatic credential rotation, and per-agent tracking records. These capabilities serve different roles from inventory through authentication. Their relevance to detection depends on whether the resulting records support activity correlation and user attribution.

The gateway also makes tool fingerprinting enforceable in-path. The UltraViolet advisory names detecting, logging, and blocking changed tool definitions before they reach the agent as an immediate mitigation. Tamper-proof audit logs and end-to-end OTEL tracing supply the evidence needed to detect correlation gaps. Without those outputs, the gateway cannot support the cross-session analysis the detection method requires.

What the OAuth specification update requires and what it still leaves open

The 2026-07-28 specification update creates more explicit evidence for analysis. An MCP server must implement OAuth 2.0 Protected Resource Metadata under RFC 9728. Clients must send the RFC 8707 resource parameter on both authorization and token requests, and servers must reject tokens not issued for themselves. The latter two requirements date to the 2025-06-18 revision. They remain mandatory in 2026.

Deprecating open DCR in favor of CIMD also changes the registration surface. With metadata and audience-bound tokens, the revised framework gives defenders a clearer view of identities and their intended destinations to compare. Those records do not settle approval, however. Proving an agent’s identity does not establish who authorized it, what it may do across a multi-step run, or how that decision should be enforced across different servers.

Stateless operation leaves another operational question open. Cross-request links must be explicit, but the specification does not mandate how correlation identifiers are structured, logged, or retained. Okta’s AI Agents at Work 2026 report found that only a minority of organizations apply the same security controls to agents as to people. Standards compliance is therefore necessary but insufficient. Each organization is still responsible for watching traces, linking them to activity, and checking them against authorization policy.

A practical detection program built on identity-bound audit data

Operations begin with a baseline built from both inventory and evidence of use. The UltraViolet advisory recommends inventorying all MCP servers, classifying them as local or remote, and removing or isolating unvetted or inactive servers. For each remaining server, the program should establish its OAuth registration, valid client ID, audience-bound token, and callback to a sanctioned endpoint. Teams should check active servers that lack the expected footprint first.

That baseline makes continuous monitoring meaningful. New client registrations should be matched against approved registries, with alerts for unrecognized callbacks, out-of-audience token use, and trusted names appearing with different client IDs or endpoints. Registration scanning through mcp-scan or equivalent tooling should establish tool-description fingerprints. Approval is only the starting condition, though. Grants must also be correlated with downstream behavior, while proxy controls detect, log, and block changed definitions before they reach the agent.

The advisory recommends disabling automatic approval of tool invocations in production and requiring human or policy approval for new calls. Those decisions become part of the audit record. They complement scope-to-activity comparisons, which can expose a rug pull even when the original installation looked legitimate.

The next dependency is identity propagation across the pipeline. A gateway should inject the original user session as a signed JWT, while every tool call in a multi-step run has a traceable correlation identifier. End-to-end OTEL tracing makes missing expected spans visible. Teams should keep tamper-proof logs in line with the EU AI Act high-risk logging obligations. Recitals 99 and 100 concern general-purpose AI models and systems and leave multi-agent compliance scope unaddressed.

A formal program aligned with the OWASP MCP Top 10 and emerging standards should include version pinning, signed tool definitions, continuous dependency monitoring, and quarterly red-team exercises targeting agentic AI workflows. Agent identities also need the same access reviews, offboarding, and audit cycles that human accounts get. Attribution without ownership cannot sustain those controls. The teams that build this program make broad MCP adoption safe enough to accelerate, rather than leaving every new integration to become another emergency.