Browser Agent Security Risks in MCP-Connected Environments

Start with what a browser agent actually does. It visits pages, reads content, clicks buttons, fills forms, and navigates sessions, all without a human confirming each action. In an MCP-connected environment, it does something more: it translates what it sees on the web into tool calls against enterprise systems. A single page visit can cascade into a database query, a file write, a sent message. The agent is not just browsing; it is acting as an authenticated principal across multiple systems simultaneously.

That combination got a name in June 2025 when Simon Willison described what he called the "lethal trifecta": an agent that holds access to private data, processes untrusted content, and can communicate externally is exploitable by design, not by misconfiguration. Browser agents are the purest expression of that trifecta. They carry enterprise MCP credentials into every page they visit. Every page is untrusted. And every MCP tool they can call is a channel outward.

The deeper problem is that there is no architectural wall between code and data in this setup. In a traditional application, input validation separates the two: data goes here, instructions go there, the runtime enforces the boundary. In an LLM-based agent, a tool description is data the model reads as an instruction. A page's content is data the model reads as context, which it can treat as instruction. The model cannot, by construction, reliably distinguish between "here is information to use" and "here is something to do." OWASP ranked prompt injection as the number-one threat in its top-ten list for LLM-based applications not because it is exotic, but because the architecture provides no natural defense against it.

This matters practically in a way that traditional perimeter security is not built to handle. A perimeter review examines a boundary once. In an MCP-connected browser agent, new untrusted content enters the model's context window continuously, from every page it visits, every tool response it receives. The attack surface is not static. It regenerates with every action the agent takes.

The adoption numbers sharpen the urgency. MCP went from an Anthropic-only specification in November 2024 to shipping inside Claude, ChatGPT, Gemini, Cursor, VS Code, JetBrains, and Zed by mid-2026, with the official registry crossing 5,000 servers in the same window. A PwC survey of 300 executives in May 2025 found 88% planned to increase AI budgets over the next 12 months specifically because of agentic AI. These agents are not approaching production; they are in it. Which means the risks that follow are present conditions, not theoretical futures.

How prompt injection reaches an enterprise agent through ordinary web browsing

The mechanics are disarmingly simple. An attacker hides instructions on a webpage: white text on a white background, zero-opacity HTML elements, content buried in comments, instructions tucked into URL fragments. A human sees nothing. The agent's content parser reads everything.

The agent visits the page for an entirely legitimate reason, to summarize an article, check a price, verify a status. It encounters the hidden instruction and executes it using whatever authenticated sessions it currently holds. No user confirmation. No anomalous action. The agent did what it was asked to do, and then it did something else.

Browser agents are more exposed than text-only agents because they operate across a wider set of surfaces. By October 2025, Brave's security team had documented injections embedded in screenshots as faint text that the browser agent's OCR pipeline read and acted on. Agents that perceive pages visually rather than parsing HTML can be injected via images entirely. Opacity-zero elements disappear from the rendered display but remain fully present in the parsed DOM. The attack surface expands with the agent's perceptual capability.

The real-world confirmation came in August 2025, when Brave's security team found a hidden instruction inside a Reddit spoiler tag that caused Perplexity's Comet to extract a user's email address and a one-time passcode. A consumer context, a relatively contained harm. Now apply the same mechanism to an enterprise browser agent that holds an active MCP session with write access to internal systems, and the spoiler tag becomes something more serious.

Research on attack success rates offers no reassurance. Injection attacks have achieved success rates that can be strikingly high across different LLMs and tasks, and more capable models are not more resistant. In some configurations they are more susceptible, because their instruction-following is stronger. The same competence that makes them useful makes them compliant with attacker instructions. Academic evaluation found that all eight published prompt injection defense approaches can be bypassed at the model layer. This is not a problem with a known solution waiting to be deployed.

The enterprise escalation from the consumer case is direct. The same instruction that steals an OTP from a personal agent can, inside an enterprise browser agent, call an MCP tool, send a message, write a file, query a database, using whatever privileges the MCP session carries. The web page does not need to know which MCP tools are available. It only needs to instruct the agent broadly enough that the agent's own context window supplies the rest.

Tool poisoning: how a malicious MCP server turns agent capability against the enterprise

Prompt injection enters through the browser layer. Tool poisoning enters through a different channel, one the agent already treats as trusted.

Here is the mechanism: an attacker operates an MCP server whose tool descriptions appear legitimate at review time. The poisoned content is not in the description. It is in the tool's response. That response enters the agent's context window as a trusted return value, and the agent processes it as instruction. The attack surface is not the onboarding review; it is every runtime tool call the agent makes afterward.

The MCPTox benchmark made this concrete. Researchers evaluated 20 prominent LLM agent configurations against 45 live MCP servers using 353 authentic tools. Attack success rates exceeded 60% broadly. One model reached 72.8%. The highest refusal rate recorded across all configurations was Claude 3.7 Sonnet, at under 3%. That number deserves to sit for a moment. The best-performing safety alignment in production frontier models declined fewer than 3 tool-poisoning attempts out of every 100. Existing safety training is not a meaningful defense here.

