Which AI Sandbox Providers Run Inside Your Own Cloud Account

Every AI agent that executes code sends something out to whatever runtime hosts that execution: environment variables, file contents, API responses, intermediate model output. Whichever cloud account owns that runtime owns those data flows, and that single fact turns "where does my sandbox run" from a vendor preference into a question with legal and architectural weight. If your team works in healthcare, financial services, or government contracting, this stops being abstract fast. A Business Associate Agreement requirement attaches to any service that processes sensitive regulated customer data on a customer's behalf, so if a managed sandbox executes agent payloads carrying that kind of data, it almost certainly falls under that requirement. The decision cascades forward into isolation model, compliance posture, operational workload, and cost, each of which gets its own treatment further down. If a team picks a sandbox provider by cold-start latency alone, and never asks where the code actually runs, it has made an infrastructure commitment it hasn't actually evaluated.

What "running inside your own cloud account" means technically

Vendors use the phrase "your own cloud" loosely, and three distinct deployment models hide behind it. In a pure managed model, the vendor runs both the control plane and the compute on its own infrastructure: a customer sends code, gets output back, and nothing touches customer-owned servers. In a self-hosted or air-gapped model, the customer runs both the control plane and the compute, and the vendor's role shrinks to supplying software rather than a service, which puts the full operational burden on the customer's own team. Between those two sits BYOC, Bring Your Own Cloud, where the vendor still operates or hosts the control plane but the sandbox compute itself provisions inside the customer's VPC or cloud account, so workload data stays on infrastructure the customer owns.

The distinction that actually matters is between where the workload executes and where the control plane lives, and that line blurs more than marketing copy suggests. A BYOC arrangement can keep compute fully inside a customer's VPC while still routing orchestration metadata through the vendor's own infrastructure, and for some compliance frameworks that routing matters just as much as where the code actually ran. Northflank's enterprise guide draws this split explicitly: standard BYOC deployments keep workload execution in the customer's environment while still using Northflank-hosted orchestration metadata, a distinct tier from the arrangement where the control plane itself moves onto customer infrastructure as a forward-deployed deployment, available at certain spend levels or by separate arrangement. That second tier removes dependency on vendor-hosted infrastructure altogether, which is a meaningfully different commitment than standard BYOC even though both get called "BYOC" in casual conversation.

The commercial terms attached to BYOC vary as much as the technical terms. Northflank published a pricing comparison in May 2026 and found that only one provider among those compared offered self-serve BYOC with publicly available pricing; other platforms offering BYOC required a sales process and did not publish rates. A feature that sounds identical across two vendor homepages can mean a same-day self-serve deployment on one and a multi-week sales cycle on the other, and that gap shapes how quickly a team can even test the claim before committing budget to it.

Provider Support for Customer-Cloud Deployment

The providers that genuinely support some form of customer-cloud deployment differ sharply in what BYOC means once a contract is signed: which clouds are supported, who runs the control plane, and whether the enterprise controls regulated teams need actually ship with it.

Northflank supports self-serve BYOC across AWS, GCP, Azure, Oracle, CoreWeave, Civo, on-premises, and bare-metal, with no enterprise sales process standing between a team and a working deployment. Isolation runtime is selectable per workload rather than fixed platform-wide: Kata Containers with Cloud Hypervisor, Firecracker, or gVisor. On Northflank's own managed cloud, CPU sandboxes run under microVM isolation, and GPU sandboxes use microVM isolation where nested virtualization is available, falling back to gVisor where it isn't. Enterprise customers can go a step further and place the control plane itself inside their own infrastructure as an air-gapped, forward-deployed setup, cutting the dependency on Northflank's managed cloud. Northflank is SOC 2 Type II compliant, and HIPAA coverage with Business Associate Agreements is available under Enterprise contracts.

