Client-side MCP authorization flaws expose AI agent attack paths

At a glance

What this is: This is a research post on client-side MCP authorization weaknesses that can turn normal agent login flows into code execution, file execution, account takeover, or XSS paths.

Why it matters: It matters because AI agent integrations are expanding the attack surface at the client layer, where URL handling and browser-launch behavior become access controls by another name.

Context

Model Context Protocol clients are becoming a new identity boundary because they now mediate how AI agents discover authorization servers, launch browsers, and obtain tokens. When those client-side flows accept unsafe URLs or unsanitized schemes, the result is not just a bad login experience, but an attack path into the host, session, or browser runtime.

Traditional OAuth and application security assumptions do not fully cover MCP client behavior because the client is being asked to interpret remote metadata and then act on it locally. That creates a governance gap for AI agent access: the trusted boundary shifts from the server to the endpoint application that initiates the authorization flow.

Obsidian Security’s research shows that this is not a theoretical edge case. The same pattern appears across desktop, command-line, and browser-based MCP implementations, which makes the weakness structurally important for teams governing AI agent access and client-side authorization handling.

Key questions

Q: What breaks when MCP clients trust remote authorization endpoints too much?

A: Client-side trust breaks because the application is no longer just rendering a login flow. It is interpreting remote metadata, selecting a browser path, and potentially executing attacker-controlled input locally. That turns authorization discovery into a host compromise path when schemes, helpers, or redirects are not tightly constrained.

Q: Why do unsafe browser-launch flows create such high risk for AI agent clients?

A: Because the launch step can become an execution boundary. If the client passes unsanitized URL content into a shell, helper library, or browser wrapper, the result can be command injection, local file execution, or session compromise before the user finishes authentication.

Q: How do security teams know whether MCP authorization is actually working?

A: Look for evidence that consent is stored per client, tokens are validated at each hop, and invalid audience or redirect values are rejected consistently. If a server accepts session-only state, relayed tokens, or vague consent prompts, authorization is functioning as a convenience layer rather than a control.

Q: What should incident responders do when an MCP client authorization flow is abused?

A: Isolate the affected client, revoke any tokens issued through the compromised flow, and inspect whether local execution, browser session theft, or chained backend abuse occurred. The key is to contain both the identity artifact and the local execution path, because the compromise may span host and account layers.

Technical breakdown

How MCP authorization discovery becomes a client-side trust boundary

In the latest MCP authorization model, a resource server can advertise associated authorization servers through metadata discovery, and the client then follows that metadata to open an authorization endpoint. That sounds routine, but the client is now parsing remote instructions and turning them into local browser behavior. If the endpoint URL or scheme is not tightly constrained, the client becomes the enforcement point for security decisions that traditionally belonged to the server and browser ecosystem. This is why MCP authorization handling is not just protocol plumbing. It is a policy decision about which remote inputs may influence local execution.

Practical implication: Treat authorization discovery as a policy boundary and restrict which remote URLs and schemes a client may follow.

Why browser-launch helpers can turn authorization into code execution

Desktop and CLI MCP clients often need to spawn a browser process to complete OAuth, and many implementations rely on helper libraries rather than secure native launch routines. In that model, an unsanitized authorization URL can be interpreted by the shell or a platform-specific helper, which opens the door to command injection or unintended file handling. The risk is not the browser itself, but the wrapper around it. If that wrapper accepts attacker-controlled strings, then the authorization step becomes a local execution primitive instead of a safe redirect.

Practical implication: Audit every browser-launch path for shell interpretation, unsafe helpers, and incomplete URL encoding.

Why browser-based MCP clients are exposed to XSS and token theft

Browser-based MCP clients do not hit a shell, but they still consume authorization endpoints and load remote URLs. If a client accepts a javascript: scheme or similar attacker-controlled URL, the browser may execute script in the application context, leading to XSS, cookie theft, token theft from storage, or abuse of front-end to back-end channels. In self-hosted hybrids, that can even chain into backend command execution. The technical lesson is that browser runtime does not eliminate the client-side trust problem. It only changes the failure mode from OS-level execution to DOM-level compromise.

Practical implication: Enforce strict scheme allowlists and CSP-style protections for every browser-based authorization flow.

Threat narrative

Attacker objective: The attacker wants to convert a routine MCP authorization flow into host compromise, session theft, or account takeover through client-side trust abuse.

