The Browser Is the Sandbox: AI Agents Without Containers

The pitch: we already have the best sandbox… and we ignore it

If you’ve ever tried running a “local agent” (containers, VMs, heavy runtimes), you know the tradeoff: gigabytes to download, messy permissions, a bigger attack surface, and lots of friction.

Now consider this: the most battle-tested sandbox in computing history is already installed on your customers’ machines.

That’s the idea behind “The browser is the sandbox”, highlighted by Simon Willison based on notes from Google’s Paul Kinlan. For ~30 years, browsers have been engineered to run hostile, untrusted code from anywhere on the internet—instantly—while limiting the damage.

The twist: those same capabilities are exactly what AI agents need to safely read files, call APIs, and execute code—without turning every laptop into a security incident.

In this article we’ll cover:

why the browser is a ready-made sandbox for agents
the three pillars (filesystem, network, safe execution) and how the web addresses them
what Kinlan’s Co-do demo proves
practical use cases for founders and SMBs
real limitations (no hype) and how to design around them

Primary source: Simon Willison (Jan 25, 2026) summarizing Kinlan’s research. We’ll also reference recent signals on browser isolation (Cloudflare, Firefox, V8 research).

Why this matters for founders and SMBs

A useful AI agent isn’t a chatbot. It’s a system that:

reads your files (docs, contracts, CSVs, code)
calls APIs (CRM, invoicing, email, Slack)
executes code (parse, transform, generate)

The moment you grant those powers, you need a sandbox. Otherwise you risk:

leaking API keys
reading too many files
generated code doing unsafe things
data exfiltration over the network

Big companies solve this with heavy isolation: containers, VMs, RBAC, EDR… fine if you’re a bank.

You want something that works, ships fast, and doesn’t require a $30k “security consulting” engagement just to run a pilot.

The browser: a sandbox built to run hostile code

Modern browsers ship with:

origin-based security (same-origin policy)
explicit permissions
process isolation
intentionally limited OS access

And they keep hardening. For example, Firefox recently pushed its Windows Content Process Sandbox to level 9 and GPU sandboxing to level 2 (community reporting, early 2026), tightening access to sensitive system APIs.

On the enterprise side, Cloudflare’s CEO Matthew Prince famously framed the browser as a CISO nightmare because it constantly downloads and runs foreign code (Wired, via Cloudflare). The industry response is Remote Browser Isolation (RBI)—and the market is growing fast. One report estimates $0.59B (2024) → $5.35B (2032) with ~31.75% CAGR (Datam Intelligence via Business Herald). Treat market reports cautiously, but the direction is obvious: browser isolation is becoming a core security primitive.

The three pillars of an agent sandbox (and how the web handles them)

Kinlan breaks the sandbox problem into three parts: filesystem, network, and safe code execution. That maps perfectly to what an “operational” agent needs.

1) Filesystem access: just enough, not too much

Two practical browser approaches:

File System Access API: richer read/write access, but still largely Chrome-centric.
`<input type="file" webkitdirectory>`: lets users select an entire folder and grants the browser read-only access to it. Crucially, Willison notes it works across Firefox, Safari, and Chrome.

Practical implication: for many “agent over your documents” workflows, read-only is enough—and safer.

Examples:

analyze a folder of invoices and produce a report
scan a code repo and generate documentation
parse a directory of contracts and extract clauses

2) Network access: allow only what you mean

Network is the #1 exfiltration vector. If your agent can call any domain, it can send data anywhere.

Useful web primitives:

Content Security Policy (CSP): explicitly whitelist allowed domains (LLM provider, your API, etc.).
`<iframe sandbox>`: run the agent UI/runtime inside a restricted iframe.

The real-world detail: <iframe sandbox> is under-documented and behavior can vary. Kinlan’s notes (as summarized by Willison) include a double-iframe technique to apply strict network rules to the inner frame—exactly the kind of engineering detail that turns a demo into something shippable.

3) Safe execution: WASM + Web Workers

Even with file and network restrictions, you don’t want agent-generated code to:

freeze the UI
access unintended APIs
exploit a JS engine vulnerability

A practical pattern is WebAssembly (WASM) running inside Web Workers:

Workers isolate and keep the UI responsive
WASM offers performance and a more controlled execution surface

But “controlled” isn’t “unbreakable.” A recent academic analysis mentions finding 19 V8 bugs that could bypass isolation mechanisms (arXiv, 2025). Browsers are strong sandboxes—just not magical.

Co-do: a proof-by-demo (files + LLM + sandbox)

Kinlan’s Co-do demo tests whether you can build a Cowork-like experience in the browser:

user selects a folder of files
user configures an LLM provider + API key
the app provides chat + tools to interact with those files
network calls are constrained via CSP-approved endpoints

Willison’s takeaway: it feels similar to Claude Cowork—without shipping a multi-GB local container.

For SMB automation, that’s a big deal: you can deliver “agent over the customer’s files” via a URL, with reasonable sandboxing and almost zero onboarding.

Practical use cases you can ship

1) A “monthly close agent” in the browser

Input: folder 2025-12/ with invoices, Stripe exports, bank statements
Action: categorize, detect anomalies, prep entries
Output: clean CSV + summary report

Why browser: read-only folder access via webkitdirectory, no install, CSP locks down outbound calls.

2) A support QA agent for a solo SaaS

Input: exported tickets in support_tickets/
Action: cluster issues, propose FAQ, draft replies
Output: markdown ready to publish

Bonus: run parsers in WASM inside a Worker.

3) A contract audit agent for SMBs

Input: contracts folder
Action: extract key clauses (term, termination, indexation), flag risks
Output: table + executive summary

Key point: files stay on the machine. You don’t have to upload everything; you can send only the minimal excerpts needed.

The limitations (and how to design around them)

Limitation 1: APIs aren’t uniform

File System Access API is still Chrome-heavy.
<iframe sandbox> is poorly documented and varies.

Strategy: start with the portable baseline (webkitdirectory read-only) and add write features as optional enhancements.

Limitation 2: the browser sandbox isn’t invincible

Vulnerabilities exist (JS engine, GPU, etc.). Browsers keep hardening (Firefox level 9, etc.), but zero risk doesn’t exist.

Strategy:

least privilege (minimal files, minimal network)
no long-lived secrets in the client
rotate keys + scope API permissions
server-side logging for allowed outbound calls

Limitation 3: LLM economics and keys in the client

If you put an LLM API key in the browser, you must handle:

potential key leakage
abuse and quota blowups

Strategy: use a server proxy with short-lived tokens and per-session quotas, or rely on user-owned keys for internal B2B deployments.

The Deepthix playbook: automation without containers

A pragmatic plan:

start with a read-only agent (select folder → extract → report)
lock down outbound calls with tight CSP (only your API + the LLM)
design tools as small, explicit actions (list files, read file, search, summarize)
run heavy work in Web Workers
measure time saved, error rate, and token cost—then iterate

That’s how you ship real automation without building an overpriced, overcomplicated security theater.

Conclusion: the browser isn’t just for “viewing pages”

The browser is already a secure, cross-platform runtime designed to execute untrusted code. For AI agents, that’s a massive opportunity: ship useful automation without heavy containers and painful onboarding.

You won’t replace every server-side sandbox with it. But for a large chunk of SMB workflows—document analysis, reporting, QA, preparation—it’s a sweet spot.

Want to automate your operations with AI? Book a 15-min call to discuss.