Google's GKE Agent Sandbox takes a different shape because it runs on a customer's own GKE cluster. All compute stays inside the customer's Google Cloud account by construction rather than by vendor configuration. The feature reached general availability, and Google pairs it with Pod Snapshots, a GKE capability for checkpointing and restoring running pods, letting new environments provision from a snapshot and start in seconds rather than cold-booting from scratch. For teams running at extreme scale, Google also publishes Agent Substrate, a companion open-source project built for workloads that generate millions of sub-second tool calls, the kind of traffic that overwhelms a standard Kubernetes control plane. Because the customer owns the cluster, GKE Agent Sandbox inherits Google Cloud's existing compliance posture rather than requiring a separate certification path, and the customer retains ownership of cluster data throughout. For any enterprise already running workloads on GKE, this detail changes the economics of evaluation considerably: Agent Sandbox is offered at no extra charge in GKE beyond the normal compute a team already pays for, so testing it costs nothing more than the GKE resources it consumes.

AWS Bedrock AgentCore sits closer to the managed end of the spectrum, with a wrinkle in its compute options. The standard Runtime is fully AWS-managed serverless microVM compute running on AWS's own infrastructure, not the customer's account. A newer compute type, Instances, runs on AWS-managed EC2 inside the customer's own AWS account, integrating with CloudTrail for audit logging and falling under the standard AWS customer contract. By default, the microVM filesystem is ephemeral within a session, but AgentCore now offers managed session storage, generally available, that automatically persists filesystem state across stop and resume cycles, paired with a Memory component for short- and long-term recall across sessions. That persistence is a built-in, managed capability rather than something a team has to hand-build against S3. AgentCore fits best when a team's agents already live inside the Bedrock ecosystem, where the audit trail and the AWS contractual umbrella outweigh the gaps elsewhere in the feature set, but the underlying ephemeral-by-default state model still stays a structural constraint you design around, not a setting you flip.

Set side by side, the three approaches cover genuinely different starting points: Northflank for teams that want self-serve BYOC across a wide span of clouds without a sales cycle, GKE Agent Sandbox for teams already standardized on Google Cloud infrastructure, and AWS Bedrock AgentCore for teams whose agent stack is already built on Bedrock. Where the available sources don't cover a provider's BYOC posture in comparable detail, that gap is left as a gap rather than papered over with assumption.

The isolation technology inside the sandbox determines what the customer-cloud model protects

Moving the sandbox into a customer's own cloud account relocates the network perimeter, but it says nothing on its own about whether one tenant's code can reach another tenant's data once both are running on the same host. That's a separate axis, governed by the isolation technology inside the sandbox, and it has to be evaluated independently of the deployment model.

Standard containers isolate processes through Linux namespaces and cgroups, and every sandbox running this way shares the host's kernel. A vulnerability in that shared kernel becomes a shared risk across every sandbox sitting on the same host, regardless of whose cloud account the host happens to live in. gVisor takes a different approach: it intercepts application system calls through a user-space kernel, cutting down direct exposure to the host kernel without requiring hardware virtualization to do it. Northflank uses gVisor for GPU sandboxes on its managed cloud, and gVisor also serves as the primary isolation layer underlying GKE Agent Sandbox, which supports Kata Containers as well. MicroVM isolation, through technologies like Firecracker or Kata Containers paired with Cloud Hypervisor, goes further still: each sandbox gets its own guest kernel backed by hardware virtualization, so a compromise inside one sandbox's kernel doesn't reach the host or any neighboring sandbox. That boundary costs more in startup latency compared to container-only approaches, a tradeoff to weigh against the workload's actual risk profile rather than assuming one setting fits everything.

Why does this distinction matter more for AI agents than for ordinary workloads? Code written by a language model hasn't been reviewed by a human before it runs, and it may carry the fingerprints of a prompt injection or an outright malicious instruction buried in content the agent ingested earlier. Running that code under a shared-kernel container model means trusting namespacing to hold; running it under microVM isolation means trusting hardware virtualization instead, a meaningfully stronger guarantee for code nobody has actually read. Northflank lets you select isolation runtime per workload across its BYOC deployments, so you can apply microVM isolation to the agent executing arbitrary generated code while running a lower-trust-requirement workload under a lighter container model, instead of forcing one isolation level across the entire platform.

Putting the two axes together forms a clearer picture: deployment location and isolation technology are separate protections that must both be evaluated. If a team deploys its sandbox inside its own VPC but runs it under container-only isolation, it has moved the network boundary without touching the kernel trust boundary. BYOC paired with microVM isolation is a different protection model entirely than BYOC paired with shared-kernel containers, even though both configurations satisfy a checkbox that reads "runs in our own cloud account."