CyberArk researchers identified a variant that bypasses even description-level scanners by embedding malicious instructions not in tool descriptions but in function names, parameter types, required-field arrays, and default values. Any review process that checks only the description field misses it entirely.

Then there is tool shadowing, which is more insidious than direct poisoning. A malicious server embeds meta-instructions in its own description that govern how the agent should behave when calling tools from other servers in the same context. The attacker's server never touches the target tool's execution. The agent bridges the boundary itself, following instructions it received from one server while acting on another.

Two incidents from April 2025 confirmed the mechanism in practice. Invariant Labs demonstrated a poisoned math tool that read SSH keys and exfiltrated them encoded inside a math function parameter: no user interaction, no persistent trace, a clean operation the agent completed as a side effect of doing arithmetic. The same month, a malicious MCP server co-present with a legitimate WhatsApp MCP server instructed the agent to read message history and transmit it to an attacker-controlled number. The poisoned description appeared visually benign in tool review interfaces.

Rug-pull attacks and why point-in-time security reviews don't hold

The two incidents above involve attackers who operate malicious servers from the start. The rug-pull attack is more patient, and in some ways more dangerous, because it exploits the enterprise security review itself.

MCP provides no mechanism for continuous re-verification once trust has been extended. A server that passes onboarding review can be modified at any point afterward. A connected agent treats the modified server as the same trusted integration it approved. The gap between "reviewed" and "current state" is entirely unmonitored by the protocol.

The attacker's playbook is straightforward: publish a legitimate server, accumulate usage and goodwill over weeks or months, then update tool descriptions or response content with poisoned instructions after enterprise approval. Every agent that connected under the original terms continues running under the new ones.

CVE-2025-54136 documented exactly this in July 2025. An attacker committed a benign MCP configuration to a shared repository, waited for developer approval, then replaced it with a malicious payload in a subsequent commit. Every Cursor IDE session after that point executed the attacker's commands silently, with any credential accessible to the process in scope.

The first confirmed in-the-wild malicious MCP server arrived in September 2025. An unofficial Postmark MCP server with meaningful weekly usage was quietly modified to add a BCC field to its send-email function, silently copying every outbound email to an attacker's address. Users with auto-update enabled began leaking email content with no visible change in behavior.

MCP's June 2025 revision added tools/list_changed notifications so clients can detect mutations. But enforcement is client-side and inconsistent across implementations. Detection depends entirely on whether the client chose to implement the notification handling.

A governance posture built on "we reviewed it at onboarding" is not a security posture. It is a snapshot that decays the moment any server owner pushes an update.

How supply chain compromise reaches browser agents through the MCP package ecosystem

With tens of thousands of public MCP servers indexed and the protocol becoming the default AI integration layer, the MCP ecosystem is reproducing the supply chain vulnerabilities that defined npm, with a larger blast radius. A compromised npm package runs code. A compromised MCP server directs an agent that can read your files, send your email, and write to your database.

Registry vetting is largely absent. The OX security team submitted a proof-of-concept malicious package to 11 MCP registries; 9 of 11 accepted it without rejection. The ecosystem grew faster than the gatekeeping.

Worm-level propagation has already been documented. The Shai-Hulud worm, discovered in late 2025, compromised 796 npm packages representing approximately 132 million monthly downloads. It specifically targeted packages with "mcp-server" in their names, injecting prompt-injection payloads aimed at AI coding assistants alongside SSH propagation mechanisms and API key harvesting. A single compromised package in that category reaches every developer who installs it and, transitively, every agent that uses it.

Trend Micro found 492 MCP servers exposed to the internet with no authentication whatsoever, each a potential entry point for any agent that connects to it. A survey of more than 1,800 deployed MCP servers found over 30% had at least one exploitable vulnerability. These are not edge cases; they represent a significant share of the ecosystem as it exists in production today.

The Verizon DBIR 2025 found that 30% of all data breaches now originate with third-party compromise. The supply chain is already the dominant breach vector in conventional software. MCP inherits that exposure without the mature tooling, the audit pipelines, the dependency scanners, or the incident history that has slowly made npm and PyPI more defensible over the past decade.

For browser agents specifically, a compromised MCP server in the tool chain does not need to attack the browser layer at all. It delivers its payload through tool responses the agent already trusts, through a channel the agent has no reason to scrutinize.

Session hijacking and confused deputy: how the MCP protocol layer leaks privilege

The previous vectors require either a malicious server or a malicious web page. These next two require neither.

When multiple stateful HTTP servers handle MCP requests, an attacker who obtains an existing session ID can send malicious events to alternate servers while impersonating the original client. Browser agents are structurally exposed to this because they maintain persistent authenticated sessions by design. The session continuity that makes them useful is the same continuity that an attacker can hijack.

