Feature request: safer defaults for local file, private network, and script evaluation access

[junbyjun1238]

Hi Chrome DevTools MCP team,

Could the project consider optional guardrails for chrome-devtools-mcp when it is used by local MCP clients that process untrusted content?

I am not reporting a Chrome sandbox bypass or a same-origin policy bypass. The concern is about the local trust boundary created when a client is granted browser automation capabilities through this server.

Summary

chrome-devtools-mcp exposes powerful browser automation primitives that can interact with local and internal boundaries, including:

• navigating to local file:// URLs
• accessing localhost, loopback, private-network, or link-local/metadata-style endpoints from the browser context
• executing JavaScript in the page context
• allowing browser-mediated outbound requests from evaluated scripts

These are expected browser and DevTools capabilities. However, in MCP client deployments, tool calls may be influenced by untrusted web content, documents, repository text, or other external content. In that setting, these capabilities can become surprising data-movement paths for local files, internal services, or browser-visible content.

Why this matters

In enterprise or developer environments, users may run MCP clients with broad local trust while browsing or analyzing untrusted content. If a client is induced to combine navigation, snapshotting, and script evaluation, sensitive data obtained from local or internal browser-accessible resources may leave the chat-visible path through normal browser network behavior.

Again, this is not a claim that Chrome itself is violating its security model. This is a request to consider safer MCP defaults and clearer controls around high-impact local browser capabilities.

Suggested guardrails

Would it make sense to consider one or more of the following?

• An opt-in flag for file:// navigation, such as --allow-file-scheme.
• An opt-in flag for localhost, loopback, private IP, and link-local/metadata IP access.
• An option to disable the evaluate_script tool entirely.
• Where feasible, stricter egress controls for local/internal navigations, such as CSP injection, request interception through CDP, or an equivalent policy.
• An allowlist/denylist policy configuration for URL schemes, hostnames, and IP ranges.
• Clear documentation warnings about local file access, internal network access, and blind egress risks when exposing this server to MCP clients that may process untrusted content.

Expected outcome

The goal is not to remove DevTools functionality. The goal is to make powerful local browser capabilities explicit and configurable for MCP deployments where users may not realize that browser automation can bridge local files, internal services, and outbound browser traffic.

Thanks for considering this.