Preventing Browser MCP Screenshots and Page Snapshots from Capturing Sensitive Data

How screenshots and snapshots expose sensitive data

A browser-automation MCP server lets an agent look at a page. It does this by returning either an image of what is rendered or structured content such as the DOM or accessibility tree. In an authenticated session, that can include credentials, personal data, session tokens, financial or health records and anything else the signed-in user can see. The tool call is legitimate, the server may be approved, and the result still carries data that was never meant to leave the browser.

The exposure does not end at the model call. OWASP describes MCP context as working memory that holds prompts, retrieved data and intermediate outputs. When that context is shared, persistent or insufficiently scoped, sensitive information from one task, user or agent can reach another. Secrets can also end up in protocol logs and debug traces. Returned data can then be re-emitted through ordinary-looking tool calls, for example after a prompt injection encodes it into a search query, or passed as an argument to a different server with no regard for its data classification.

For these reasons, screenshot and snapshot capture is best handled as a data-exposure path in the tool-call lifecycle, not as a model-behavior problem. OWASP guidance is to treat every tool response as untrusted data, including responses from approved servers. Instructions in a prompt telling the agent to avoid sensitive pages do not change what the capture tool returns, and an injected instruction can override them. Controls belong where the data is produced and where it is returned.

Implement the layers in order

Start with separation. OWASP recommends keeping sensitive servers (payment, auth, PII) apart from general-purpose ones. Apply the same reasoning here: a browser server that touches authenticated pages should not share a runtime, credentials or context with unrelated tools.

Next, shrink what can be captured. Run the agent in a dedicated browser profile that starts empty and is discarded after the task, so saved logins and cookies from a human profile are not present. Allow only the origins the task requires. Where your tooling offers element masking, apply it to fields you can identify in advance, and treat the list as a baseline that you maintain.

Then reduce the tool surface. Grant each tool only the data and operations it needs, and enforce permissions and parameters at the tool boundary. Disable screenshot capture where text snapshots are enough, or the reverse. Do not rely on a tool's read or write annotation to describe risk. Clients should treat annotations as untrusted unless they come from trusted servers, and a read-only snapshot can still be a sensitive read.

Finally, enforce policy on the result. This is the only layer that sees what was actually captured, so it covers pages and fields the earlier layers did not anticipate.

• Separate browser servers that reach authenticated pages from general-purpose servers.
• Use isolated or ephemeral profiles and an origin allowlist per task.
• Mask or exclude known sensitive elements before capture.
• Expose only the capture tools the task needs, with permissions enforced at the tool boundary.
• Require human confirmation for operations whose effects include sensitive reads.
• Enforce allow, redact or block policy on every screenshot and snapshot result.

Enforcing redact or block policy on results at runtime

Image and text results need different handling. A text snapshot can be scanned for patterns such as credentials, tokens and personal identifiers, and matches can be replaced before the result is returned. An image has no text to scan until its content is interpreted, so detection is harder, and a redacted region has to be altered in the image itself. In both cases detection can miss content. Where a screenshot of a sensitive origin cannot be reliably cleaned, blocking the result is a safer outcome than passing a partial redaction. Policy can express this per tool and per origin: allow a snapshot from a public documentation site, redact one from an internal tool, block any capture from a payment or health portal.

Enforcement has to hold when the client is bypassed or a prompt is injected. That means it sits in the execution path between the MCP server and the model, not in client settings or system prompts. Trussed enforces policy in the execution path on MCP servers and tool calls, with allow, redact, block, rate limit and escalation for human approval, applied to individual interactions and tool calls. Enforcement is at runtime, not reviewed after the fact, so a result is acted on before it enters context.

Some limits remain. Screening does not stop an injection it fails to detect, and a captured value can reach other channels. Keep least privilege and tool scoping in place, and watch for cross-server flows, such as credentials captured from one server appearing in calls to another.