Add policy to restrict browser agent tools to specific domains (independent of fetch tool)

[JoeCiervo]

Summary

Add a policy to restrict browser agent tools to specific domains, independent of the fetch tool.

Problem

Organizations need to balance developer productivity with security. Currently, the only way to restrict agents from
autonomously controlling public websites is to disable browser tools entirely via BrowserChatTools: false.
However, this also prevents legitimate local development use cases (e.g., testing a localhost app with an agent).

The alternative — using ChatAgentNetworkFilter with ChatAgentAllowedNetworkDomains: ["localhost"] — is too
broad: it also blocks the fetch tool from accessing external content, degrading general agent usefulness.

There is currently no policy that says: "agents may use browser tools, but only on localhost."

Proposed Solution

Add a new dedicated policy for browser tool domain restrictions, separate from the fetch tool:

• Policy name: BrowserChatToolsAllowedDomains
• Setting: workbench.browser.chatTools.allowedDomains
• Type: Array of domain patterns (wildcards supported)
• Example:

  ["localhost", "127.0.0.1", "*.internal.example.com"]
  
  
  

When set, agents can use browser tools (click, navigate, type, etc.) only on matching domains. The fetch tool
remains unaffected.

This complements BrowserChatTools (the on/off switch) with fine-grained domain control.

Expected Behavior

An organization sets:

BrowserChatTools: true
BrowserChatToolsAllowedDomains: ["localhost", "127.0.0.1"]

Result:

• ✅ Agents can control pages on localhost
• ❌ Agents cannot click/navigate/automate public websites
• ✅ Fetch tool continues to work on external URLs

Current Behavior

Only a binary on/off exists for browser tools (BrowserChatTools). Domain-scoped browser tool access is not possible
without also restricting the fetch tool via ChatAgentNetworkFilter, which is overly broad.

Additional Context

This feature would allow organizations that have disabled BrowserChatTools for security reasons to safely re-enable
it, scoped to internal/local development environments — unlocking productivity benefits without exposing a risk of
agents automating public websites.

[HyderYash]

Hi @JoeCiervo 👋

I’d like to work on implementing this policy.

My plan is to:
• Locate existing BrowserChatTools policy implementation
• Add a new setting workbench.browser.chatTools.allowedDomains
• Enforce domain checks in browser tool navigation/click handlers
• Add validation + documentation

Please let me know if this approach sounds good or if you’d like the implementation done in a specific way.

Thanks!

[kycutler]

Hi @JoeCiervo, thanks for opening this request. I'd like to understand the use case better.

Usually when an agent is unable to perform a task in one way, it will just find a different way -- e.g. if it can't use the built-in browser tools, it might try invoking Playwright or curl via the terminal. So we also want those to have the same restrictions.

This is why we currently have the unified chat.agent.networkFilter setting -- so all tools can follow the same logic without needing separate lists for each.

So I'm curious what your use case is for the fetch tool to behave differently. Could you elaborate?