Which platforms support AI-agent sandboxes in a customer’s own cloud?
AI agents that write code, install packages, process files, or call tools need a trusted execution boundary. With private data or services, vendor-hosted sandboxes may not fit your network, residency, or infrastructure policies.
“Private,” “dedicated,” and “in your VPC” can describe different architectures. This article compares platforms that run sandbox compute on customer-owned infrastructure and helps you identify the boundary you need.
The platforms below support AI-agent sandbox execution in customer-owned cloud environments, but they place different parts of the platform inside that boundary.
- Northflank Sandboxes lets you run microVM-backed or gVisor-isolated AI-agent sandboxes in your own cloud with enterprise infrastructure control through self-serve BYOC, with Northflank provisioning and managing Kubernetes, or on eligible existing private, on-premises, and bare-metal Kubernetes clusters through BYOK. BYOC supports Google Cloud Platform, AWS, Microsoft Azure, Civo, Oracle Cloud, CoreWeave, and Nebius, while Northflank Cloud provides the fully managed option.
- E2B provides API-driven Firecracker microVM sandboxes with contact-led BYOC for customer AWS and GCP environments. Templates, snapshots, runtime logs, and sensitive sandbox traffic remain within the customer VPC boundary.
- Runloop Devboxes uses dedicated microVMs and a BYOC deployment that places the sandbox control plane and data plane in your AWS, GCP, or Azure environment.
If your enterprise needs to run AI-agent sandboxes inside its own security, network, residency, or cloud-spend boundary, Northflank Sandboxes provide separate-kernel isolation on Northflank Cloud, self-serve BYOC, or eligible existing Kubernetes through BYOK. Northflank manages the platform and can provision and manage the Kubernetes layer in your cloud account, so your platform team retains infrastructure control without building the sandbox orchestration layer itself.
Sandboxes run alongside APIs, workers, databases, storage, jobs, and GPU workloads with shared deployment, networking, secrets, observability, RBAC, and audit controls. Northflank is SOC 2 Type 2 compliant and HIPAA compliant, with BAAs supported under Enterprise contracts. Northflank Skills also gives compatible coding agents Northflank-specific guidance for deploying and operating the platform. Startups and engineers can use the same capabilities through Northflank’s self-serve developer experience.
Get started with Northflank self-serve, or book a demo to discuss AI-agent sandbox architecture, BYOC, Kubernetes, networking, security, compliance, or scale.
An own-cloud AI-agent sandbox runs its execution plane in a cloud account, VPC, Kubernetes cluster, or machine fleet your organization owns or manages. The vendor may still provide a hosted control plane, API, orchestration, or support.
That excludes several useful but different designs. A service can attach to your VPC while executing elsewhere. Peering connects networks, a dedicated region isolates vendor capacity, and a custom image changes the environment rather than its location.
Start by asking where agent-written code actually executes, then trace templates, snapshots, files, logs, credentials, and network traffic separately. If the main requirement is reaching internal services rather than owning the execution plane, the available patterns for connecting AI-built applications to private APIs may solve the problem without BYOC.
Compare the boundary and the work your team must own, not just SDK syntax or startup time.
- What runs in your infrastructure? Separate compute, storage, logs, and networking from the vendor control plane.
- What isolates each run? Shared-kernel containers, user-space kernels, microVMs, and dedicated VMs provide different boundaries. This guide to isolating AI agents with company data covers the surrounding controls.
- What state survives? Disposable tasks and long-running coding agents have different needs. Compare the trade-off between persistent and ephemeral AI sandboxes.
- How does it reach other systems? Check private DNS, egress policy, workload identity, secrets, and traffic paths.
- Who operates the fleet? Self-hosting can leave upgrades, capacity, patches, storage, observability, and incident response with your team.
The best fit depends on which platform components must run in your account and whether you need a sandbox API or the complete infrastructure around your agents.
| Platform | Best for | Customer-cloud boundary | Isolation | Operating model |
|---|---|---|---|---|
| Northflank Sandboxes | Running sandboxes with the complete production agent stack | Sandbox workloads on BYOC or eligible BYOK Kubernetes | MicroVM-backed or gVisor user-space-kernel isolation, depending on configuration | Northflank manages the platform and can manage the BYOC cluster |
| E2B | Running agent code in API-driven microVM sandboxes in a customer VPC | AWS and GCP | Firecracker microVM | E2B control plane with contact-led BYOC onboarding |
| Runloop Devboxes | Keeping both sandbox planes in the customer environment | Control and data planes in AWS, GCP, or Azure | Dedicated microVM | Enterprise BYOC deployment |
The following profiles explain how each platform fits a different customer-cloud operating model.
Northflank supports isolated AI-agent execution whether you are building a dedicated sandbox product or integrating sandboxes into a wider production platform. Northflank Sandboxes provide separate-kernel isolation, command execution, exposed ports, persistent volumes, GPUs, pause, resume, and deletion. Northflank is built for enterprise infrastructure, security, and governance requirements, while startups and individual engineers can also use the same self-serve UI, API, CLI, SDK, GitOps, and templates.
Your team can run sandboxes on Northflank Cloud or deploy them into infrastructure you control. Self-serve BYOC places workloads in your cloud account with Northflank provisioning and managing Kubernetes, while BYOK lets you import a suitable existing Kubernetes cluster.
Northflank also runs the infrastructure around the sandbox. APIs, workers, jobs, databases, object storage, persistent volumes, and GPU workloads use the same deployment and operations layer. An agent can create an environment, access a private service, store an artifact, trigger a job, and promote an output without your team combining separate sandbox and application platforms.
The deployment and operations capabilities include:
- Self-serve BYOC: Deploy into Google Cloud Platform, AWS, Microsoft Azure, Civo, Oracle Cloud, CoreWeave, or Nebius, with Northflank managing Kubernetes in your account.
- BYOK: Import suitable existing Kubernetes, including eligible private, on-premises, or bare-metal infrastructure.
- Full-stack infrastructure: Run APIs, workers, jobs, databases, storage, and GPU workloads with your sandboxes instead of operating separate platforms.
- Security and governance: Use network policies, RBAC, scoped API roles, SAML or OIDC SSO, secret injection, and audit logs.
- Compliance: Northflank is SOC 2 Type 2 compliant and HIPAA compliant, with BAAs supported under Enterprise contracts.
- Agent-native operations: Northflank Skills guides Codex, Claude Code, Cursor, and other compatible agents through Northflank workflows.
With BYOC, workload runtime and data stay in your environment. The Northflank security details explain the separate options for metadata, logs, builds, images, DNS, and backups.
Get started with Northflank self-serve, or book a demo to discuss AI-agent sandbox architecture, BYOC, Kubernetes, networking, security, compliance, or scale.
E2B fits applications that already have most of their production infrastructure and need a sandbox API for agent code execution.
- Infrastructure targets: E2B BYOC supports customer AWS and GCP environments.
- Isolation: Each E2B sandbox runs in a Firecracker microVM.
- Data boundary: Templates, snapshots, and runtime logs are stored in the customer VPC. Sensitive traffic, including template build source files and sandbox traffic, goes directly from the client to the BYOC VPC without traversing E2B Cloud.
- Control plane: E2B Cloud manages the platform and receives anonymized cluster CPU and memory metrics. An internal load balancer and VPC peering can keep sandbox traffic private.
- Access model: BYOC is contact-led and requires a dedicated supported cloud environment.
Sandbox compute runs in the customer environment while E2B operates the hosted control plane.
Runloop Devboxes is suited to policies that require both platform planes inside infrastructure owned by your organization.
- Customer-cloud boundary: Runloop BYOC places the control plane and data plane in a customer AWS account, GCP project, or Azure subscription.
- Isolation: Devboxes run in dedicated microVMs with their own kernel, filesystem, and network namespace.
- Security controls: The deployment includes customer-managed KMS, workload identity, audit logs, and network isolation.
- Private connectivity: Available patterns include private links, VPC peering, transit networks, and VPNs.
- Access model: BYOC is an enterprise-led deployment.
Before committing, validate upgrade ownership, support access, telemetry, capacity, disaster recovery, and the exact cloud services deployed.
The right platform satisfies your non-negotiable boundary with the least new infrastructure for your team to own.
- Use Northflank Sandboxes when you need sandboxes and the surrounding production application platform across managed cloud, BYOC, or BYOK.
- Use E2B when API-driven Firecracker microVM sandboxes in AWS or GCP are the priority and contact-led onboarding is acceptable.
- Use Runloop Devboxes when both planes must be placed in a customer AWS, GCP, or Azure environment.
Test the platform with a representative workflow. Create environments under burst load, terminate a compromised run, revoke its credentials, deny an unapproved destination, restore required state, and trace an action end to end. At high concurrency, model the scheduler, warm capacity, quotas, and failure domains described in this guide to running millions of concurrent AI sandboxes.
If an agent creates a service that must stay online, move the artifact through a controlled build and release path. See how to deploy an AI agent from sandbox to production for that lifecycle.
These answers clarify common deployment boundaries.
No. Peering creates a private network path between environments, but it does not change who owns the sandbox compute. With Northflank BYOC, the sandbox workload runs on Kubernetes provisioned in your cloud account; peering or an overlay is a separate connectivity decision.
Not automatically. Trace sandbox files, templates, snapshots, logs, metrics, source code, images, backups, credentials, and control-plane metadata. For Northflank BYOC, workload runtime and workload data sit in your environment, while the Northflank security details explain the boundaries and options for other data categories.
It depends on the workload and threat model. A microVM or another separate-kernel boundary is a strong default for untrusted, tenant-supplied, or agent-generated code. Northflank Sandboxes use separate-kernel isolation, while a hardened shared-kernel container may fit lower-risk internal tasks after you assess privilege, network access, credentials, and escape impact.
It depends on utilization and operational cost. Include idle capacity, engineering, upgrades, security response, observability, and availability instead of comparing one vCPU rate. A managed BYOC model such as Northflank can keep execution in your account while reducing the Kubernetes and platform work your team operates directly.
Not on placement alone. Give each workload a narrow route, scoped identity, short-lived credentials, and API-level authorization. On Northflank BYOC, network policies can restrict sandbox traffic to approved workloads, projects, IP addresses or CIDRs, FQDNs, or hostnames, while the target API still authorizes each action.
