Client-side MCP authorization flaws expose AI agent attack paths

At a glance

What this is: Obsidian Security found that common MCP client implementations can be abused through unsafe authorization flows to trigger RCE, LFE, XSS, and account takeover.

Why it matters: This matters because practitioners now have to govern AI agent access at the client, protocol, and identity layers at once, not just the server or tool layer.

👉 Read Obsidian Security's analysis of common MCP client vulnerabilities

Context

MCP client authorization is the control point that decides which tools and data an AI agent can reach, and this article shows that the client side is often where that control breaks down. The primary problem is not OAuth itself, but the unsafe handling of authorization discovery, URL opening, and browser launch logic inside MCP clients.

For AI agent programmes, this creates an identity governance problem as much as an application security problem. The agent may be the visible actor, but the exposed surface is the client process, the metadata lookup, and the local operating system functions that transform a remote authorization endpoint into code execution or token theft.

The broader lesson is that agent access control cannot be treated as a clean server-side policy layer. Once client implementations accept untrusted endpoints, dynamic URL schemes, or insecure open handlers, the trust boundary shifts onto the endpoint and the user's session context.

Key questions

Q: How should security teams enforce per-client authorization in MCP environments?

A: Security teams should bind each request to a specific client identity, approved scope, and approved operation on the server side. The user’s general login must never become blanket permission for any application that can reach the MCP endpoint. Consent records, exact client identifiers, and server-side policy checks are the controls that prevent confused deputy abuse.

Q: Why do MCP servers create new identity risk for AI-native development?

A: MCP servers create risk because they extend delegated access from the model into repositories, data, and workflow tools. If the trust path is too broad, the agent can act with capabilities that were never intended for that task. Teams should review those connections as access paths, not just as integration plumbing.

Q: What breaks when URL schemes are not restricted in agent clients?

A: Untrusted schemes can move a workflow from normal login into command injection, local file execution, XSS, or token theft. Once the client accepts arbitrary schemes, the attacker no longer needs direct server compromise. They only need the client to interpret their URL as something executable or scriptable.

Q: Who is accountable when an MCP client exposes tokens or executes hostile input?

A: Accountability sits across the application team, the identity team, and the platform owner because the failure spans protocol handling, endpoint policy, and local runtime behaviour. NIST zero trust and application security controls both apply, but neither replaces the need for client-side authorization governance.

Technical breakdown

How MCP authorization discovery becomes a client-side attack path

MCP clients use OAuth metadata discovery to find authorization endpoints and then open a browser or browser-like view to complete sign-in. That flow is safe only if the client strictly validates the endpoint and the URL scheme. When a remote MCP server can influence the authorization endpoint, the client is no longer just consuming a login address. It is interpreting attacker-controlled metadata, launching local processes, and potentially passing untrusted input into shell helpers or browser handlers. In practice, that converts a trust decision about a remote resource server into a local execution problem.

Practical implication: restrict MCP authorization endpoints to approved schemes and validate metadata before any browser launch occurs.

Why browser-launch helpers can turn into RCE or LFE

Many MCP clients rely on helper functions such as open, shell.openExternal, or webbrowser.open to launch a browser. These helpers often invoke operating system commands under the hood so that the correct app handles the link. If the URL is not safely encoded, the helper can interpret special characters, alternate schemes, or file paths in ways that trigger command injection, local file execution, or remote code execution. The risk is highest where third-party libraries wrap this behaviour without strong security guarantees and where users trust a remote authorization flow to behave like a normal login.

Practical implication: remove unsafe open handlers from the authorization path and use a strict allowlist for URL handling.

Why browser-based MCP clients face XSS and token theft instead of shell execution

Browser-based MCP clients usually cannot spawn shell commands directly, but they can still be abused through JavaScript-in-URL and weak content security controls. If a client renders attacker-controlled authorization links with location.href or window.open without scheme filtering, a javascript: payload can execute in the page context. That opens access to session cookies, localStorage tokens, and application actions. In self-hosted hybrids, the browser layer can also talk to backend components, which turns XSS into a stepping stone for chained compromise.

Practical implication: enforce scheme filtering and CSP together, because blocking only shell execution does not close the browser-side attack path.

Threat narrative

Attacker objective: The attacker wants to turn a trusted MCP authorization flow into client compromise, session theft, or downstream account takeover.

1. Entry occurs when a malicious or compromised MCP server supplies an authorization endpoint or URL scheme that the client accepts during OAuth metadata discovery.
2. Escalation occurs when the client passes that untrusted input into a browser launcher or browser context, allowing command injection, local file execution, XSS, or token theft.
3. Impact occurs when the attacker gains code execution, session access, account takeover, or chained control over the client host and the connected AI agent workflow.

Breaches seen in the wild

• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Client-side MCP authorization has created a new identity control plane problem. The article shows that the decision boundary now sits inside the client, where metadata discovery, browser launch logic, and OS helpers all influence access. That means identity teams can no longer treat agent authorization as a pure server-side concern. Practitioners need to recognise the client as part of the access enforcement surface.

Authorization endpoint trust is no longer a safe assumption in agentic workflows. The old OAuth premise is that the client can trust metadata enough to route a user to the right login page. In MCP implementations, that premise breaks because the endpoint itself can become the payload. The implication is that identity governance for agents must examine how trust is established before any token is minted or any tool call is allowed.

Runtime URL handling is now an identity security control, not just an application detail. A malformed or attacker-controlled URL can cross the line from login flow into code execution, file execution, or session theft. That puts protocol parsing, scheme filtering, and handler selection into the same category as privileged access controls. Security teams should stop treating these as edge cases and start treating them as part of agent access governance.

AI agent programmes inherit the weakest client in the chain, not the strongest server policy. The research spans desktop tools, command-line clients, and browser-based implementations, which means the exposure is architectural rather than product-specific. When a remote server can influence local execution or browser context, the trust model collapses across multiple layers at once. Practitioners should assume agent access is only as safe as the client that interprets it.

Browser-based MCP clients shift the threat from shell compromise to session compromise. That matters because token theft and cookie theft are often enough to take over the identity boundary without ever touching the operating system. For IAM and security teams, this widens the scope of agent governance from local hardening to session protection, CSP enforcement, and token containment.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• For a broader control model, OWASP NHI Top 10 helps teams map agentic risks to runtime governance and tool access controls.

What this signals

Client-side identity governance is becoming a first-class control plane for AI agent programmes. Once an MCP client can interpret hostile metadata as a login instruction, the access boundary is no longer the server or the vault. Practitioners need to audit where authorization is parsed, where URLs are opened, and where tokens are stored, because those are now governance points, not implementation details.

Runtime trust debt is the right concept for this pattern. Every time a team accepts dynamic authorization discovery without strict scheme filtering, it accumulates trust debt in the agent stack. That debt shows up later as session compromise, local execution, or hard-to-trace token abuse, and it is much cheaper to stop at discovery than to investigate after the fact.

With 96% of technology professionals already identifying AI agents as a growing security threat, per the AI Agents: The New Attack Surface report, the operational question is not whether agents will proliferate but whether the client layer can be governed at the same speed. Teams should align MCP hardening with the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10.

For practitioners

• Restrict authorization endpoints to approved schemes Allow only http and https for MCP authorization discovery, and reject javascript:, file:, smb:, and any other non-web schemes before the client renders or opens them.
• Remove unsafe browser-launch helpers from the trust path Avoid third-party open handlers that do not guarantee safe encoding, and do not pass raw metadata into shell-based browser launch logic.
• Treat MCP clients as privileged identity endpoints Review desktop, CLI, and browser-based clients as access-enforcing software that can expose credentials, session tokens, and local execution paths.
• Apply content security controls to browser-based clients Use strict scheme filtering, a tight content security policy, and defensive handling of window.open and location.href to prevent JavaScript URL abuse.
• Test the full authorization chain with hostile inputs Validate how each client handles malicious metadata, redirected authorization endpoints, and edge-case URL encodings before agent access reaches production.

Key takeaways

• MCP client authorization flaws show that AI agent identity risk now extends into local runtime and browser handling, not just server-side access policy.
• The evidence points to a repeatable attack pattern across desktop, CLI, and browser-based clients, with command injection, local file execution, XSS, and account takeover all in scope.
• Practical governance starts by restricting schemes, removing unsafe open handlers, and treating agent clients as privileged identity endpoints.

Key terms

• MCP authorization: MCP authorization is the control layer that decides whether an agent or client may use a specific tool in a specific context. In secure deployments, it must go beyond token claims and incorporate user identity, resource ownership, and policy at request time.
• Client-side RCE: Client-side RCE is remote code execution that happens on the user's device or workstation rather than on a server. In MCP contexts, it often appears when browser launch helpers, shell wrappers, or URL handlers interpret attacker-controlled input as a command or executable path.
• 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.
• Metadata Trust Boundary: A metadata trust boundary is the line between tool content that can be safely consumed and tool content that must be validated before use. For agentic systems, descriptions, examples, and schemas are security-relevant inputs because they can influence decisions and trigger actions with real-world impact.

What's in the full article

Obsidian Security's full research covers the operational detail this post intentionally leaves for the source:

• Step-by-step proof-of-concept behaviour for the affected MCP clients across desktop and browser-based implementations.
• The exact metadata discovery sequence that turns authorization server lookup into a local trust decision.
• Technical examples of command injection, local file execution, XSS, and chained RCE paths.
• The coordinated disclosure timeline and the CVE references assigned to the affected client flaws.

👉 Obsidian Security's full post covers the affected clients, proof-of-concept behaviour, and mitigation details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.