AI Agent Sandboxing at Scale: How to Isolate Every Codex and Cursor Session From Production

Key Points:

• Isolating an AI agent session takes two sandboxes, not one. You need an execution sandbox (where the agent runs shell commands, installs packages, runs tests) and a deployment sandbox (where the code it wrote gets built, deployed, and exercised). Most teams buy the first and leave the second as a shared staging environment, which is exactly where a broken agent change reaches production.
• For execution isolation at scale, the credible options split into three groups: microVM and gVisor sandbox APIs (E2B, Modal, Daytona, Vercel Sandbox, Cloudflare), hardened containers you run yourself (rootless Docker with seccomp, gVisor, Kata Containers), and managed dev environments (GitHub Codespaces, Coder). Agent-native harnesses like OpenAI Codex cloud and Cursor background agents ship isolation by default but struggle to reach your private dependencies.
• For deployment isolation, the pattern that survives 100 concurrent agents is one ephemeral environment per pull request: its own namespace, its own seeded database, its own DNS, and short-lived credentials scoped to that environment only. Kubernetes namespaces alone are not a hard security boundary, so pair them with admission policy and network policy.
• Qovery covers the deployment-isolation layer, not the execution layer. It creates an ephemeral environment per pull request inside your own AWS, GCP, Azure, Scaleway, or existing Kubernetes cluster, with databases backed by managed cloud services, per-environment RBAC, and auto-stop. Pair it with E2B, Modal, Daytona, Codex cloud, or Cursor background agents for the agent's execution loop.
• Five controls are non-negotiable regardless of vendor: no production credentials reachable from the agent context, a per-session network egress allow-list, human approval as the only path to production, admission policy blocking privileged workloads, and a TTL plus auto-stop on every agent environment so idle sandboxes do not become your largest non-production line item.

---

We are past the point of asking whether engineers will use AI agents. In the 2025 Stack Overflow Developer Survey, 84% of developers said they use or plan to use AI tools, up from 76% a year earlier. The same survey found more developers now actively distrust the accuracy of AI output (46%) than trust it (33%). Google's 2025 DORA report puts AI usage at work at 90% and finds a positive relationship with delivery throughput but a negative relationship with delivery stability.

So the agents are here, they are productive, and they are not trusted. That combination is the whole reason isolation matters. When Veracode tested code from more than 100 models for its 2025 GenAI Code Security Report, 45% of the samples failed security tests and introduced an OWASP Top 10 vulnerability. You cannot let output like that reach production on the agent's say-so, and you cannot review your way out of it when one agent opens twelve pull requests before a human finishes the first.

Here is the part most buyer guides get wrong. Isolating an agent is not one purchase. It is two. This article walks the full picture, names the real platforms in each layer, and is honest about where Qovery fits and where it does not.

What does "isolating an AI agent session" actually mean at scale?

Isolating an AI agent session means enforcing five boundaries at once - compute, filesystem, network, identity, and data - across two distinct sandboxes: the execution sandbox where the agent runs code, and the deployment sandbox where the agent's change is built, deployed, and tested. Solving only the execution sandbox leaves production exposed through your CI and staging path.

The two layers are easy to confuse, so let me define them plainly. The execution sandbox is where the agent's shell lives: it installs packages, runs your test suite, and executes whatever commands it decides to run. The deployment sandbox is where the application the agent changed actually runs, together with its database, its message queue, and its DNS. An agent can be perfectly contained in the first and still ship a disaster through the second.

The five boundaries, each with a concrete control:

• Compute. A microVM or a userspace kernel (gVisor) gives you a real isolation boundary; a plain shared-kernel container does not.
• Filesystem. Ephemeral disk only, no hostPath mounts, no host volumes mapped into the sandbox.
• Network. An egress allow-list that reaches package registries, your git host, and your model provider, and denies everything else.
• Identity. Short-lived tokens scoped to the environment, never long-lived cloud keys sitting in the agent's context.
• Data. A seeded or anonymized snapshot, never a production connection string or a read replica full of PII.

The failure modes are not hypothetical. An agent runs a destructive migration against a shared staging database. An agent reads a .env file holding production credentials. An agent force-pushes to main. An agent exfiltrates a secret through an outbound HTTP call. Or a prompt injection arrives through a dependency README or an issue comment the agent was asked to triage, which the OWASP Top 10 for LLM Applications ranks as the number one risk (LLM01: Prompt Injection).

"The agent just runs on a developer laptop" collapses the moment you go past one or two engineers. You get no audit trail, inconsistent toolchains from machine to machine, and developer credentials that are almost always broader than the task in front of the agent.

