Defending Browser MCP Agents Against Prompt Injection on Untrusted Web Pages

How injection reaches a browser MCP agent

A browser agent reads page content as part of its task, and the model cannot reliably tell which text is data and which is instruction. OWASP's MCP Top 10 frames this as analogous to XSS or SQL injection: the model is the interpreter and the payload is text, including any content that becomes text after OCR or other processing. Hidden or visible instructions on a page, in a link, or in an image are all in scope.

Page content is only one path. Instructions can also arrive in tool return values, in poisoned tool descriptions and schemas, and in persistent memory that carries attacker instructions into later sessions. OWASP advises treating the entire tool schema as an injection surface, not only the description field. Its recent exploit roundup describes research in which a crafted link ran a prompt in the victim's authenticated session without separate confirmation.

The consequences matter more than the wording of the payload. OWASP lists data exfiltration through legitimate channels as a key risk: sensitive data encoded into ordinary-looking tool calls such as search queries or email subjects. MCP tools that fetch URLs from model-generated parameters can also be steered toward internal services such as cloud metadata endpoints. Other outcomes include form submissions and calls to privileged tools. Because prompt wording is not a security boundary, the defense has to constrain these consequences directly.

Implement input handling and tool permissions first

Start with an inventory. List every MCP server the browser agent can reach, every tool, and every schema field, since each is an injection surface. Then reduce access: give each task only the tools it needs, avoid wildcard or unrestricted tool access, and split tool sets so that a task reading untrusted pages does not also hold tools that move data out or change state.

On the browser side, use separate browsing profiles and limit the agent's access to sensitive signed-in sessions. An injected instruction can only act with the credentials the agent holds, so reducing those credentials reduces the damage.

For input handling, keep system instructions in a context separate from fetched content, and validate and sanitize tool outputs before they return to model context. Tool outputs can be reused as inputs to other tools, which can cause downstream SSRF or command injection if left unsanitized. Classifier-based screening of fetched pages can be added as one layer. Measure its false-positive rate, and remember that it does not stop an injection it fails to detect or content that arrives through other channels. Encoded and multilingual payloads can evade pattern-based filters.

• Inventory MCP servers, tools and schema fields as injection surfaces.
• Assign the minimum tool set per task and separate sets by trust level.
• Remove wildcard tool access and review scope on a schedule.
• Use separate browsing profiles and limit signed-in sessions.
• Sanitize tool outputs before they reach model context.
• Validate model-generated URL parameters against internal ranges.

Enforce policy on individual tool calls at runtime

Scoping decides which tools exist for a task. Runtime enforcement decides whether a specific call, with specific arguments, may proceed. OWASP's guidance is to enforce authorization in the execution component, outside the agent's context, because anything inside the context can be rewritten by an injected instruction.

A useful policy evaluates the tool and server, the arguments, the destination, the sensitivity of the data being sent, and whether untrusted content was in context when the call was made. Each call then gets one of five outcomes. Allow calls that match the task. Redact sensitive fields from parameters. Block calls to unapproved destinations or internal address ranges. Rate limit repeated calls that could leak data in small pieces. Escalate to a person when the action is high-impact or the context is untrusted.

Destination control is the most practical starting point for browser agents, along with approval of cross-site data transfers. Because exfiltration can be encoded into a normal-looking search query or email subject, narrow the allowed destinations and fields instead of trying to recognize malicious content. The tradeoff is operational: tight rules produce false blocks, so start in the highest-risk tools and tune from observed traffic.

Trussed enforces policy in the execution path across agents, tools and MCP servers, applying allow, redact, block, rate limit and escalate decisions to individual interactions and tool calls. It is enforced at runtime, not reviewed after the fact. It does not replace content separation, tool scoping or browser isolation, and it does not provide end-to-end tracing of agentic workflows.

Gate high-impact actions and retain evidence

Define action classes that always require human approval, such as sending data to a new destination, submitting a form, or calling a privileged MCP tool after reading external content. Anything outside an autonomous allowlist should wait for confirmation. Without review, an injected payload can act before anyone notices. Show the approver the proposed call and the untrusted content that preceded it, so the decision is informed rather than a reflex click.

Evidence should answer two questions: what was the agent allowed to do, and what did it do. For each tool call, retain the agent or task identity, the tool and MCP server, the parameters with sensitive values redacted, the policy decision and the rule that produced it, the approval outcome, a timestamp, and the provenance of the input that was in context. Exclude credentials, secrets and unnecessary sensitive prompt or response content from these records. Which fields to keep is a design decision for your team, so define it before an incident.

Where Trussed is deployed, enforcement itself produces continuous audit-ready evidence, with self-managed deployment in the customer cloud and configurable retention and data residency. That evidence covers the interactions and tool calls the policy touched.