Restricting Outbound Network Access for a Browser Automation MCP Server

Define the egress threat model first

A browser automation MCP server gives an AI agent a real or headless browser that can reach whatever the host network allows. The agent does not need to be compromised for this to matter. Page content is untrusted input, and indirect prompt injection, where a model acts on instructions embedded in data it reads, is a recognized risk for agents that interact with adversarial content. A January 2026 federal request for information on AI agent security lists it among inference-time risks and names network access permissions and approvals among the controls to consider. That document is a request for information, not binding guidance.

For this server, three outbound paths deserve explicit treatment. The first is injection-driven navigation, where a page or an over-permissive tool call steers the browser to a destination the operator never intended. The second is server-side request forgery against loopback, the container network, internal services and cloud metadata endpoints. The third is exfiltration through browser-initiated requests, such as data placed in a URL, a form post or a subresource fetch to an attacker-controlled host.

Write these down with the assets at risk: instance credentials reachable through metadata, internal APIs, and any data present in the browser session. The threat model then tells you which destinations must never be reachable and which few must be.

Build the default-deny allowlist

Deny-by-default means the firewall blocks all outbound traffic not expressly permitted, which NIST firewall guidance describes as more secure than permitting everything not explicitly forbidden. Apply that rule to the browser workload and add destinations deliberately.

Start in reporting-only mode. Zero trust guidance supports running new policy in a reporting mode for a period to establish baseline access patterns and confirm the policy is workable. Use that period to learn which hosts the legitimate tasks need, then enforce.

• 1. Isolate the browser: Run it in a dedicated namespace, subnet or VM with its own egress rules, separate from other workloads.
• 2. Baseline in reporting mode: Record destinations contacted during representative tasks, including subresource hosts.
• 3. Deny all egress: Permit only the proxy and approved resolver. No direct internet route from the browser.
• 4. Allowlist at the proxy: Add exact hostnames the tasks require. Treat each wildcard as a decision to trust every name under it.
• 5. Block internal ranges: Deny loopback, link-local metadata addresses, private ranges and the container network from the browser process.
• 6. Enforce and assign ownership: Switch from reporting to blocking, and name an owner and review process for allowlist changes.

Handle redirects, subresources and internal addresses

Redirects are the best-documented bypass. CVE-2026-54018 describes an application where Playwright follows HTTP 301 and 302 redirects by default. An attacker supplied a safe-looking URL that redirected to localhost, the Docker container network or cloud metadata, and this defeated URL validation even with a local-fetch setting disabled. The practical lesson is that checking the first URL is not enough. Validate the final destination and every hop, and enforce the same rule at the network layer so a validation gap in application code does not become an open path.

Subresources need the same attention. A page can load images, scripts, frames and beacons from other hosts, and each is an outbound request the browser makes on its own. An allowlist that covers only the navigation target will either break pages or, if loosened to compensate, permit exfiltration channels. Use the reporting-mode baseline to decide which subresource hosts are necessary, and block the rest at the proxy.

For internal ranges, do not rely on string checks of the hostname. Names can resolve to private addresses, so evaluate the resolved IP at connection time, cover IPv6 as well as IPv4, and keep the network-layer deny rules for loopback, private and metadata addresses independent of the proxy. Do not treat the internal network as a trust zone. Least-privilege, per-request, context-based access decisions are the better model.

Add request-level policy on MCP tool calls

Network controls answer where the server may connect. They do not answer whether a particular navigation, form submission or data transfer is appropriate for the task the agent was given. Layer 3 rules cannot express tool-call intent, and zero trust guidance calls for per-request, context-based decisions on top of network segmentation. The RFI similarly lists data or tool restrictions, continuous monitoring, and approvals for consequential actions as agent-level controls.

Trussed addresses this layer. It enforces policy in the execution path of MCP tool calls and other agent interactions, with the actions allow, redact, block, rate limit and escalate for human approval. Enforcement happens at runtime, not after the fact, and it generates audit-ready evidence of what was permitted and what was stopped. It can be self-managed in the customer cloud, with configurable retention and data residency. It sits alongside the proxy, DNS and firewall layers described here and does not replace them.

Whichever mechanism you use, apply the same discipline. Define which tool parameters, such as target URLs, are acceptable, decide which cases need human approval, and keep the decisions as evidence next to your network records.