Browser sandboxing restricts the permissions of processes that handle untrusted web content. It limits what those processes can access on the operating system, so exploiting a webpage-rendering bug doesn't automatically give an attacker access to your files or the rest of the machine. Chromium's sandbox uses operating system security controls to enforce those restrictions.
Browsers must process code and media supplied by websites you don't control. Malicious pages may exploit flaws in an image decoder or JavaScript engine. Sandboxing assumes such a compromise can happen and restricts the affected process before it handles that content.
Copy link to headingHow does browser sandboxing work?
Browsers divide work among processes with different responsibilities. In Chromium's multiprocess architecture, renderer processes handle web content, while the main browser process coordinates the application. Separate services handle work such as networking. This division lets the browser apply tighter restrictions to processes exposed to untrusted input.
Renderers need to display pages and execute scripts without unrestricted access to the user's home directory. Privileged components validate requests before acting on a renderer's behalf.
The enforcement mechanism depends on the operating system. Chromium on Windows uses controls such as restricted access tokens. On Linux, namespaces and seccomp filters help confine processes and limit their system calls.
System calls ask the operating system kernel to perform work, such as opening a file. Filtering them limits what a compromised process can ask the kernel to do.
Sandbox escapes occur when attackers cross an intended restriction. Compromising a renderer and escaping its sandbox are separate failures, though an attack can combine them. The browser and operating system both need security updates because the boundary depends on their implementations.
Copy link to headingHow is sandboxing different from Site Isolation?
Process sandboxing limits access to the surrounding system. Site Isolation helps prevent compromised renderers from accessing another site's sensitive data.
Browsers already enforce the same-origin policy, which restricts how documents and scripts from different origins interact. Site Isolation adds process separation and checks outside the renderer. It can keep a malicious site's renderer from receiving data belonging to another site in the first place.
Tabs aren't dependable security boundaries. Cross-site frames within one tab can occupy different processes, and process allocation varies by browser and platform. Another tab doesn't create an isolated environment for another customer.
Several controls use similar language but operate at different levels:
These controls can work together. An iframe restriction doesn't create a virtual machine, and a VM doesn't decide which site's data a browser renderer can access.
Copy link to headingWhat does the iframe sandbox attribute do?
Web developers can apply HTML sandbox restrictions to an embedded document. An empty sandbox attribute applies every restriction. Tokens such as allow-scripts grant exceptions for content that needs additional capabilities.
This static preview disables scripts and form submission:
<iframe title="Static content preview" sandbox="" srcdoc="<h2>Preview</h2><p>This content needs no scripts.</p>"></iframe>This is a complete embedding example using fixed content. The frame receives an opaque origin because it lacks allow-same-origin. It also cannot open popups or navigate the top-level page under the sandbox restrictions shown.
Review each exception if a preview needs JavaScript. Granting both allow-scripts and allow-same-origin can let content from the embedding page's own origin remove the sandbox attribute and reload without restrictions.
The attribute doesn't sanitize HTML or establish a network allowlist. If you replace the fixed srcdoc value with user content, use a safe insertion mechanism. Consider serving hosted untrusted documents from a separate origin, since opening them directly bypasses the iframe's restrictions.
Copy link to headingWhat does browser sandboxing protect against?
Browser sandboxing reduces the damage a compromised process can cause. For example, a renderer exploit should encounter operating system restrictions when it tries to read unrelated files or install persistent malware. Chromium's sandbox threat model treats the code inside the restricted process as potentially hostile.
Those protections depend on the operating system kernel and privileged components handling renderer requests. Bugs in either can undermine the boundary. Sandboxing also doesn't determine whether a website deserves information you choose to submit. Sending credentials to a phishing page doesn't require a sandbox escape.
For automated browsing, distinguish machine access from account access. Browsers signed in to business applications may be able to change records through the ordinary UI. Isolating the browser doesn't remove those permissions or decide whether a particular change is authorized.
Keep the browser's native sandbox enabled where the execution environment supports it. Chromium warns that launching with --no-sandbox reduces security. Investigate launch failures before disabling a protection, including when a container or VM surrounds the browser.
Copy link to headingWhy do browser agents need an isolated execution environment?
Browser agents add automation code that may download files or run commands to process them. The renderer sandbox doesn't contain every program the worker launches. Give the worker its own execution boundary for untrusted work.
Consider an agent that downloads an invoice and converts it into structured data. The browser renders the supplier portal; a separate program parses the downloaded document. Putting the browser and parser in a dedicated worker can keep both away from the application's production files. The application can then accept a defined result instead of sharing its entire working directory.
When running computer-use agents, assign the worker to a particular user or task and control which authenticated session it receives. Saved cookies and downloaded files should follow that ownership, including when a later job resumes the session.
Webpage text can contain instructions intended to redirect an AI agent. An execution boundary limits what the resulting actions can reach, but it doesn't decide which instructions the model should trust. Enforce business permissions and required approvals in the application or destination service.
Copy link to headingWhere does Vercel Sandbox fit?
Vercel Sandbox provides an isolated Linux environment for a browser and its automation tools. Each sandbox has its own guest kernel inside a Firecracker microVM. This boundary surrounds the whole worker, while the browser's sandbox restricts its renderer processes.
Use this approach when a task needs control over installed tools or must process files alongside browser work. You supply the browser and its dependencies, including its native security configuration. The microVM security model describes the separate boundary around the guest.
For interactive browser tools, command stdin support lets your application send input to a process that is already running.
Configure the Sandbox firewall for the destinations the worker needs. Outbound internet access is allowed by default. For a restricted browser workflow, allow its target website and authentication dependencies. Permission to reach a site doesn't authorize every action within it.
Decide whether to retain browser files. Sandbox persistence keeps filesystem state beyond the running session. Restoring it doesn't resume processes, so restart the browser and verify its saved authentication.
Copy link to headingWhen should you use Kernel through the Vercel Marketplace?
Managed browser services let you request sessions without maintaining the browser installation or runtime. Kernel on the Vercel Marketplace provides cloud browsers that your application controls through automation tools.
Kernel runs each Chromium browser in its own VM. Your application can connect using the Chrome DevTools Protocol, or CDP, with tools such as Playwright. Kernel also provides Live View and session replays for observing browser work.
The Marketplace integration provisions a Kernel resource. With the Vercel CLI installed, run these commands from your project directory to sign in, link the project, and add Kernel:
vercel loginvercel linkvercel integration add kernelFollow the prompts to select a team and project, configure the resource, and review the terms. Connecting Kernel to the project syncs KERNEL_API_KEY to its environment variables. Keep the key in server-side code.
The browser automation starter demonstrates a Next.js application creating a Kernel browser. Its AI SDK agent executes Playwright code in the browser VM.
Choose Vercel Sandbox when you need to assemble the worker's execution environment. Kernel fits applications that need a managed browser session. They can participate in the same application, but installing Kernel doesn't place its browser inside Vercel Sandbox.
If a sandboxed worker controls a remote browser, configure that browser's access and session ownership separately.
Copy link to headingHow does agent-browser fit into a sandboxed workflow?
agent-browser gives AI agents a command-line interface for operating a browser. An agent can inspect an accessibility snapshot and interact with elements using references returned by that snapshot, such as a link to download an invoice.
Choose a package manager to install the CLI and download Chrome:
pnpm add -g agent-browseragent-browser installOn Linux, agent-browser install --with-deps also installs system libraries and requires root or sudo access. Install inside the sandbox if the browser will run there.
Open a page, inspect its interactive elements, and close the browser when finished:
agent-browser open https://example.comagent-browser snapshot -iagent-browser closeThe snapshot returns element references for subsequent commands. In an ongoing task, inspect the page again after navigation before choosing another target. This example runs the browser in the environment where you installed it; it doesn't create a Vercel Sandbox.
Check Chrome's launch settings in the target environment. agent-browser can add --no-sandbox automatically when it detects CI, root execution, or certain containers. Successful startup doesn't prove that the native sandbox is enabled.
For hosted sessions, the Kernel provider lets the CLI control a browser running on Kernel. Configure agent-browser's security controls for either workflow; navigation allowlists, action policies, and output limits are opt-in.
Action policies can deny operations or require confirmation. Check allowlist support for your browser connection mode before relying on it.
The domain allowlist isn't an operating system firewall, and agent-browser doesn't sandbox arbitrary local executables. Combine its controls with the worker's execution boundary and network policy. For Kernel sessions, apply the relevant network restrictions where the remote browser runs.
Copy link to headingFrequently asked questions
Copy link to headingIs iframe sandboxing the same as browser sandboxing?
No. The HTML sandbox attribute changes the capabilities of an embedded document, such as whether its scripts can run. The browser's process sandbox uses operating system controls to restrict processes handling web content. Both can apply to the same page.
Copy link to headingDoes running a browser in a VM replace its native sandbox?
VMs provide a boundary around the guest environment. The browser's native sandbox adds restrictions within that guest, protecting resources a compromised renderer should not reach. Review both configurations because their protections apply at different levels.
Copy link to headingCan browser sandboxing prevent prompt injection?
Browser sandboxing doesn't decide whether instructions found on a webpage are trustworthy. An agent can follow malicious text while using legitimate browser actions. Restrict the agent's account permissions and enforce authorization for consequential operations outside the model's reasoning.
Copy link to headingIs remote browser isolation the same as a browser's built-in sandbox?
Remote browser isolation runs the browser away from the user's device. Built-in sandboxing restricts processes wherever the browser runs. Remote services can use both, but you still need to assess their isolation and session controls.