How to Block Browser MCP Servers From Internal Admin Consoles and Cloud Metadata Endpoints

Map the attack paths first

A browser-capable MCP server loads and acts on URLs supplied through tool-call parameters. Those parameters are often generated by a model. Prompt injection can therefore steer a URL-fetching tool toward internal services, and the request leaves from the server's own network position, not the user's. The usual targets are internal admin consoles, loopback and private-range services, and cloud metadata endpoints, which expose credentials and access tokens on AWS, Azure and Google Cloud.

MCP raises the stakes. Servers commonly run with delegated user permissions and agents chain tool calls, so one successful fetch can feed the next step. Mapping the path means listing each hop: where the model's input originates, which tool turns it into a request, what network the server sits on, and which internal destinations that network can reach.

Network rules alone leave gaps because the request is not always the one you inspected. A public hostname can redirect to an internal address. A name can resolve to a public address at check time and an internal one at connection time, which is the DNS rebinding pattern. Addresses can be written in alternate encodings or as IPv6 equivalents, and a check that only handles IPv4-shaped strings can miss them. In a browser, page content can trigger further navigation and sub-requests after the first URL was approved. Each of these is a reason to enforce at more than one layer.

Design destination policy for MCP tool calls

URLs are hard to validate and parsers can be abused, so avoid passing a raw model-supplied URL to the request layer. Where possible, accept a host from an explicit allowlist and build the request yourself with a scheme, port and path your application fixes. Prefer an allowlist to a deny-list, and use the deny-list as a backstop for non-public addresses.

When a tool must fetch arbitrary public sites, the check has to run on the resolved address, not the string. Resolve the hostname and reject any address that is not globally reachable. Do not rely on IPv4-only string or CIDR matching. The same checks must apply to every redirect hop and to the address actually used for the connection, otherwise a validated name can still land on an internal host.

• 1. Normalize and parse once: Use a single parser to extract scheme, host and port, and reject unexpected schemes and ports.
• 2. Match the host to an allowlist: Permit named hosts for each tool. Route exceptions to review.
• 3. Resolve and test the address: Reject any address that is not globally reachable, covering IPv6 and alternate representations.
• 4. Block known internal names: Deny metadata.google.internal and 169.254.169.254 regardless of how they are written.
• 5. Re-check every redirect: Apply the same rules to each hop, or disable redirect following for the tool.
• 6. Connect to the validated address: Use the address you checked so a second DNS answer cannot change the destination.

Where runtime enforcement complements the network layer

Network controls decide whether a packet may leave a host. They do not see the tool call: which MCP server was invoked, with which parameters, on behalf of which agent. Browser-side navigation, redirect chains and unusual URL forms are easier to judge at the point where the tool call is made, because the full requested destination is still available there.

Trussed enforces policy at runtime in the execution path for MCP servers and tool calls, with actions to allow, redact, block, rate limit or escalate for human approval. For this use case, that lets a destination rule act on an individual call before it executes, for example blocking a request aimed at an internal admin console, redacting a secret from a response, or escalating a first-time destination to a reviewer. Enforcement is at runtime, not reviewed after the fact. The same policy can apply across multiple servers and tools. It sits alongside egress rules, host isolation and metadata hardening, and does not replace them.

There are tradeoffs. Allowlists need an owner and a change process. Human escalation adds latency, so reserve it for new or ambiguous destinations rather than routine ones. Any enforcement point you evaluate should show how it treats the resolved address, redirects, IPv6 and alternate encodings, because those are the cases that defeat simple string checks.