# Cloudflare Browser Run can now hard-limit agent sessions to approved hostnames Cloudflare Browser Run now supports session-level hostname guardrails for Puppeteer, Playwright and CDP browser automation. Requests outside the allowlist are blocked with a deterministic 403, and the policy is fixed for the lifetime of the session. The useful change is containment rather than another browser-agent feature. Teams can let an agent operate a real browser while constraining its HTTP and HTTPS reach to the site and dependencies the task actually needs, reducing the blast radius of prompt injection, bad tool decisions or untrusted page content. - Status: Active - Published: 2026-09-15T19:20:33+12:00 - Updated: 2026-09-15T19:20:33+12:00 - Categories: Artificial Intelligence, Web Development, Cloud & Infrastructure, AI Agents, Cloud Platforms, Developer Tools - Tags: AI agents, Cloudflare, network security, sandboxing - Canonical HTML: https://beyondthe.news/dossiers/cloudflare-browser-run-hostname-guardrails-agent-network-allowlist ## What changed Cloudflare added Browser Run guardrails on September 14, 2026. A Puppeteer, Playwright or Chrome DevTools Protocol session can now be started with an `allowedDomains` list or reusable `allowedDomainSets`; HTTP and HTTPS requests to other hostnames are blocked for the lifetime of that session. Direct lists support up to 50 entries and domain sets up to four entries, including centrally hosted HTTPS lists. An empty allowlist blocks all outbound HTTP/HTTPS traffic. Blocked requests return HTTP 403 with Cloudflare-specific guardrail headers. The same release also adds read-only Live View links so observers can watch a session without clicking, typing, navigating or executing JavaScript. ## Why it matters Browser-using agents inherit the security surface of the web pages they visit: redirects, scripts, images and page instructions can all influence what the browser attempts next. A model prompt saying 'stay on this site' is not a network security boundary. Browser Run guardrails move that restriction into the execution environment itself. That gives builders a practical defense-in-depth control for research agents, QA systems, scraping workflows and any automation handling authenticated sessions or sensitive data. ## The allowlist is enforced by the browser runtime, not the prompt Developers declare allowed hostname patterns when the Browser Run session is created. Requests outside that set are blocked before the browser can use them, and Cloudflare returns a 403 tagged with `cf-mitigated: guardrails`. The policy cannot be relaxed mid-session; changes require starting a new session. ## Teams can use fixed lists or centrally maintained domain sets `allowedDomains` supports a short explicit list, while `allowedDomainSets` can reference reusable sets, including an HTTPS-hosted text file. Cloudflare also provides a maintained `common-cdns` set for common page dependencies. Hosted lists are cached for up to an hour and only affect sessions started after the refreshed list is loaded. ## A browser can be made completely network-isolated Passing an empty `allowedDomains` array blocks all HTTP and HTTPS requests. That is useful for rendering self-contained HTML into screenshots or PDFs without allowing the content to fetch scripts, tracking pixels, APIs or other external resources. ## Read-only Live View separates observation from control Browser Run can now issue a Live View URL in read-only mode. A viewer can watch the active session but cannot interact with the page or execute JavaScript. The viewing permission is separate from the session's hostname guardrails, which remain enforced. ## This is a different boundary from Chrome's Connection Allowlist BTN already tracks Chrome 152's `Connection-Allowlist`, which lets a website restrict its own browser-originated network destinations. Browser Run guardrails operate one layer higher: the automation operator sets the policy for a hosted browser session before an agent drives it. The two mechanisms address similar exfiltration risk from opposite sides of the browser trust boundary. ## Key details - Cloudflare announced Browser Run guardrails on September 14, 2026. - Guardrails apply to Puppeteer, Playwright and CDP sessions; Cloudflare says Quick Actions do not support them. - `allowedDomains` supports up to 50 hostname patterns. - `allowedDomainSets` supports up to four reusable lists. - If both are omitted, HTTP and HTTPS remain unrestricted. - An empty allowlist blocks all HTTP and HTTPS traffic. - The guardrail policy is fixed for the lifetime of the session. - A blocked hostname returns HTTP 403 with `cf-mitigated: guardrails` and a `not-in-allowlist` reason header. - Guardrails remain active while a session is viewed through Live View. - Live View now supports a read-only viewer mode. ## Builder takeaways - Treat hostname guardrails as a default containment control for browser agents that only need a bounded set of sites. - Include redirects, authentication endpoints, APIs, scripts, fonts and other legitimate dependencies in the allowlist or the workflow can fail unexpectedly. - Prefer `*.example.com` plus the apex domain over loose prefix patterns such as `*example.com`, which Cloudflare warns can match attacker-controlled lookalike domains. - Use an empty allowlist for self-contained HTML/PDF/screenshot jobs that should never touch the internet. - Keep high-risk business actions behind server-side authorization even with network guardrails; the allowlist restricts destinations, not what the agent may do inside an allowed site. - Use read-only Live View when humans need observability without giving every observer interactive browser control. ## What to watch - Whether Cloudflare adds path-, method- or port-level restrictions beyond hostname allowlisting. - Support for guardrails in Quick Actions, Kitesurf and other Browser Run surfaces. - Audit logs or per-request policy traces designed for agent incident review. - Whether other browser-agent runtimes adopt comparable runtime-enforced network policies. - Independent testing for redirect, DNS and browser-protocol edge cases around the allowlist. ## Uncertainties - Guardrails are currently marked Beta and their limits or integration support may change. - Hostname allowlisting constrains HTTP/HTTPS destinations but does not by itself define application-level permissions on an allowed domain. - Reusable domain sets can change over time, so security-sensitive workflows may prefer fixed explicit lists. - Cloudflare's documentation defines the intended enforcement model; broad independent bypass testing is not yet available. ## Sources - [Control which hostnames Browser Run sessions can access](https://developers.cloudflare.com/changelog/) — Cloudflare · primary changelog · 2026-09-14T00:00:00+12:00. Primary announcement for Browser Run hostname guardrails and read-only Live View. - [Guardrails](https://developers.cloudflare.com/browser-run/features/guardrails/) — Cloudflare Docs · primary documentation · 2026-09-14T00:00:00+12:00. Implementation details, limits, blocking behavior, domain sets and integration support.