Browser Isolation and Sandbox Infrastructure for AI Agents

TL;DR

• Traditional remote browser isolation keeps web code away from a human endpoint and returns a safe visual representation. Agent sandboxing contains autonomous, API-controlled browser sessions.
• Agents can follow hostile page instructions, misuse credentials, and execute actions without immediate human review. Conventional controls were not built for this runtime risk.
• Effective containment requires a separate compute and storage boundary for each session or tenant. Default-deny network access and task-scoped credentials limit what a compromised agent can reach.
• Buyers should verify the isolation boundary first, then inspect egress policy, secret injection, audit coverage, data retention, regional hosting, and private deployment options.

Why AI agents need a different kind of browser isolation than humans do

Traditional remote browser isolation protects a human user’s device by executing web content somewhere else. A remote service opens each page inside an ephemeral container, while the endpoint receives a safe representation of the page rather than its original code. RBI vendors describe the protected actor as a person who views pages and submits clicks, scrolling, or keyboard input.

RBI products use several rendering methods to keep active content away from the endpoint. Pixel pushing streams images or video after the remote browser renders the page. DOM mirroring removes suspected threats and sends a reconstructed page that the local browser can display. Network Vector Rendering streams graphics-engine drawing commands, which reduces bandwidth while withholding page code. Each method focuses on what reaches the human user’s device.

Enterprise RBI also applies policies around human browsing. A Secure Web Gateway can route unknown domains, email links, or sensitive users into isolation. Security Service Edge products can combine those routing decisions with access and data-loss controls. For example, an administrator might block downloads, clipboard use, printing, or keyboard input. Menlo Security describes this model as treating web content as untrusted and destroying the remote container after the browsing session.

An autonomous agent changes both the protected actor and the direction of risk. The agent consumes page content as input, decides what to do, and controls the browser through an API. It may retain cookies, authenticate to business applications, and perform actions without a person reviewing each step. Sending a sanitized visual representation to a human endpoint does not govern what the agent can read, which credentials it can use, or which transactions it can complete.

Prompt injection creates one risk that traditional RBI policies do not address. A malicious instruction embedded in a page can redirect the agent’s reasoning and cause an authorized browser session to take unintended actions. Current defenses remain probabilistic, so an agent sandbox must limit the resulting access rather than assume that filters will catch every instruction. Agent sandbox research notes that isolation can contain a prompt injection’s impact even when it cannot prevent the injection itself.

Agent identity and authorization require another control layer. A browser sandbox must restrict each machine identity to task-scoped credentials, approved tools, and permitted destinations. Otherwise, a hijacked agent can use valid authentication to bypass the intent behind a user’s original request. Traditional controls such as disabling copy and paste do not constrain an API-driven agent that can submit forms or call connected tools directly.

Machine-to-machine orchestration adds a third risk class. One service may create hundreds of browser sessions, resume stored state, and pass outputs into other agents or applications. Agent-focused infrastructure therefore needs per-session isolation, tenant separation, credential controls, network policy, and attributable audit records. Traditional RBI establishes a useful remote execution boundary, but its human-facing rendering and policy model does not cover those autonomous execution requirements.

How agent browser sandboxes actually contain risk

Per-session isolation gives each agent run its own browser process, filesystem, memory allocation, and lifecycle. When the session ends, the platform should destroy its writable state unless an explicit policy preserves selected data. A browser’s internal renderer sandbox cannot provide the same boundary because it protects browser processes rather than separating the entire agent workload from the host and other tenants.

Standard containers provide the lightest infrastructure boundary. Namespaces hide host resources, and cgroups limit consumption, but every container still shares the host kernel. A kernel flaw or unsafe runtime configuration can therefore expose the host or neighboring sessions. Containers remain reasonable for trusted workloads, but an agent processing hostile web content should not be treated as trusted code.

Documented runc escapes show how shared-kernel isolation can fail. CVE-2019-5736 allowed a malicious container to overwrite the host’s runc binary and gain host root under affected configurations. CVE-2024-21626 allowed crafted working-directory behavior to expose the host filesystem through open file descriptors. The latter received a CVSS score of 8.6 and was fixed in runc 1.1.12, according to a review of agent sandbox risks. Patching closes known flaws, but the examples demonstrate why a container runtime cannot serve as an absolute trust boundary.

gVisor adds a stronger layer by intercepting application system calls in a user-space kernel called Sentry. Most workload requests reach Sentry instead of the host kernel, so an escape may require defects in both codebases. The tradeoff appears most clearly in I/O-heavy browser workloads, where reported overhead ranges between 10 and 30 percent. Compute-heavy tasks usually see less overhead, according to a comparison of agent sandbox technologies.

