What is browser sandboxing for AI agents?
Browser sandboxing for AI agents is the layered isolation between a session's browser and everything outside it: other sessions, the host system, the credential store, another tenant's data. Layers stack from per-tab process isolation (cheap, leaky), to per-session containers (better, shared kernel), to microVMs per session (strongest, hardware boundaries). The right layer depends on what you're afraid of.
What is browser sandboxing for AI agents?
A browser agent is, by design, executing instructions derived from untrusted content. The page might be a customer dashboard or a phishing trap; the agent doesn't get to know in advance. That makes the browser the most exposed surface in the stack — and it's where every layer of defense starts to matter. Sandboxing is the answer to a simple question: when something inside the browser goes wrong (a prompt-injection hijack, a chrome exploit, an over-eager agent action), how far can the blast radius reach? Less far than you'd think with the right layers; further than you'd hope with the wrong ones.
The four boundaries that matter
Production agent platforms care about isolation across four boundaries, in increasing order of strength and cost:
- Tab / process boundary. Modern browsers already isolate tabs into separate OS processes. Useful inside a session, near-useless across sessions because they share the same browser binary, the same OS, the same caches.
- Browser-instance boundary. Each agent session runs in its own browser process / Chromium binary. Fresh cookies, fresh storage, fresh in-memory state. Stops casual cross-contamination but a kernel-level escape still reaches the host.
- Container boundary. The browser runs inside a Linux container (or equivalent) with seccomp / namespaces / cgroups limits. Strong against most realistic threats, weak against true kernel exploits since the kernel is shared.
- MicroVM / hardware-virt boundary. The browser runs inside a Firecracker-style microVM with a separate kernel and hardware-backed memory isolation. The strongest practical option for cloud-browser products and the right answer for multi-tenant environments where one tenant being compromised must not reach another.
The right layer depends on the threat model: a hobby script needs (1) or (2); a multi-tenant product handling regulated data needs (4).
What sandboxing protects against
Different layers stop different attacks. The honest comparison:
| Tab/process | Browser instance | Container | MicroVM | |
|---|---|---|---|---|
| Cookie / storage leak across sessions | ✗ | ✓ | ✓ | ✓ |
| One agent's network requests reaching another | ✗ | partial | ✓ | ✓ |
| Browser exploit reaching the host filesystem | ✗ | ✗ | partial | ✓ |
| Cross-tenant memory access | ✗ | ✗ | ✗ | ✓ |
| Kernel-level container escape | n/a | n/a | ✗ | ✓ |
A lot of agent platforms market "sandboxing" without saying which layer. The right phrasing in a security review is "each session runs in its own [containers/microVMs] with [these] kernel-level controls; the host is not shared between tenants in any way that crosses [this] boundary."
Sandboxing vs. browser isolation vs. PII handling
These three concepts get conflated and they're solving different problems:
- Browser sandboxing is about technical containment — the OS-level boundaries between a session's browser and everything else. See browser isolation for the foundational concept.
- PII handling is about data flow — what ends up in the model's context, in observability artifacts, in storage, in training corpora.
- Zero data retention is about persistence — what survives the session.
A complete privacy posture needs all three. Sandboxing without retention controls leaks PII through screenshots; retention controls without sandboxing leak sessions into each other; either alone is half a story.
Notte's posture
Each Notte session runs in an isolated cloud-browser instance, with the kind of layered controls described above. SOC 2 Type II is in place; specific scope and architectural detail (which layer, in which regions, against which threat model) is what the Notte Trust Center is for.
Key takeaways
- Browser sandboxing for AI agents is the OS-level isolation between a session's browser and everything outside it.
- Four layers stack from cheap (process / tab) to strong (microVM); the right level depends on threat model and tenancy.
- Sandboxing is technical containment, distinct from PII handling (data flow) and ZDR (persistence). A real privacy story uses all three.
- For multi-tenant or regulated workloads, the only acceptable answer is microVM-class isolation per session.