AI Trustfall: How Untrusted AI Agents Get Trusted Access Through MCP

61%

of MCP authorization servers had at least one exploitable security gap

8%

of servers combined missing PKCE with a hijackable redirect — one click, one working access token

81%

of consent pages disclosed zero permissions before approval

29%

of servers honored MCP tokens at full API privilege, up to 22 scopes beyond what was granted

88%

of consent pages had no protection against clickjacking

AI agents are only useful when they can reach your data. Model Context Protocol (MCP) is the standard way they ask for that permission, and very little stands between the request and approval.

Varonis Threat Labs tested that assumption across 1,034 production MCP authorization servers in widely used SaaS products. We found an ecosystem-wide pattern where an unverified client can walk straight into a trusted OAuth flow and leave with a working access token, no password required.

By design, a single POST request is enough to register an OAuth client against a production MCP server, complete with its own name, redirect URI, and requested scopes.

Seconds later, that client can generate a consent link on the vendor’s own domain. If a signed-in user clicks Allow, the server issues a working access token to whoever controls the newly registered client. This flow was built for trusted agents, but nothing prevents an attacker from using it exactly as is. The consent page is meant to keep the human in the loop by making that request clear before anyone approves it, but it's not doing the job.

While updates to the DCR protocol have been announced, it will remain active until July 2027, as well as the risks. There is no universal fix or easy button for practitioners during this period.

Continue reading to discover how legitimate and malicious MCP flows work, where consent clarity breaks down, and what security and IT teams can do about it.

Four pieces combine to create the problem; each step seems reasonable on its own. Together, they create the Trustfall.

In weaker implementations, additional vulnerabilities compound the risk. Missing PKCE allows authorization of code interception, loose redirect URI validation allows code redirection to attacker-controlled endpoints, and XSS in consent pages through unsensitized client metadata can automate approval.

The malicious flow is byte-for-byte the legitimate one. The only difference is who chose the values. Here is what the attacker sends, and what the server sends back.

The RFCs are explicit about what the consent screen owes the user:

• RFC 6749 section 10.2 tells authorization servers not to let one client masquerade as another in the UI.
• RFC 7591 section 5 instructs servers to treat dynamically-registered client metadata as untrusted and to communicate that lack of verification to the user.
• The OAuth 2.0 Security BCP (RFC 9700, January 2025) hardens both with concrete UI requirements. We tested every part of that screen, finding that the consent screen is not holding up.

0

100

200

300

400

500

Servers affected (of 1,034)

We sent an /authorize request with no code_challenge and no code_challenge_method. 12% of servers returned 200, rendered a consent page, and issued an authorization code on Allow. The code exchanged at /token with no code_verifier.

What an attacker gains: PKCE is the protection that turns an authorization code from a bearer secret into something only usable by the client that initiated the flow. Without it, a code that leaks anywhere, such as a query string in a server log, browser history, referrer header, an SSRF, or an open redirect, becomes a full access token. The leak channels are abundant; PKCE is the only thing standing between a leak and full account takeover.

We posted to /register with a JavaScript: URI as redirect. 47% of servers returned HTTP 201 and stored it. RFC 6749 section 3.1.2 requires an absolute URI, JavaScript is a pseudo-protocol.

What an attacker gains: Modern desktop browsers refuse to navigate to JavaScript from a 302, which mitigates the solo case. But MCP is consumed primarily by agent clients, that is, HTTP-only clients and embedded web views with their own policies. The CRLF chain below bypasses the browser block by smuggling JavaScript into a location header. The consumer is software, not Chrome.

On 8% of the servers, the full chain fires as follows: register with the JavaScript redirect -> send the victim one authorize link -> Victim clicks Allow -> The code lands at the attacker-chosen destination, redeemable without a code_verifier -> One registration, one link, one click, and a working access token.

What an attacker gains: Account takeover with no credential theft and no malware. Either gap alone still leaves the attacker a problem to solve; together they cancel out. The code lands where the attacker chose, and anyone holding it can redeem it. The result is an access token, usually with a refresh token for persistence, and nothing in the victim’s account looks wrong except for a connected app they would have to look for.

We compared each MCP endpoint’s OAuth issuer against its vendor’s main product and against sibling MCP services. 273 endpoints share their issuer with the vendor’s primary API, and 62 across 25 clusters share with sibling MCPs — 29% combined. None emit tokens with an aud claim.

What an attacker gains: A token minted on the MCP consent surface, consented with one narrow scope, is structurally indistinguishable from a token minted on the vendor’s primary API.

The attacker presents the same bearer token to the parent product’s API, which validates only iss and signature, granting its broader scope set. The median parent advertises three additional scopes the MCP doesn’t. The maximum observed was 22 including admin/write/delete, manage_runner, k8s_proxy, backup:write, backup:delete, and webhook:manage.

No exploit chain required, just a legitimate token honored by a surface it was not minted for.

We registered with a redirect_uri containing a literal \r\n. 19% of servers (196 of 1,034) reflected attacker-controlled HTTP headers from the registration response. A more aggressive variant, injecting location and JavaScript:void(0) succeeded on 70 of those 196.

What an attacker gains: Forced redirect to JavaScript via the injected header, bypassing the browser-level navigation block. Cache poisoning, where edge caches store the forged response. WAF and proxy bypass through header smuggling.