Firecracker and Kata Containers place each workload behind a dedicated guest kernel. Firecracker uses hardware virtualization and a small virtual machine monitor, while Kata exposes virtual machines through familiar container and Kubernetes interfaces. A guest-kernel compromise therefore does not directly become a host-kernel compromise. Hardware virtualization also reduces exposure between tenants that share a physical machine, though buyers still need to ask whether each session, customer, or worker receives its own microVM.

ECScape illustrates why the placement boundary matters. Researchers showed that a low-privileged container on a shared Amazon ECS host could intercept IAM credentials intended for other tasks. The same technique failed against AWS Fargate because Fargate separated tasks with hardware virtualization and did not share their CPU, memory, storage, or network interfaces, according to a multi-tenant isolation analysis. An autonomous agent can repeatedly probe such weaknesses while carrying credentials and reacting to attacker-controlled page content.

Multi-tenant isolation must cover storage and resource use as well as compute. Each tenant should receive separate volumes without shared writable mounts, and storage controls should enforce tenant scope below the application layer. Separate encryption keys can further limit exposure if a storage policy fails.

Cgroups should enforce CPU, memory, and process limits for every session. Process caps stop fork bombs, while memory and CPU quotas prevent one agent from exhausting a shared host. Quotas contain resource abuse but do not replace a security boundary. A strong deployment combines quotas with disposable session storage and an isolation tier chosen for the consequences of a host or cross-tenant escape.

Network segmentation and the role of the browser proxy

Compute isolation limits what an agent can reach on its host, while network segmentation limits where the agent can send requests. A browser sandbox may resist filesystem or kernel attacks and still expose internal services, cloud credentials, or production APIs through unrestricted outbound access. Effective containment requires both boundaries.

A browser proxy places a policy enforcement point between each browser session and its destinations. Network policy should block outbound traffic by default, permit only required domains or IP ranges, restrict DNS resolution, and separate agent networks from production systems. Direct connections must also be blocked so an agent cannot bypass the proxy. Agent sandbox guidance recommends default-deny egress with explicit access to required endpoints.

Cloud metadata services require an explicit block. An agent manipulated through prompt injection could use server-side request forgery, commonly called SSRF, to request the instance metadata address at 169.254.169.254 and obtain host credentials. Network rules should deny that address regardless of the agent’s destination allowlist. AWS-oriented sandbox guidance gives an iptables rule that drops forwarded traffic to the metadata endpoint.

Multi-tenant deployments need separate egress policy for each tenant. Per-tenant allowlists prevent one customer’s browser from inheriting another customer’s approved destinations. Static outbound IPs let receiving services allow traffic from a known source, while tenant-scoped logs record the requested destination, timestamp, session identity, policy decision, and transferred volume. Research on multi-tenant agent infrastructure identifies per-tenant allowlists, static outbound IPs, and outbound traffic logs as core egress controls.

Anchorbrowser provides one vendor-specific example of an integrated network approach. Anchor describes Anchor VPN as a built-in enterprise VPN that supplies its browser infrastructure with a consistent network backbone without relying on third-party proxies. Consistent routing can reduce IP changes that disrupt authenticated sessions. Anchor’s public material does not establish whether Anchor VPN enforces default-deny egress, blocks metadata access, or provides tenant-scoped traffic logs. Buyers should verify those controls separately rather than treat a built-in VPN as proof of network isolation.

Secrets, authentication, and audit logging for autonomous sessions

Environment-variable injection provides the weakest credential protection. Every process in the browser sandbox can often read the variables, and secrets may appear in diagnostic logs or memory dumps. OWASP-oriented guidance therefore recommends avoiding environment variables for sensitive credentials in untrusted agent workloads, according to this agent isolation analysis.

Runtime vault retrieval offers a stronger option. The agent requests a secret through a secure API when the task begins, which avoids embedding credentials in code or browser images. Short-lived credentials reduce the exposure window, but the secret still enters sandbox memory. A compromised agent may read or misuse it before expiration.

Proxy-layer injection provides the strongest separation when the target protocol supports it. A trusted proxy adds credentials to outbound requests without exposing them to the agent or browser sandbox. The proxy should issue task-scoped access, distinguish read permissions from write permissions, and block requests outside the approved destination list. Website logins still require controls for cookies, MFA, reauthentication, and other browser session state that a request header cannot handle.

Authentication tooling should preserve the human requester's authority instead of letting every action inherit a broad agent identity. Each autonomous session needs its own identity, limited permissions, and expiration time. High-impact actions such as submitting a payment should require recorded human approval. NIST-oriented guidance favors just-in-time access because persistent credentials let a hijacked agent continue operating after its original task ends.

Anchor describes OmniConnect as authentication-lifecycle tooling for computer-use agents. According to a vendor-issued announcement, OmniConnect integrates with 1Password Unified Access and supports MFA flows. Anchor also reports automatic reauthentication after session logout and consistent routing through Anchor VPN. Buyers should treat these capabilities as vendor-reported and verify how credentials reach the browser, where session cookies remain, and which authentication events appear in logs.