The confused deputy is a different kind of problem, one built into how permission scoping typically works in early deployments. The MCP server executes actions using its own elevated credentials, not the requesting user's. A user without database administrator access asks the agent to run a query; the server, which holds admin credentials, complies, because nothing in the default protocol behavior checks whether the requesting user is authorized for what the server can do. No injection required. No malicious content. The vulnerability is in the permission architecture, not in any attack payload.

OAuth-layer confused deputy compounds this. Attackers can exploit MCP proxy servers connecting to third-party APIs by combining static client IDs, dynamic client registration, and consent cookies to obtain authorization codes without proper user consent. The user believes they are authorizing one scope; the attacker's configuration has them authorizing something broader.

Server-side request forgery is a related protocol-layer vector. Tool-supplied URLs that route requests to internal endpoints or cloud metadata services turn ordinary MCP tool calls into SSRF attacks. The preconditions are missing egress allowlists and absent URL scheme validation, both common in early-stage deployments that prioritized capability over constraint.

What these vectors share is that none of them require a sophisticated attacker with a malicious server or a carefully crafted web page. They exploit how the protocol handles identity, session, and privilege by default. They are not exceptions to normal operation; they are features of it, used in unintended ways.

How these vectors combine when a browser agent operates inside a multi-server MCP topology

The realistic enterprise configuration is not one agent connected to one server. It is one agent connected to a web-browsing tool, a GitHub integration, a database connector, and an email sender, all active in the same context window simultaneously. Each server is legitimate. Each connection was reviewed. And the combination creates an attack surface that none of the individual reviews addressed.

Walk through how an attack chain works in this topology. The browser agent visits a page containing a hidden prompt injection, a routine visit for a benign reason. The injected instruction directs the agent to call the GitHub MCP server and read issues from a private repository. A poisoned tool response from a second MCP server in context then instructs the agent to transmit the retrieved content via the email MCP server. The email server executes using its own elevated send privileges, a confused deputy completing the chain, with no per-action user authorization at any step.

Invariant Labs documented this class of attack in May 2025. Hidden instructions in a public repository's issue tracker caused a Claude Desktop agent to open private repositories via the same GitHub MCP session and leak their contents into a public pull request comment, all triggered by a routine instruction to look at recent issues. The chain crossed from public web content to private enterprise data to public disclosure without any anomalous authentication event.

Palo Alto Unit 42 identified an additional compounding vector in December 2025: covert tool invocation via MCP sampling, where the protocol allows tool calls and file system operations to occur without user awareness. Steps in the chain can be invisible not just in real time but in retrospect, with no log entry the user would recognize as theirs.

The key escalation property of multi-server topology is that each hop uses a legitimate tool call with legitimate credentials. There is no failed permission check. No anomalous authentication request. Nothing a perimeter control flags, because from the perimeter's perspective, the agent is doing its job.

What is missing from most deployments is a real-time record of what the agent called, in what sequence, with what parameters, and why. Without that record, the chain completes before anyone knows it started.

What governs how far a browser agent's compromise can actually propagate

The primary limiting factor is scope: what the agent is actually permitted to do. An agent that can only read cannot write. An agent scoped to one MCP server cannot pivot to another. Least-privilege is not a new concept, but in this context it is the most direct control available, because it acts before any of the attack chains described above can complete.

Most deployments have not made this a deliberate architectural constraint. They have given the agent what it needed to be useful, which is understandable, and have deferred the scoping question, which is costly. The difference between an agent that can call three MCP servers and one that can call seven is not just a difference in capability. It is a difference in the blast radius of any compromise that reaches that agent.

A few other propagation controls are worth naming. The first is tool call confirmation for high-consequence operations: not for every action, because that defeats the purpose of automation, but for any action that is irreversible or that crosses a trust boundary. Write to external system. Send message. Delete record. These warrant a human confirmation step, and the latency cost is real but bounded.

The second is observability. The attack chains documented above are, in principle, reconstructible if you have complete tool call logs with parameters, timestamps, and triggering context. Without those logs, reconstruction is impossible. Observability does not prevent compromise; it is what allows you to detect and respond to it, and it is what makes post-incident learning possible rather than speculative, and producing those logs at the governance layer, rather than leaving them to individual tool implementations, is exactly the problem that products like MCPManager, Usercentrics' centralized layer for controlling, monitoring, and auditing how AI systems access business data via MCP, are built to address.

The third is that isolation between MCP servers within a single agent context limits the reach of tool shadowing and cross-server injection. If the agent's context for one server cannot be influenced by instructions arriving from another, the lateral movement described in the multi-server topology becomes significantly harder.

None of these controls are exotic. Least privilege, confirmations on high-stakes actions, comprehensive logging, inter-server context isolation: these are recognizable patterns from conventional security, adapted to a new execution model. The challenge is not that the mitigations are unknown. It is that the deployment pressure has been high, the tooling has been immature, and the instinct to restrict capability in a system you just paid to expand is a genuinely difficult organizational impulse to act on. The attack chains described throughout this piece are what happen in the space between "we deployed the agent" and "we scoped it properly." Closing that space is the work.