Blocking File Uploads and Downloads Through a Browser Automation MCP Server

How upload and download paths are exposed

A browser automation MCP server gives an AI agent the same capabilities a user has in a real browser: navigating, clicking, typing, submitting forms and following links. Depending on the server, those capabilities can include attaching a local file to a file input, responding to a file chooser, or triggering a download. Each one is a transfer path between the host and the web.

The upload risk is data disclosure. Agents may pass sensitive data such as credentials, file contents or environment variables as tool arguments without any awareness of data classification. An agent that can both read files and make network requests is a much larger problem than one that can only return text. The download risk runs the other way: an untrusted file lands on the host that runs the browser. OWASP guidance on browser agents also notes that exposed file-transfer helpers undermined the boundary between agent tools and the host.

Prompt injection is the usual trigger. Fetched web pages and tool responses become instructions once the agent reads them, so a page can ask the agent to upload a file or fetch a payload. A system prompt that says "do not upload files" is enforced only by the model's instruction-following, not by any backend control. Restrictions have to sit outside the model.

Blocking layers and where each one falls short

Each layer removes a different part of the path, and each has a gap that another layer has to cover. Treat the list below as a stack, not a menu.

• Tool configuration: Blocks: omit or disable file-related tools, and allow only approved servers and tools. Limits: tool definitions can change after approval, and a different tool, such as one that runs scripts in the page, may reach the same outcome. Check the server's own documentation for its file-related tools and startup options.
• Browser and profile settings: Blocks: denied or redirected downloads, restricted file-chooser handling, and a dedicated profile with no signed-in sensitive sessions. Limits: available settings differ by browser and version, and they do not stop sensitive text typed into a form field.
• Filesystem and container isolation: Blocks: access outside required directories and to credential stores. Limits: files inside permitted directories remain reachable, and any writable directory can receive a download.
• Network egress restrictions: Blocks: outbound traffic when the task does not need it, or traffic to unapproved destinations. Limits: a browsing agent needs some web access, and an allowed destination may still accept uploads.
• Tool-call policy enforcement: Blocks: calls that match file-transfer rules, before they execute. Limits: it governs only traffic routed through it, and page behavior that involves no tool call is outside its view.

Enforcing policy in the tool-call path

Configuration reduces the available surface. Policy enforcement decides what happens when an agent still attempts a transfer. An MCP proxy or gateway sits between the agent and the server, evaluates each call, and returns an allow, redact or block decision before the browser acts.

Rules can key on the tool name, the arguments and the target. Examples include a file-upload tool, a file path outside an approved directory, or a destination domain that is not on the allowlist. Treat arguments as untrusted input, especially file paths. Do not rely on a tool's own read/write annotation to judge risk, since annotations are untrusted unless they come from a trusted server. Re-validate rules when a tool definition or description changes, because name-based rules can silently stop matching.

Every blocked attempt should produce a durable record. Useful fields are the rule ID, the target tool and server, the request identifier, the decision and a timestamp. Keep raw file contents and sensitive values out of the record so the evidence does not become a second exposure. A detection category or rule ID is enough to support triage.

Trussed enforces policy in the execution path across agents, tools and MCP servers, with allow, redact, block, rate limit and escalation for human approval, applied to individual tool calls. Enforcement is at runtime, not reviewed after the fact, and it generates audit-ready evidence of what was attempted and what was blocked. It can be deployed self-managed in the customer cloud, with configurable retention and data residency.

Governance and operating decisions

Treat adding or changing a browser MCP server as a controlled dependency change with review, and require re-approval when tool definitions change. Disallow auto-discovery or connections to arbitrary servers. Keep high-privilege tools, such as file access and internal APIs, away from agent contexts that connect to external or untrusted servers.

Require approval for cross-site data transfers, and reduce browser-agent access to signed-in services to the task minimum. Decide in advance which exceptions are legitimate, who approves them, and how long the approval lasts.

The main tradeoff is usability. Tight download and egress limits can break legitimate workflows, so start from the narrowest task definition and widen it by explicit rule. Retain the blocked-attempt records for the period your investigation and audit processes require. For a regulated enterprise, those records show what the agent was allowed to do and what it actually did.