How statefulness and session persistence change the BYOC evaluation

For a single-task agent that reads a file, transforms it, and returns a result, statefulness barely registers as a concern. For an agent that runs across many steps, accumulating context, memory, and intermediate work over minutes or hours, it becomes one of the sharpest points of differentiation among providers. Session caps and state models are the primary architectural variable for a BYOC buyer running this kind of long-running workflow, and the providers covered here land in genuinely different places on it.

AWS Bedrock AgentCore's managed session storage, generally available as of mid-2026, persists filesystem state automatically across stop and resume cycles, with no need for a team to externalize state manually against S3 or any other store. Its Memory component adds built-in persistence for knowledge that needs to carry across sessions rather than just within one. That combination suits stateless or lightly stateful tool invocations well, but an agent that builds up substantial intermediate context across many steps still runs up against the structural fact that the default execution model is ephemeral, and persistence has to be deliberately engaged rather than assumed.

GKE Agent Sandbox, paired with Pod Snapshots, allows a running pod to be checkpointed and restored, so an agent's environment can resume from the point it was snapshotted rather than cold-starting. That capability comes with real caveats: external network connections terminate on restore and don't reconnect automatically, and certain application state, such as secrets and environment variables, has to be re-initialized rather than coming back automatically. That's a materially different capability than restoring an identical running process, so you need to account for what gets rebuilt versus what truly resumes.

A September 2026 comparison of sandbox providers framed the core question directly: what actually survives a pause, the filesystem only, the filesystem plus memory, or nothing at all, and that question shapes how a session gets structured from the first line of code. The gap between a provider that attaches a persistent volume and one that checkpoints memory state too is a real architectural difference, and vendor marketing language doesn't always make clear which side of that gap a given feature sits on. For computer-use agents in particular, the kind that drive a browser or desktop and build up session state across dozens or hundreds of interactions, a fully ephemeral sandbox means you rebuild environment context from zero on every restart. That compounds both latency and reliability risk the longer the task runs. The state model is a design constraint to settle before the architecture gets built around it, not an afterthought to patch in once an agent starts timing out in production.

What compliance certifications cover in a BYOC deployment

A SOC 2 Type II badge or a HIPAA attestation on a vendor's website describes the controls applied to a specific deployment model, and that scope doesn't automatically travel with every deployment option the same vendor offers. A certification earned against a vendor's managed infrastructure doesn't extend on its own to a BYOC or self-hosted deployment of the same underlying software, because the control boundary has moved. Northflank's enterprise guide states this directly: compliance requirements depend on the data involved and the deployment chosen, and picking a customer-owned infrastructure path doesn't by itself settle every compliance obligation a regulated team carries.

HIPAA is the clearest illustration. A Business Associate Agreement is required wherever a service processes regulated sensitive data on a customer's behalf, and a managed sandbox executing agent payloads carrying that kind of data will almost certainly cross that threshold. But the BAA has to name the specific service and the specific deployment configuration it covers. A BAA signed against a vendor's standard managed offering may not extend automatically to that same vendor's BYOC tier, or to a forward-deployed control plane arrangement, unless the agreement is written to cover that configuration explicitly.

AWS Bedrock AgentCore illustrates the same principle from a different angle. Running inside the customer's own AWS account through the Instances compute type brings real benefits: coverage under the existing AWS customer contract and integration with CloudTrail for audit logging. The ephemeral-by-default state model means a compliance review has to account for where agent state actually lives once it's externalized, as well as where the compute itself executes. Data residency adds a further layer that's easy to miss: execution location, storage location, backup location, log location, and control-plane metadata location are five separate questions, not one. If you choose a compute region, that doesn't automatically place every one of those other data types in that same region, especially when the control plane stays vendor-hosted even as workload execution moves into the customer's own cloud account. BYOC moves the needle substantially toward a team's own compliance posture, but it doesn't end the conversation there. The certification and the deployment model have to be checked together, every time, rather than assumed to match because the vendor's name is the same on both.