A Headless Browser Sandbox for AI Agents That Click Through Websites

Browser agents should not drive a browser on the machine that runs your app. CreateOS Sandbox gives every session its own Firecracker microVM with headless Chromium exposed over a DevTools port, egress rules enforced in the host kernel, and pause, resume, and fork for long or parallel click-throughs. Start free with 500 credits.

Introduction

An agent that clicks through websites runs two kinds of untrusted code at once. The pages it renders were written by strangers. The click loop itself was usually written by a model. Run both on the box that serves your customers, and one malicious page or one hallucinated loop becomes your incident.

The fix is mechanical. Give each browsing session its own machine. Control what it can reach. Make idle sessions cheap to keep around. That is the job CreateOS Sandbox does: your agent harness writes the clicks, and the sandbox is the computer they run on.

Key Takeaways

Every browsing session gets a Firecracker microVM with its own guest kernel, not a shared container. The blast radius of a bad page ends at the machine boundary.
Headless Chromium comes with a DevTools port on a public URL, so any client that speaks the Chrome DevTools Protocol connects with no extra plumbing.
Outbound access is open until you set an egress rule. Once set, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest.
Pause takes about 1.4 s and stops the meter; resume restores the exact machine. Fork branches a paused session for parallel attempts.
Billing is per second, egress is $0, and new accounts start with 500 free credits.

Why a Browser Agent Needs Its Own MicroVM

A browser is the most exposed process you will ever run. It renders content you do not control and holds the cookies, sessions, and credentials your agent types into forms. A container puts that process on a kernel shared with everything else on the host.

CreateOS Sandbox runs each session as a Firecracker microVM with its own guest kernel. The boundary is the machine, not a namespace. If a page exploits the browser, the blast radius ends at the VM edge. Our post on AI agent security and sandbox escape covers the threat model in depth.

The same boundary makes multi-agent setups sane. Attach sandboxes to a private overlay network and your agents find each other by name over private DNS, with no public exposure. Traffic between networks is denied by default.

What the Sandbox Gives an Agent That Clicks Through Websites

A browser you can drive from anywhere. Every sandbox can run headless Chromium with a DevTools port on a public URL. Point Playwright, Puppeteer, or your own CDP client at it and start clicking. Anything else running gets a live web URL, and a graphical desktop with screenshots and clipboard covers the cases where the agent needs to see the page rather than parse it.

Egress you set once and can trust. Outbound access is open until you set at least one rule. Once set, everything else is denied. Rules take a host, host:port, wildcard subdomains, IPs and CIDRs, plus domain rules through a transparent proxy. Set them in the egress field at create time, apply them live through the API with no restart, or use the SDK's setEgress method or the CLI. Enforcement sits in the host kernel with eBPF, outside the VM, so code inside cannot rewrite or route around it. It survives a full guest compromise.

Sessions that outlive a coffee break. Many click-throughs stall on a person: a login code, an approval. Pause writes a snapshot of the full machine in about 1.4 s and stops compute billing. Resume brings back that exact machine, working state included: under 0.7 s on the same host, 11 to 13 s cold on a different one. Those are idle-host figures, not an SLA. Auto-resume triggers on ingress HTTP, and idle timeout auto-pause is configurable.

Parallel attempts without parallel cost. Fork a paused sandbox and the agent's memory and working state branch with it. Run N ways through a checkout flow or a long form, keep the winner, throw away the rest.

Right-sized machines. Shapes run from a quarter CPU up to 8 CPUs with 16 GB of RAM and 10 to 60 GB of disk. Bring your own Dockerfile to pin the browser build your agent expects, and use two-way file sync to pull screenshots and artifacts out.

The Numbers Behind It

Scale first: 2.6 million sandboxes have been created since June 2026. CreateOS's own CI has run on sandboxes since July 2026. That is the proof we point to first: the runtime carries our own builds every day. Uptime is 99%+. Underneath, NodeOps, the infrastructure company behind CreateOS, has been operating production infrastructure since December 2023.

Speed claims come with their qualifiers attached. Creation is measured in tens of milliseconds, about 30 ms on an idle host, and an idle host is not an SLA. Pause is about 1.4 s. Same-host resume is under 0.7 s. Cross-host cold start is 11 to 13 s.

One more thing, stated plainly: this is a young product. Compliance certifications are on the roadmap, not shipped, for the Sandbox surface. What is proven today is the isolation architecture, the egress enforcement, and the CI that runs on it daily.

What to Weigh Before You Commit

Egress is not locked down by default. Outbound is open until you set a rule. If your agent should only touch three domains, set those three rules at create time or live through the API. Inbound is closed regardless.
No GPUs. Headless rendering is CPU work and the shapes cover it, but GPU-accelerated rendering is not on the menu. If you need it, this is not your tool.
Cold starts and resumes have real costs. Cross-host cold start is 11 to 13 s, and the first request after a pause waits for the resume. Set the idle window longer if that matters to you.
Where the machine lives. Sandboxes run in the CreateOS cloud, your cloud, or your own VPC, on the same API. Relevant when click-throughs handle logged-in accounts that must stay inside your boundary.
It is built for code you cannot trust. If your team only ever runs code it wrote and reviewed itself, you do not need a per-session microVM, and this will be the wrong shape of tool.

Frequently Asked Questions

Can my agent drive the browser with Playwright or Puppeteer?

Yes. Each sandbox can run headless Chromium with a DevTools port on a public URL, so anything that speaks the Chrome DevTools Protocol can connect. The SDK is @nodeops-createos/sandbox on npm and the CLI is createos sandbox. Both are covered in the docs.

Is outbound network access restricted by default?

No. Outbound is open until you set at least one egress rule. Once set, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest. Inbound is closed by default no matter what your egress rules say.

What happens when a session waits hours for a human?

Pause writes a snapshot of the full machine in about 1.4 s and stops compute billing. Resume restores that exact machine: under 0.7 s on the same host, 11 to 13 s cold on a different host. Idle timeout auto-pause is configurable, and auto-resume triggers on ingress HTTP.

What does it cost to try this?

New accounts start with 500 free credits. Billing is per second, egress is $0, and pausing stops the meter. Shapes run from a quarter CPU up to 8 CPUs with 16 GB of RAM and 10 to 60 GB of disk. Current numbers are on the Sandbox pricing page.

Conclusion

A browser agent is only as contained as the machine it clicks from. CreateOS Sandbox gives every session a Firecracker microVM with its own guest kernel, a headless Chromium your harness can drive over CDP, egress rules enforced where the agent cannot touch them, and pause, resume, and fork so long and parallel click-throughs stay cheap.

Set one egress allowlist, point your click loop at the DevTools port, and let idle sessions pause themselves. Create your first browser sandbox free with 500 credits at createos.sh/products/sandbox.

About CreateOS

CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.