← Back to Blog
Header image for blog post: How to run browser agents in secure sandboxes on Northflank
Daniel Adeboye
Published 9th September 2026

How to run browser agents in secure sandboxes on Northflank

TL;DR: how to run browser agents in secure sandboxes

  • Browser agents face a unique threat model because untrusted web content can contain prompt injection that influences the agent's actions, even when the browser itself is isolated.
  • Chromium's built-in process sandbox protects against certain browser and renderer exploits, but it does not control what an AI agent does with the browser's legitimate permissions.
  • A secure browser-agent sandbox should provide strong workload isolation, egress controls, session isolation, scoped credentials, and audit logging.
  • Northflank Sandboxes provide microVM-backed containers with VM-level isolation, startup times under 1 second, and API-based lifecycle management for running untrusted workloads such as AI agents.
  • Sandboxes can run on Northflank's managed cloud or in your own cloud through BYOC, and can be paused, resumed, or destroyed as needed.

Get started (self-serve) or book a demo.

Browser agents interact with the web autonomously: navigating pages, clicking elements, filling forms, extracting data, and taking screenshots. Computer-use agents such as Claude Computer Use and ChatGPT agent, along with Playwright-based agents, can perform multi-step tasks across web applications without a human controlling every interaction. That capability is what makes browser agents useful. It also makes the browser environment a significant security boundary.

The threat model for browser agents is different from the threat model for coding agents. A coding agent's primary risk comes from the code it generates and executes, while a browser agent also consumes untrusted web content that can influence its behavior. A malicious webpage can contain instructions designed to make an agent take actions outside its intended scope, such as sending sensitive data to an external endpoint or interacting with an unauthorized service. The sandbox therefore needs to isolate not only the agent's execution environment, but also the browser session and the credentials associated with it.

What a secure browser agent sandbox requires

  1. MicroVM isolation for the browser process: Standard containers share the host kernel, while microVM-based isolation provides a stronger boundary around the browser workload. A compromised browser process or agent workload is isolated from the underlying host and other sandbox sessions.
  2. Egress controls on what the browser can reach: Default-deny egress means the browser can only reach destinations explicitly allowed by the network policy. If a prompt injection causes the agent to send data to an attacker-controlled domain, the request can be blocked because the destination is not in the allowlist.
  3. Session isolation between tenants: In a multi-tenant browser agent platform, each user's session should be isolated from other users' sessions. Isolating each session at the workload or VM level reduces the risk of one compromised browser session accessing another user's browser state, files, or processes.
  4. Scoped credential injection: Credentials required by the browser agent should come from a secrets manager and be limited to the permissions required for the task. They should be injected at runtime rather than stored in the browser image, source code, or developer's local environment.
  5. Audit logging of browser activity: Platform-level logging should provide visibility into session creation, configuration changes, resource usage, and other relevant activity. Keeping this visibility outside the agent's own process makes it more useful when investigating unexpected behavior.

How to run a browser agent in a Northflank sandbox

Northflank Sandboxes provide isolated environments for running browser agents and browser automation workloads. They boot in under 1 second, run in their own isolated environment, and can be created and managed programmatically using the Northflank SDK.

Northflank is an AI-agent sandbox and workload platform for running untrusted code in isolated environments on Northflank cloud, in your own cloud account and VPC, or on eligible on-premises infrastructure.

Prerequisites

Step 1: Install and initialize the SDK

npm install @northflank/js-client
import {
  ApiClient,
  ApiClientInMemoryContextProvider,
} from "@northflank/js-client";

const contextProvider = new ApiClientInMemoryContextProvider();

await contextProvider.addContext({
  name: "context",
  token: process.env.NORTHFLANK_TOKEN,
});

const apiClient = new ApiClient(contextProvider, {
  throwErrorOnHttpErrorCode: true,
});

Step 2: Create a browser agent sandbox

Deploy your browser agent container as a sandbox service. Northflank sandboxes provide the isolated execution environment. Your browser agent application, including the browser controller, task logic, and any policy enforcement, runs inside it.

const sandboxId = `browser-agent-${crypto.randomUUID().split("-")[4]}`;

await apiClient.create.service.deployment({
  parameters: {
    projectId: "your-project-id",
  },
  data: {
    name: sandboxId,
    billing: {
      deploymentPlan: "nf-compute-200",
    },
    deployment: {
      instances: 1,
      docker: {
        configType: "customCommand",
        customCommand: "sleep infinity",
      },
      external: {
        imagePath: "your-browser-agent-image",
      },
      storage: {
        ephemeralStorage: {
          storageSize: 4096,
        },
      },
    },
  },
})

For credentials, use Northflank secret groups rather than storing sensitive values directly in your service configuration.

Before executing commands, make sure the sandbox is fully running. See the SDK reference for how to wait for it to be ready.