1. Entry begins when a malicious or manipulated MCP server advertises an authorization endpoint through metadata discovery and the client follows it without strong validation.
2. Credential or execution abuse occurs when the client launches the endpoint with an unsafe browser helper, unsanitized URL, or attacker-controlled scheme such as file: or javascript:.
3. Escalation follows as the payload triggers command execution, local file execution, XSS, or token theft depending on whether the client is desktop, CLI, or browser-based.
4. Impact is compromise of the client host, user session, or downstream application access, with some chains extending into account takeover or chained remote code execution.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP authorization is now a client-side identity control, not just a protocol detail. The article shows that the security decision is made where the client interprets remote metadata, opens a browser, and accepts a URL scheme. That shifts control responsibility from the server to the application runtime that initiates the flow. Practitioners should treat the client as part of the identity perimeter, because the authorization boundary is now enforced by code paths that were never designed as access policy engines.

URL scheme trust is a named concept: authorization endpoint scheme trust. This is the broken premise that a remote server can safely suggest a browser destination and the client can treat the scheme as benign. In practice, the difference between https, file, smb, and javascript is a security boundary, not a formatting detail. The implication is that MCP ecosystems need scheme governance at the client layer, because the identity risk emerges before token issuance even begins.

Conventional OAuth assumptions collapse when the client itself becomes executable policy. OAuth was built around redirect handling and browser-mediated authentication, but not around arbitrary desktop helpers, shell invocation, or hybrid front-end/back-end app behavior. That means the usual trust model, where the authorization server is the main security anchor, is incomplete for MCP clients. The practitioner takeaway is that authorization design must now account for local execution semantics, not only token exchange correctness.

AI agent access governance has a new choke point in the client implementation layer. Obsidian Security’s findings across desktop, CLI, and browser-based MCP clients show that agent access can be undermined by unsafe local handling even when the server side is behaving as expected. This is not a server trust problem alone, and it is not only an application security problem. It is a lifecycle and access governance problem for non-human identity flows that now depend on client behavior as much as on policy.

From our research library:

• Gartner predicts that more than 40% of agentic AI projects will be cancelled by the end of 2027, citing rising costs, unclear value and insufficient risk controls.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Authorization endpoint scheme trust: This article exposes a governance gap that many teams have not yet named, which is the assumption that remote authorization metadata is safe to turn into local browser behavior. Once MCP clients are part of the identity path, scheme allowlisting, process isolation, and host-level execution control become part of access governance, not just application hygiene. 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.

Security teams should expect MCP client abuse to show up first in endpoint behavior, browser context, and token-handling anomalies rather than in the authorization server itself. That makes client observability, scheme validation, and authorization-flow testing essential to any AI agent programme that relies on delegated access.

For practitioners

• Restrict authorization URL schemes Allow only http and https in MCP client authorization flows, and reject any endpoint that resolves to file, smb, javascript, or other unsafe schemes.
• Replace unsafe browser-launch helpers Remove browser-open wrappers that pass untrusted input through shell commands, and use a secure launcher that encodes every non-URL-safe character before process invocation.
• Harden browser-based client handling Apply strict content security controls, block javascript-scheme redirects, and separate authorization UI from privileged backend channels in hybrid MCP clients.
• Review client-side authorization assumptions Map every MCP client path that discovers, validates, and opens authorization endpoints, then test whether untrusted metadata can influence local execution or session state.

Key takeaways

• MCP clients can convert routine authorization discovery into host compromise when they accept unsafe endpoint schemes or launch paths.
• The evidence spans desktop, CLI, and browser-based clients, which shows that the weakness is architectural rather than isolated to one implementation style.
• Scheme allowlisting, safe browser launching, and strict client-side validation are the controls most directly aligned to the failure described in this research.

Key terms

• Mcp Client: An MCP client is the application or agent that connects to a Model Context Protocol server to request tools, data, or prompts. It manages the session, sends structured requests, and receives responses in a standard format. In identity terms, it is the calling party that may need authentication, authorization, and audit controls.
• Protected Resource Metadata: Protected resource metadata is machine-readable discovery data published by a service so clients can find its authorization expectations. For agent registration, it tells the actor where to look for supported flows and how to discover the trust model without relying on ad hoc integration.
• URL Scheme Allowlisting: URL scheme allowlisting is the practice of permitting only specific schemes such as http and https while blocking dangerous alternatives like javascript:, file:, and smb:. For AI agent clients, it is a basic control that prevents remote metadata from becoming code execution or token theft.
• Client-Side Trust Boundary: The point at which browser code is allowed to see, use, or transmit sensitive data. It is not a physical boundary, but a governance boundary defined by policy, monitoring, and control over what loaded scripts can access during execution.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.