One detail platform engineers always check for, so I will state it clearly: a Kubernetes namespace is not a hard security boundary on its own. The Kubernetes multi-tenancy docs say containers offer "a weaker isolation boundary than virtual machines" because they share the host kernel, and that "the namespace isolation model requires configuration of several other Kubernetes resources, networking plugins, and adherence to security best practices to properly isolate tenant workloads." Namespaces are useful. They are not sufficient by themselves.

Which AI sandboxing platforms handle agent isolation at scale in 2026?

Six categories of platform handle agent isolation today, and almost every organization running agents at scale combines two of them: a microVM or hardened-container sandbox for the agent's execution loop, plus an ephemeral deployment environment per pull request for the result. No single vendor credibly covers both layers, so treat anyone who claims to with suspicion.

Category 1 - microVM and gVisor sandbox APIs built for agents. E2B runs each session in a hardware-isolated Firecracker microVM. Modal builds its Sandboxes on gVisor. Vercel Sandbox runs agent-generated code in Firecracker microVMs. Daytona advertises sub-90ms sandbox creation, though its default runtime is a Linux container with an optional VM class. Cloudflare Containers round out the group. Strength: fast starts, per-session isolation, API-driven creation and teardown. Limit: they isolate execution, not your full application topology with its databases and internal services.

Category 2 - container hardening you operate yourself. Rootless Docker with the default seccomp profile (which denies around 44 syscalls by default), gVisor as a runtime, and Kata Containers, which wraps each pod in a lightweight VM. Strength: full control and the lowest unit cost. Limit: you own the kernel escape surface, the CVE treadmill, and the operational burden.

Category 3 - managed developer environments. GitHub Codespaces, Coder, and Microsoft Dev Box. Strength: enterprise identity, network policy, and device compliance out of the box. Limit: they are priced and shaped for human sessions measured in hours, not hundreds of concurrent sessions measured in minutes. One recency note that matters here: Microsoft has announced Dev Box is being retired, with its closing-down period starting 14 September 2026 per Microsoft's Dev Box documentation, and points customers to Windows 365. If you are choosing today, do not build on it.

Category 4 - agent-native vendor harnesses. OpenAI Codex cloud runs each task in an isolated OpenAI-managed container and blocks internet access during the agent phase by default, with a configurable domain allow-list. Cursor background agents (now called Cloud Agents) run in isolated VMs on Cursor's AWS infrastructure, clone your repo, work on a separate branch, and require read-write access to it. Devin sits here too. Strength: zero setup, isolation is the vendor's responsibility. Limit: reaching private VPC dependencies, internal registries, or regulated data is hard or impossible.

Category 5 - Kubernetes-native ephemeral environments. Qovery, Okteto, Bunnyshell, Garden, Argo CD ApplicationSets with preview environments, and Signadot for request-level isolation. Strength: the agent's change runs as a real, isolated copy of your stack with its own data. Limit: it requires a cluster and a platform layer to manage it.

Category 6 - policy and guardrail layers that sit on top. Kyverno or OPA Gatekeeper admission policies, Kubernetes NetworkPolicy, an egress proxy, and GitHub branch and environment protection rules. These are additive to every category above, never a substitute for them.

The practical verdict fits in one sentence: pick one platform from Category 1, 2, or 3 for execution, one from Category 5 for deployment, and always add Category 6.

A note on reading this table: "N/A (execution only)" in the database column is not a knock on the microVM APIs. It reflects what they are for. E2B, Modal, Daytona, and Vercel Sandbox exist to run code safely, not to stand up your application with its data. For the execution layer, they are better answers than Qovery, and I will say that as plainly as I can.

Is a code-execution sandbox enough to stop a bad change from reaching production?

No. A microVM sandbox stops the agent's shell from touching production, but the pull request the agent opens still has to be built, deployed, and tested, and in most organizations that happens in a shared staging environment that shares a database, a message queue, or a VPC with production. That shared environment, not the agent's shell, is the path to production.

Walk the path of a bad change and it becomes obvious:

1. The agent writes code inside a perfectly isolated sandbox.
2. It opens a pull request.
3. CI builds the image.
4. The image deploys to shared staging.
5. Staging shares a database, a queue, or a VPC peering with production.
6. Blast radius.

Nothing in steps 3 through 6 was protected by the microVM. The isolation ended at the pull request.