Step 3: Execute a browser task inside the sandbox

Once the sandbox is running, execute your browser agent. Replace your-browser-agent-script.js with the entry point of your browser agent application, and make sure your image includes your script and its dependencies.

const handle = await apiClient.exec.execServiceSession(
  {
    projectId: "your-project-id",
    serviceId: sandboxId,
  },
  {
    shell: "bash -c",
    command: "node your-browser-agent-script.js",
  }
);

const result = await handle.waitForCommandResult();

console.log("Exit code:", result.exitCode);

The browser process runs inside the isolated sandbox, while the SDK lets your application create the environment and execute commands remotely.

Step 4: Manage the sandbox lifecycle

When the browser session is complete, you can destroy the sandbox:

await apiClient.delete.service({
  parameters: {
    projectId: "your-project-id",
    serviceId: sandboxId,
  },
});

For most browser agent workloads, ephemeral storage is the safer default. Persistent volumes should be used deliberately and isolated per session. Sandboxes can also be paused and resumed when you need to preserve the environment without incurring compute costs.

For more advanced configurations, including persistent volumesGPU sandboxes, port exposure, and sandbox lifecycle management, see the Sandboxes on Northflank documentation.

How Northflank handles browser agent infrastructure

Running browser agents securely means operating more than the browser itself. Someone has to provision isolated environments, manage their lifecycle, control networking and credentials, allocate resources, and support the infrastructure as the number of concurrent sessions grows.

Northflank provides this execution layer through Sandboxes, with the rest of the platform available around the browser agent workload.

  • MicroVM isolation:** Each sandbox runs in a microVM-backed container using user-space kernel isolation. Sandboxes boot in under 1 second and prevent container escape. Each session gets its own dedicated kernel, providing a stronger isolation boundary between browser agent workloads, the host, and adjacent sessions.
  • Ephemeral and persistent environments: Sandboxes can run as short-lived environments for single browser tasks, or use persistent workspace storage when session state needs to survive between runs. For most browser agent workloads, ephemeral storage is the safer default.
  • Managed cloud or BYOC: Sandboxes run on Northflank's managed cloud across 6+ regions, or inside your own AWS, GCP, Azure, Oracle, or CoreWeave account with self-serve BYOC. Agent execution stays inside your own VPC when using BYOC.
  • Secrets management: Secret groups store credentials and inject them at sandbox start. Credentials are not stored inside the browser environment.
  • RBAC and SSO: Northflank provides role-based access control across the platform and enterprise SSO through SAML and OIDC. Every sandbox session is tied to a named identity.
  • Audit logging: Platform and workload logs provide visibility into sandbox activity and infrastructure changes, giving teams a record that can be used to investigate unexpected browser agent behavior.
  • Broader workload support: Browser agents can run alongside applications, APIs, workers, databases, jobs, and GPU workloads through the same platform.

Conclusion

Browser agents face a threat model that standard sandbox approaches underestimate. Chromium's process isolation stops malicious JavaScript from escaping the renderer. It does not stop a manipulated agent from taking actions with its own legitimate permissions. Infrastructure-level isolation, default-deny egress, and credential injection outside the browser session are the controls that constrain what a manipulated browser agent can actually do.

Northflank sandboxes provide that infrastructure as a managed platform: microVM-backed containers that boot in under 1 second, prevent container escape, and are created and managed programmatically via the JavaScript SDK. Browser agent sessions run in complete isolation from your host environment and from each other.

FAQs: how to run browser agents in secure sandboxes

Can I run Playwright in a secure sandbox on Northflank?

Yes. Playwright-based browser workloads can run inside a Northflank Sandbox alongside the browser runtime and application code that controls it. The Sandbox provides the isolated execution environment, while Playwright handles browser automation.

What isolation does Northflank use for browser agents?

Northflank uses microVM-backed isolation for sandbox workloads, with Kata Containers and Cloud Hypervisor as the primary microVM approach. Firecracker and gVisor are also supported depending on workload and infrastructure requirements.

How do you securely give a browser agent access to an authenticated website?

Use a dedicated browser identity or service account with only the permissions required for the workflow. Keep browser state isolated per session, avoid exposing personal browser profiles, and provide credentials at runtime rather than storing them in source code or images.

Should browser agents have unrestricted internet access?

No. Browser agents need network access to perform their jobs, but unrestricted egress makes it easier for a compromised or manipulated agent to communicate with unexpected destinations. Use network policies and explicit allowlists to control which websites, APIs, and internal services the browser can reach.

Can I run browser agents inside my own cloud or VPC?

Yes. Northflank supports sandbox workloads in customer-owned cloud infrastructure through BYOC, allowing teams to run them inside their own cloud environment and network.

Share this article with your network
X