An autonomous-session audit trail must connect each browser action to the authority behind it. A CSA research note summarizing NIST guidance identifies the minimum record as the initiator identity, action type, accessed tool or system, timestamp, result, and approval chain. Logs should also capture the context supplied to the agent and the permissions active at that moment.

Immutable records should cover credential retrieval, proxy injection, browser interactions, API requests, and policy violations. Each event needs a shared session identifier so investigators can reconstruct a workflow that crossed multiple agents or tools. The log should distinguish the human requester, the agent identity, and the service that executed the action. Without those distinctions, an audit may show what happened but cannot establish who authorized it.

Data retention, regional deployment, and private-cloud options

Deployment choice determines who controls the browser runtime and where session data crosses trust boundaries. A managed cloud places the runtime and supporting services in the vendor’s environment. A VPC deployment can provide dedicated network boundaries while leaving some management components with the vendor. Bring-your-own-cloud, private-cloud, and on-premise models give you greater infrastructure control, but contracts and architecture diagrams must identify any vendor control plane, telemetry service, or support channel that still receives data.

Retention policies should cover each data type the browser creates. Configure separate periods for recordings, screenshots, downloaded files, cookies, logs, and session metadata. Confirm when deletion occurs, whether deletion includes replicas and backups, and whether administrators can override the policy. A zero-data-retention option also needs a precise definition because a vendor may still retain billing, security, or operational metadata.

Regional controls must govern processing as well as primary storage. Ask where browsers execute, where backups reside, which personnel can access them, and whether subprocessors operate in other regions. Then require contractual region restrictions and technical settings that prevent workloads from launching elsewhere. A region selector without controls for logs, support access, and backups provides an incomplete residency boundary.

Anchor provides one vendor-reported example of tiered packaging. Its pricing disclosures list 30-day retention for the Team plan. The Enterprise plan lists customizable retention including zero data retention, custom regions in the EU, Asia, and Australia, plus bring-your-own-cloud and on-premise deployment. Buyers should verify which data categories each option covers and whether any Anchor-managed services remain outside the selected environment.

What SOC 2 and HIPAA claims actually mean for a browser sandbox vendor

SOC 2 is an attestation report, not a universal security certification. A Type I report evaluates whether specified controls were suitably designed at a particular date. A Type II report also evaluates whether those controls operated effectively during a review period, which commonly covers six to twelve months. Marketing phrases such as “SOC 2 compliant” or “SOC 2 in progress” do not establish either status without an auditor’s report.

Request the actual SOC 2 report, even if the vendor requires a nondisclosure agreement. Confirm that the audited legal entity and service cover the browser sandbox you plan to use. Review the reporting period, auditor’s opinion, noted exceptions, customer responsibilities, and any infrastructure providers excluded through carve-outs. An audit of corporate access policies may offer little evidence about session isolation, credential injection, or browser proxy controls.

A Type II report provides evidence that scoped controls operated during the stated period. It does not prove that every security control works, that the vendor remains secure after the review period, or that the service can stop a novel attack. A secondary overview of SOC 2 and HIPAA makes the same distinction and recommends requesting a current report from a recognized CPA firm.

HIPAA does not provide vendors with a general certification badge. When a browser sandbox creates, receives, maintains, or transmits protected health information on behalf of a covered entity, the vendor generally acts as a business associate and must sign a Business Associate Agreement. Browser screenshots, session recordings, logs, downloaded files, and stored authentication state can all contain protected health information.

Obtain the executed BAA before sending protected health information through the service. Review its permitted uses, breach notification duties, deletion terms, and subprocessor requirements. Then verify that the technical service matches the contract, including encryption, access logging, retention settings, backup locations, and regional processing. A vendor that cannot sign an acceptable BAA should not handle the workload.

Evaluation criteria for finance, healthcare, and government workloads

Regulated buyers should test whether a browser sandbox can enforce their specific controls and produce evidence that those controls operated. A general security claim cannot answer how the vendor handles credentials, protected data, or government authorization requirements.

Finance

• Can the vendor produce a tamper-resistant record for every agent session? NIST-related guidance calls for records that capture the initiator, action, accessed tool, timestamp, result, permissions, and approval chain. Those fields let an investigator attribute a transaction across human and agent identities.

• Can you export logs to your security archive with trusted timestamps and stable session identifiers? Ask how the vendor prevents alteration, controls administrator access, and links browser actions to downstream API or payment events.

• Can you scope each credential to one user, task, destination, and time window? Short-lived credentials reduce the damage an agent can cause after prompt injection or session compromise. Ask whether the browser retrieves secrets at runtime and whether logs exclude passwords, tokens, and account data.