Across four reflection vectors, 75 distinct servers reflect attacker-controlled HTML or script into the consent DOM:

• Unescaped client_name: The server stored a literal <img onerror=…> tag and rendered it live on the consent page. It fires on page load, with no click required.
• State parameter reflected unescaped: Payload delivered through the state= query parameter.
• Scope parameter reflected unescaped: The same issue, through scope=.
• JavaScript URI rendered as <a href>: DCR fields client_uri, tos_uri, and policy_uri rendered as clickable links that execute attacker code.

88% of consent pages had no X-Frame-Options and no frame-ancestors CSP. The attacker hosts a transparent overlay, the victim clicks what they think is a button. On the attacker’s site, the click lands on Allow.

What an attacker gains: Automated consent approval without the user reading anything. One HTTP header closes this — the highest fix-cost-to-impact ratio across the entire dataset.

Any single MCP gap weakens the flow. When multiple gaps appear together, they form a reliable path from one POST to /register and one link to a working access token with persistent refresh capability.

The blast radius depends on the product, but the security failure does not. An unverified client enters a trusted OAuth flow and leaves with access the user never understood, and the server never constrained.

For MCP authorization server operators

If you operate an MCP authorization server, you can test these controls today:

Require PKCE with S256 for all public clients. Do not make it optional.

Enforce exact redirect URI matching. Allow only safe URI schemes (https:). Reject JavaScript, data, and wildcard patterns.

Bind every token to an audience. Issue MCP tokens with an aud claim naming the MCP resource and validate aud at every API, not just iss and signature. If the MCP service shares an issuer with your primary API or with sibling MCPs, that check is the only safeguard stopping a narrowly consented MCP token from being replayed for the parent product’s full scope set.

Sanitize all DCR metadata. Reject CRLF and control characters. HTML-encode client names, logos, and URLs before rendering.

Label unverified clients. The consent page must clearly distinguish a dynamically registered client from a verified or first-party application.

Render scopes in plain language. Show the user what they are granting before they approve.

Provide a visible deny path. Every consent page needs a clear cancel or deny option.

Prevent clickjacking. Set Content-Security-Policy: frame-ancestors 'none' on authorization endpoints.

Do not ask for secrets in consent flows. OAuth consent pages should never request API keys, personal access tokens, or passwords.

Monitor DCR activity. Log and alert on unusual registration patterns and consent grants.

Fetch client metadata documents safely. If you support CIMD, the document fetch is an outbound request to a URL a stranger chose. Block internal and link-local addresses, cap redirects, size, and timeout, and never follow the fetch into your own network.

Match the client_id to its document exactly. The identifier inside the metadata document must equal the URL it was fetched from, character for character, and the redirect URI must already be listed there. No normalization shortcuts, no prefix matching.

For the MCP and OAuth ecosystem

The standard is already correcting course. The MCP spec’s 2026-07-28 revision deprecates Dynamic Client Registration and points implementers at Client ID Metadata Documents (CIMD).

DCR and CIMD both solve the same problem, giving a client the server has never met a client_id. They just solve it in opposite directions.

An anonymous stranger POSTs a blob of self-asserted JSON, and the server parses it, stores it, and later renders it back to a user on its own domain. Every number in this report traces back to that single decision:

• Attacker-chosen text lands in the DOM. That is why 75 servers reflected attacker-controlled HTML through client_name and the other DCR fields.
• Attacker-chosen bytes go into a response header. That is why 196 servers could be made to emit forged headers through a redirect_uri carrying a literal \r\n.
• Attacker-chosen destinations get stored without validation. That is why 47% accepted a javascript: pseudo-protocol as a redirect URI and returned 201.

And because registration is free, anonymous, and unlimited, nothing about the resulting client_id ties back to anyone. The consent page ends up holding a decision it was never given the evidence to make.

The client hosts a JSON document at an HTTPS URL it controls. That URL is the client_id. The authorization server fetches the document the first time it sees the identifier, verifies that the client_id inside matches the URL exactly, checks the requested redirect URI against the list in the document, and caches the result. There is no registration endpoint, no write path, and no stored record to poison.

On a CIMD server, the same attacker publishes this instead of POSTing it:

Note what survives and what does not. The name is still whatever the attacker typed. But the client_id is now a URL the victim's server resolves, the redirect has to live on that same host, and the whole thing is attributable to a domain someone had to register.

That inversion retires entire vulnerability classes rather than patching them on a per-server basis. Removing /register removes the CRLF injection sink and the unbounded registration table behind it. Requiring the redirect URI to already appear in a document served from the client's own origin means an attacker can no longer point a legitimate vendor's flow at attacker.example, or at a javascript: URI, unless they own the domain the user is being shown.

The identifier stops being an opaque string like dyn_evil789 and becomes a name with an owner. Defenders can allowlist, denylist, rate-limit, and revoke by domain, and abuse now burns a registered domain instead of costing an attacker one HTTP request.

That is the argument for moving early. Servers that adopt CIMD do not have to get sanitization, storage hygiene, and redirect validation right on every one of those fields — they simply no longer accept them.

Here’s the catch: CIMD is what everyone is moving to, but it isn't a ratified standard yet. DCR is deprecated, yet remains the only real RFC. So, you should support both for now. The deprecation window means that DCR-only servers will remain active until roughly July 2027. Every finding in this report applies to them for the entire window.