Domain Allowlist
The domain allowlist restricts browser navigation and network requests to a set of trusted domains, preventing AI agents from navigating to unexpected sites or exfiltrating data.Quick Start
How It Works
When enabled, the domain allowlist blocks:- Document navigation - Prevents navigating to non-allowed domains
- Sub-resource requests - Blocks scripts, images, stylesheets, fetch/XHR to non-allowed domains
- WebSocket connections - Prevents WebSocket connections to non-allowed domains
- EventSource connections - Blocks Server-Sent Events to non-allowed domains
- navigator.sendBeacon - Prevents beacon requests to non-allowed domains
blockedbyclient error.
Domain Pattern Syntax
Exact Match
https://example.comhttp://example.com
https://www.example.comhttps://api.example.comhttps://other.com
Wildcard Subdomains
https://app.example.comhttps://api.example.comhttps://cdn.example.comhttps://example.com(bare domain also matches)
https://other.com
*.example.com automatically match the bare domain example.com for convenience.
Multiple Domains
https://example.comhttps://api.example.comhttps://images.cdn.nethttps://assets.cdn.net
https://other.com
Special URLs
Data and Blob URLs
Data URIs and blob URLs are handled specially:- Sub-resources: Allowed (images, scripts from data: or blob: URLs)
- Navigation: Blocked (cannot navigate to data: or blob: URLs)
data: URL navigation while allowing legitimate use of data URIs for images, etc.
About: and Chrome: URLs
Internal browser URLs (about:, chrome:, chrome-extension:) are blocked.
Implementation Details
Route-based Filtering
Domain filtering is implemented via Playwright’s route interception at the browser context level:JavaScript Monkey-patching
WebSocket, EventSource, and navigator.sendBeacon are patched via an init script to enforce domain allowlist at the JavaScript API level:Security Note
This JavaScript monkey-patching is a best-effort defense. If page scripts can useeval(), they could theoretically restore the original WebSocket/EventSource implementations. To close this loophole, deny the eval action category in your action policy:
Common Patterns
Single Domain Application
Multi-Domain Application with CDN
Development Environment
Best Practices
1. Include CDN Domains
Many applications load resources from CDNs. Include CDN domains in the allowlist:2. Use Wildcards for Subdomains
Instead of listing all subdomains:3. Test Before Deploying
Test the domain allowlist in headed mode to identify missing domains:4. Combine with Action Policy
For maximum security, combine domain allowlist with action policy:policy.json:
Configuration File
Set domain allowlist inagent-browser.json:
- CLI flag
--allowed-domains - Environment variable
AGENT_BROWSER_ALLOWED_DOMAINS - Config file
allowedDomains
Environment Variables
| Variable | Description | Example |
|---|---|---|
AGENT_BROWSER_ALLOWED_DOMAINS | Comma-separated list of allowed domain patterns | example.com,*.cdn.example.com |
Programmatic API
Install domain filter programmatically:Helper Functions
Troubleshooting
Page fails to load resources
Symptom: Page loads but images, styles, or scripts are missing. Solution: Check network requests to identify blocked domains:WebSocket connection blocked
Symptom: Error in console:WebSocket connection to wss://... blocked by domain allowlist
Solution: Add the WebSocket server domain to allowlist:
Navigation blocked
Symptom: Cannot navigate to a new page after initial load. Solution: The target domain is not in the allowlist. Add it:See Also
- Security Overview - All security features
- Action Policies - Action gating
- Auth Vault - Credential storage