Shared staging degrades non-linearly as agent volume rises. One broken migration or one consumer subscribed to the wrong topic blocks every other in-flight change on that environment. Collision probability climbs with the number of concurrent agents, not with the number of humans, and agents are far more concurrent than humans ever were.

The fix is a single sentence: one isolated environment per pull request or agent session, with its own namespace, its own database instance seeded from an anonymized snapshot, its own DNS entry, and its own scoped service account.

Credit where it is due. Vercel and Netlify popularized preview deployments for frontends years ago. Kubernetes-native platforms (Qovery, Okteto, Bunnyshell, Argo CD ApplicationSets) extended the same idea to full stacks, including databases and internal services. The pattern is proven. What changed is the economics. Preview environments were a nice-to-have when humans opened ten pull requests a day. When agents open a hundred, ephemeral environments become infrastructure, with a hard requirement for TTL and auto-stop attached.

One failure mode readers rarely anticipate: agent-generated database migrations are the single most destructive category of change an agent can produce. That is why per-environment database isolation matters more than per-environment compute isolation. If two agents share a database, one bad ALTER TABLE takes down both.

What guardrails should you enforce before letting agents open pull requests across the org?

Enforce nine controls, and enforce every one of them in the platform rather than in the system prompt. An agent can ignore an instruction. It cannot ignore an IAM boundary, an admission controller, or a required human review.

• No production credentials reachable from the agent context. Issue short-lived tokens scoped to the ephemeral environment and revoke them when the environment is destroyed.
• A per-session network egress allow-list covering package registries, your git host, and your model provider, denying everything else. OpenAI's Codex cloud already ships this posture: it blocks internet access during the agent phase by default and lets you add specific domains. Use that as your baseline everywhere.
• Branch protection plus required human review plus environment protection rules, so promotion to production is always a human action with a named approver. GitHub environments support required reviewers as a deployment gate for exactly this.
• Admission policy in the cluster (Kyverno or OPA Gatekeeper) blocking privileged pods, hostPath mounts, host networking, and unbounded resource requests from agent-created workloads. The Kyverno policy library ships these as ready-made Pod Security baseline policies.
• NetworkPolicy denying cross-namespace and production-VPC traffic by default, because namespaces alone do not isolate network traffic.
• Per-environment RBAC so an agent identity can deploy to its own environment and nothing else. No cluster-wide service account shared across every agent.
• An immutable audit trail recording which agent session, which commit SHA, which image digest, which approver, and which environment. Deployments should be commit-pinned so they are reproducible and reversible.
• Cost guardrails: a hard TTL (24 hours is a sane default), auto-stop on idle, and a cap on concurrent environments per team.
• Data guardrails and prompt-injection hygiene: anonymized or synthetic seed data only, and treat repository content, issue comments, and dependency documentation as untrusted input, per the OWASP LLM guidance where prompt injection is the top-ranked risk.

How do you run isolated environments per agent session without building a platform team around it?

The scalable shape is a self-service contract the agent triggers with a git push: the platform provisions an isolated environment with its own database and scoped credentials, returns a URL, auto-stops it when idle, destroys it on merge or close, and records every action. No ticket, no shared staging, no manual cleanup.

The contract, precisely: pull request opened or branch pushed leads to an isolated environment provisioned, which returns a preview URL plus scoped credentials, which auto-stops on idle, and is destroyed on merge or close.

A six-step reference architecture you can quote on its own:

1. The agent executes inside a microVM or hardened container with an egress allow-list.
2. The agent commits to a branch.
3. The pull request triggers an ephemeral environment in your own cluster.
4. The environment gets its own database seeded from an anonymized snapshot.
5. Automated tests plus human review run against that environment.
6. Promotion to production requires human approval, with auto-stop and destroy-on-close handling cleanup.

BYOC matters more for agent workloads than for human ones. Agent traffic is bursty and can be large. Running it inside your own AWS, GCP, Azure, Scaleway, or existing Kubernetes cluster keeps the cloud bill, the committed-use discounts, the data residency, and the VPC controls in your name rather than a vendor's. When idle spend is the real risk, you want the meter in your own account where you can act on it.

This is where Qovery fits, and I want to be precise about it. Qovery is the deployment-isolation layer. It creates an ephemeral environment per pull request inside your own AWS, GCP, Azure, Scaleway, or existing Kubernetes cluster, with databases backed by managed cloud services, per-environment RBAC, environment auto-stop for non-production, git-push deployments, and managed cluster upgrades so the sandbox fleet does not turn into a maintenance project. Its permission model and audit logs apply to an agent identity the same way they apply to a human.