• Can high-impact actions require human approval? The approval mechanism should pause an agent before money movement, account changes, or sensitive data exports rather than record approval after execution.

Healthcare

• Will the vendor sign a Business Associate Agreement before any browser session handles protected health information? A BAA should cover permitted uses, breach duties, and relevant subprocessors. A vendor that will not sign one should not receive PHI, according to this secondary compliance overview.

• Does encryption cover PHI in transit and at rest across session recordings, screenshots, downloads, logs, and backups? Ask who controls the keys and whether support personnel can decrypt stored artifacts.

• Can you configure retention separately for browser state, recordings, and audit logs? Confirm how deletion propagates to backups and subprocessors. Zero-retention claims should specify which artifacts disappear and which records remain.

• Can access controls bind each agent session to a patient, workforce member, and approved purpose? Broad shared credentials make inappropriate access harder to detect and investigate.

Government

• Can the vendor guarantee where session data, logs, backups, and support access remain? Sensitive workloads may require execution inside your cloud account or on premises so you control storage, networking, and reachable services. Infrastructure guidance recommends customer-controlled infrastructure for workloads with strict residency requirements.

• What authorization evidence can the vendor provide for your agency and impact level? If your procurement requires FedRAMP or comparable controls, ask for the exact authorization status, boundary, inherited controls, and current 3PAO assessment artifacts. “FedRAMP-ready” should not substitute for those documents.

• Can the browser environment enforce default-deny network access? Require per-session allowlists, private connectivity, blocked metadata endpoints, controlled outbound IPs, and logs of every permitted connection.

• Can the vendor isolate your workload in a dedicated tenant, private cloud, or on-premise deployment? Ask which control plane, support, telemetry, and update paths still cross the boundary.

Comparing browser isolation and sandbox vendors for AI agents

The supplied sources document some vendors far more fully than others. A “not publicly disclosed” cell means the available first-party research did not establish the control. It does not prove that the vendor lacks it.

Anchorbrowser provides the clearest supplied disclosures for authentication, networking, retention, regions, and private deployment. Its public material still leaves the underlying session boundary, tenant separation, and audit-log design unspecified. Browserbase supplies a vendor compliance claim but little supporting architecture detail in the available research.

Browserless has third-party evidence for self-hosting and several operational features, but the supplied sources do not establish its security boundary or compliance posture. Steel and Kernel cannot support a security comparison without first-party documentation. Traditional RBI vendors document strong endpoint protection for human browsing, but their rendering model does not establish controls for autonomous agents, persistent credentials, or API-driven session orchestration.

A practical checklist for evaluating agent browser infrastructure

Isolation

• Does every agent session receive its own compute boundary and filesystem, or do sessions share containers, kernels, or storage?
• Request an architecture diagram that identifies the isolation technology, tenant boundaries, and any shared components.
• Ask how the platform prevents one tenant from accessing another tenant’s browser state, cookies, files, and encryption keys.
• Confirm that the platform enforces CPU, memory, process, and execution limits outside the agent’s control.
• Request recent penetration test results and the vendor’s patching process for browser and container escape vulnerabilities.

Network controls

• Confirm that outbound traffic follows a default-deny policy with tenant-specific domain or IP allowlists. Infrastructure controls should restrict agent connectivity rather than relying on application code alone to enforce access limits (Northflank).
• Ask whether the platform blocks cloud metadata endpoints, private address ranges, and unauthorized DNS resolution.
• Confirm whether each tenant can receive static outbound IPs and inspect browser proxy logs.
• Request evidence that agent networks cannot reach the vendor’s management plane or your production network without explicit permission.

Secrets and audit records

• Ask whether credentials enter the sandbox through environment variables, runtime retrieval, or proxy-layer injection.
• Confirm that credentials are short-lived and limited to the required task and permissions.
• Request a sample audit record. Each record should identify the initiator, action, accessed system, timestamp, outcome, and approval chain (CSA Research Note).
• Ask whether users can export logs to immutable storage and connect them to existing security monitoring tools.

Retention and region

• Obtain the default and configurable retention periods for recordings, logs, cookies, and downloaded files.
• Ask how deletion works across primary storage and backups.
• Confirm every processing and storage region, including regions used by subprocessors.
• Request private-cloud, customer-cloud, or on-premise deployment details when policy requires customer-controlled infrastructure.

Compliance evidence

• Ask for the actual SOC 2 report, not a label such as “SOC 2 compliant” or “in progress.” Verify its scope, auditor, period, exceptions, and whether it covers Type I or Type II controls (Hamming).
• Get a signed BAA before sending protected health information.
• Ask government vendors which services and deployment boundaries any FedRAMP or third-party assessment covers.

Match the isolation and evidence bar to the workload’s actual regulatory exposure rather than the vendor’s marketing tier.