Cloudflare Built a Browser That Forgets: Why Agent Browsing Just Became Its Own Control Boundary

On 6 August 2026 Cloudflare launched Kitesurf, a web browser built for AI agents rather than people, and made it available free in beta through Browser Run subject to per account limits. It does not use Chromium. It runs entirely in V8 isolates on Cloudflare Workers, assembled from a Rust rendering engine called Blitz, the Stylo CSS parser that Firefox uses, and the Boa JavaScript engine. Cloudflare says it was built in twelve weeks and already passes more than 215,000 Web Platform Tests, with hundreds more added each week. The published benchmarks are specific: a screenshot task consumed 380 milliseconds of CPU against 1,173 for Chromium, HTML extraction 229 against 877, and memory came in at 57.8 MiB against 271.0 for screenshots and 39.4 MiB against 273.7 for extraction. That is between 3.1 and 3.8 times less CPU and between 4.7 and 7 times less memory.

The efficiency numbers are what most coverage led with, and they are a real result, but they are not the interesting part for anyone responsible for security or compliance. A browser designed for agents drops the things agents never look at, which is themes, tabs, extensions and most of the visual chrome, and keeps HTML, DOM, CSS, SVG and network requests. Once you remove the human, you are no longer shipping a general purpose application to a laptop. You are running a rendering service, and a rendering service is something you can put a policy in front of. The architecture reflects that directly: a component Cloudflare calls SandboxOutbound sits in the request path and enforces network behaviour including CORS and cookie handling, which means the egress decision is made by infrastructure rather than by whatever the page persuaded the agent to do.

The design assumptions are stated plainly and they are worth quoting back to your own architecture. Every page load is treated as untrusted input. Every session starts fresh. Each component receives only the network access it needs for the task in front of it. Compare that with how agent browsing usually happens today, which is a browser extension or a desktop automation tool operating inside a logged in profile that belongs to a named employee, carrying their cookies, their saved credentials and their standing authorisations into every page the agent visits. We wrote earlier this month about browser agents inheriting a human session, and the point stands: the failure is not that the agent is careless, it is that the agent was handed an identity it was never supposed to have. A stateless browser removes that inheritance by construction.

It is worth being equally clear about what this thing cannot do, because the limitations are not incidental, they are the direct consequence of the design. Kitesurf does not support video or WebGL. It cannot complete bot challenges that depend on a real TLS fingerprint. And it does not support long lived authenticated stateful sessions, which is precisely the workload most people have in mind when they imagine an agent doing useful work on the web. It is also slower in wall clock terms, roughly 1.7 to 1.8 times, mostly on rasterisation and image encoding. So the honest reading is that this is very good at reading the public web at volume, and it is not yet a replacement for an agent that logs into a supplier portal on your behalf. Anyone promising the latter is selling something else.

That constraint actually points at the right operating model rather than away from it, and it is a model worth adopting whether or not you use this particular product. Split agent work into two lanes. Untrusted public browsing, which is research, scraping, monitoring, price checks and reading documentation, goes through a hosted agent browser with no credentials, no persistent state and an allowlisted set of destinations. Authenticated work against systems that matter goes through an API with a scoped service credential that has a short lifetime and a named owner, not through a browser holding a human session. Most of the incidents we have looked at this year sit in the space where those two lanes were collapsed into one, and a tool that physically cannot hold a session forces the separation you should have made anyway.

For assurance work the practical gain is evidence. A server side agent browser produces logs in a place your organisation controls, so you can answer the questions an assessor asks: which destinations did this agent reach, what did it send, when, and under whose authority. An agent driving Chrome on a laptop produces almost nothing you can hand to anyone. ISO 27001 already gives you the relevant controls in network security, logging and access management, and ISO 42001 adds the obligation to know which AI systems you run, what they do and who owns them. Continuous compliance platforms such as Vanta, Drata, Secureframe and Sprinto will confirm that your policies exist and your access reviews ran, and none of them can tell an auditor what your agent fetched last Tuesday unless you built that telemetry and pointed it somewhere durable.

There is a vendor concentration point that should not be skipped, because adopting a hosted agent browser is a supplier decision and not just a technical one. If your agents browse through Cloudflare, then every page they visit, every cookie handled and everything rendered on their behalf passes through Cloudflare infrastructure. That makes it a subprocessor, which puts it on your vendor register, in your data processing agreements and potentially on the subprocessor list you publish to customers. The controls in ISO 27001 covering supplier relationships and change monitoring apply, as does the equivalent expectation in the SOC 2 common criteria. Ask the residency question early, because a serverless network that runs your workload wherever it is cheapest is exactly where a promise about where customer data gets processed quietly stops being true. There is a further wrinkle worth naming: the same company sells the bot detection that blocks unwanted automation and the browser that performs wanted automation, and how those two products treat each other is a commercial question as much as a technical one.

The compatibility story is the reason this is likely to spread faster than a new engine normally would. Kitesurf speaks the Chrome DevTools Protocol, so it works with Puppeteer, Playwright, chrome-remote-interface and MCP clients, selected with a parameter rather than a rewrite. A team already running browser automation can point existing scripts at it and compare results in an afternoon. That low switching cost is also the governance risk, because it means the change can happen inside a repository without anyone opening a ticket, in exactly the way that MCP servers and model gateways arrived in most organisations. If your change management process only notices new suppliers when someone raises a purchase order, a free beta that requires a one line configuration change will not register at all.

Our recommendation this month is a short exercise rather than a procurement decision. List every agent and automation in your business that fetches web pages, including the ones embedded in developer tooling such as Cursor, Claude Code and Copilot agents, and the MCP servers wired into them. For each, write down whether it browses inside a human session or a dedicated one, which credentials travel with it, where its request log ends up, and who owns it by name. Then take the two or three that touch the public web most heavily and ask whether they need a session at all. If the answer is no, move them to a stateless hosted browser with an allowlist and keep the logs. If the answer is yes, that is the workload deserving your attention, because a credential riding along with an agent through arbitrary web pages is the exposure worth fixing before an ISO 42001 assessment or a SOC 2 examination finds it for you.