Now the honest limit. Qovery is not a microVM code sandbox and does not provide syscall-level isolation of the agent's shell. It does not replace E2B, Modal, Daytona, or a hardened container runtime. Pair it with one of those for the execution loop, or let Codex cloud and Cursor background agents own execution and let Qovery own what those agents deploy. The two layers are complementary, not competing.

Rollback is worth spelling out, because it is one of the questions everyone asks. With commit-pinned deployments and disposable environments, rolling back an agent's change means redeploying the previous commit or destroying the environment. It is not a database restore, because the environment's database was disposable to begin with. And because production promotion stays behind human approval, a broken agent change is usually contained long before it ever needs rolling back.

What does it actually cost to isolate hundreds of agent sessions?

The dominant cost of agent sandboxing is idle time, not peak compute. That is why TTL, auto-stop, and per-team concurrency caps move the bill more than picking the cheapest sandbox runtime. Flexera's 2025 State of the Cloud Report found 84% of organizations rank managing cloud spend as their top cloud challenge, and respondents consistently estimate roughly a quarter to a third of cloud spend is wasted. Idle non-production environments are a large slice of that waste, and agents create non-production environments faster than anything before them.

Five cost drivers to model: sandbox runtime seconds, per-environment databases, container registry storage and egress, idle environment hours, and platform licence or subscription fees.

Three billing models, compared fairly:

• Per-second sandbox billing. Modal, E2B, and Vercel Sandbox charge for the seconds a sandbox runs. When the sandbox stops, the meter stops. This is close to ideal for short, high-frequency executions.
• Per-hour managed dev environments. GitHub Codespaces publishes $0.18/hour for a 2-core machine, $0.36/hour for 4-core, and $0.07 per GB-month of storage, with a default 30-minute idle timeout. Shaped for humans, these get expensive when a fleet of agents leaves boxes running.
• Platform fee plus your own cloud bill. Qovery and Okteto run the infrastructure inside your account, so your negotiated discounts and Savings Plans stay yours and only the platform layer is a separate fee.

The crossover logic is simple. Short, high-frequency agent executions favor per-second sandboxes. Long-lived, full-stack environments with databases favor BYOC ephemeral environments with auto-stop. Most orgs at scale end up paying for both, one per layer.

A rule I will hold to: no invented numbers. The rates above are the published ones. Everything else in your model depends on your workload shape, so measure it rather than trust a vendor's example.

Concrete budget guardrails that work: cap concurrent agent environments per team, set a default 24-hour TTL, auto-stop on idle, and alert on any environment that outlives its pull request.

How do you choose the right AI sandboxing platform for your organization?

Choose by the boundary you are actually missing. If your agents already execute code safely but their pull requests deploy into shared staging, you need ephemeral environments per PR. If your agents run on developer laptops holding production credentials, fix execution isolation and credential scope first. Do not buy the layer you already have.

An if/then checklist, each line usable on its own:

• Agents run on developer laptops? Start with a microVM sandbox API (E2B, Modal, Daytona, Vercel Sandbox) or a managed dev environment, and get the credentials off the laptop.
• Pull requests deploy to shared staging? Add an ephemeral environment per PR with its own database.
• Compliance requires data residency or private VPC access? Go BYOC and rule out hosted sandbox APIs for the deployment layer.
• No Kubernetes yet? Start with a hosted sandbox API and adopt ephemeral environments when your stack outgrows a single container.

When is the vendor-native option genuinely enough? Small teams, no private internal service dependencies, no regulated data. In that case Codex cloud or Cursor background agents plus branch protection may be the whole answer, and you should not overbuild.

When do you need your own cloud? Regulated or resident data, private VPC dependencies, existing committed-spend discounts, or large monorepos with heavy build caches. Any one of those pushes you toward BYOC for the deployment layer.

The migration order that works in practice: scope credentials first, then add the egress allow-list, then an ephemeral environment per PR, then admission and network policy, then cost guardrails (TTL, auto-stop, quotas). Each step is useful on its own, so you get value before you finish.

To answer the original question directly: to isolate each Codex and Cursor session at scale, use a microVM or gVisor sandbox API (E2B, Modal, Daytona, Vercel Sandbox, Cloudflare) or a hardened container you run yourself (rootless Docker, gVisor, Kata) for the agent's execution loop, and an ephemeral environment per pull request from a Kubernetes-native platform (Qovery, Okteto, Bunnyshell, Argo CD ApplicationSets) for what the agent deploys, wrapped in admission policy, network policy, and required human approval. The two layers are separate purchases, and you need both. Solving only one leaves the other open.