TL;DR
Run production AI agents on a platform that keeps them online through a regional or cloud outage, isolates the untrusted code they write, and gives them short-lived cloud credentials instead of stored keys. On Control Plane, agents run as standard workloads active-active across regions and clouds under a 99.999% SLA, untrusted code runs in Sandboxes that each get a dedicated Kata Containers microVM, and every action lands in a tamper-proof audit trail. Capacity AI right-sizes CPU and memory to actual usage, and customers typically see 30 to 50 percent lower compute costs compared with running directly on AWS, GCP, or Azure.
Two ways agents use Control Plane
Control Plane serves two distinct agent use cases.
- Agents operating infrastructure. The agent uses Control Plane as its target. It reads live infrastructure state through the Control Plane MCP server, proposes deployments, scaling changes, or configuration updates, and every change is written to the audit trail for human review. The worked example below follows this model.
- Agents executing untrusted code. The agent writes and runs code, scripts, or tools inside a Control Plane Sandbox. Each Sandbox runs in a dedicated Kata Containers microVM with its own guest kernel, so generated code stays behind a hardware-virtualization boundary. This is the use case sandbox-first tools such as E2B and Modal address.
The two are independent. A team can adopt one without the other, or use both: let an agent build and test code in a Sandbox, then ship the result as a production workload on the same platform.
Platform comparison
| Platform | Isolation | Where it runs | Compliance | Idle behavior | Billing model |
|---|---|---|---|---|---|
| Control Plane | Sandboxes: dedicated Kata Containers microVM. Workloads: cgroups, namespaces, and restricted syscalls and capabilities, with deny-by-default networking | AWS, GCP, and Azure natively, plus your own clusters, bare metal, or on premises; active-active across regions and clouds | PCI DSS Level 1, SOC 2 Type II, HIPAA, GDPR | Serverless workloads scale to zero; standard and stateful through KEDA; a suspended Sandbox costs storage only | Reserved CPU per millicore and memory per MB, right-sized by Capacity AI; no contracts or minimums |
| E2B | Firecracker microVM per sandbox | E2B cloud; BYOC on AWS, GCP, and Azure (Enterprise) | SOC 2 Type II; HIPAA BAA on request | Pause and resume with memory preserved; billing stops while paused | Per-second billing for active sandbox runtime |
| Modal | gVisor or a VM runtime; GPU sandboxes on gVisor only | Modal cloud only | SOC 2 Type II; HIPAA BAA on Enterprise | Sandboxes end on timeout or idle timeout; up to 24 hours each | Per-second CPU, memory, and GPU metering |
| Daytona | Container, Linux VM, or Windows VM sandbox classes | Daytona cloud; bring your own compute (Enterprise) | SOC 2 Type II, ISO 27001, HIPAA, GDPR | Auto-stop after 15 minutes of inactivity by default | Per-second billing for vCPU, memory, and storage |
E2B, Modal, and Daytona provide the sandbox. The agent’s production runtime, identity, networking, and failover live on another platform. Control Plane runs both on one platform.
How it works
Sandboxes: where agents build and run untrusted code
- Create. A Sandbox is created from the Sandbox Manager in the console. It provisions a persistent workspace and a dedicated Kata Containers microVM.
- Work. The agent, or the engineer working with it, connects from a browser IDE and terminal, or from VS Code, Cursor, or SSH through
cpln sandbox connect. Every toolbox image includes the Claude Code CLI. - Suspend. Suspending a Sandbox scales it to zero and keeps its workspace, so it costs storage only until it resumes.
- Delete. Deleting a Sandbox removes its workspace. The audit trail persists independently.
Production agents: where agents serve users
A production agent runs as a standard Control Plane workload. It is isolated with cgroups, namespaces, and restricted syscalls and capabilities, has no access to the Kubernetes API, and starts with deny-by-default networking, so it reaches only the services you allow. Service-to-service traffic uses mutual TLS. Autoscaling adds replicas as load grows, serverless workloads scale to zero when idle, and Capacity AI right-sizes each replica’s CPU and memory between the minimum and maximum you set, based on historical usage.
For agents that need a private VPC or an on premises service, Cloud Wormhole opens that path without a VPN and without installing a client on either end.
Worked example: an MCP-connected agent deploying across two regions
An agent connected to Control Plane through MCP is asked to deploy a service to two regions for latency and redundancy.
- Context gathering. The agent reads the current infrastructure state through MCP: existing services, network policy, and identity configuration. It works from a live view of what is running, not a static template.
- Plan. The agent proposes the change: deploy the service as a standard workload to a Global Virtual Cloud with one location on AWS in the US and one on GCP in Europe, using Universal Cloud Identity to reach the services it needs in both clouds without long-lived keys in code.
- Human checkpoint. The plan is written to the audit trail. An engineer reviews it, confirms sizing, and approves.
- Deploy. Control Plane runs the workload in both locations at once. A built-in global endpoint routes each request to the nearest healthy location.
- Private access. One location needs a database in the customer’s data center. Cloud Wormhole opens that path with no VPN tunnel or client install.
- Verify. The agent checks both locations and reports status through MCP. The full sequence, from plan to approval to deployment, is recorded in the audit trail.
- Steady state. The service runs active-active. If either region fails, traffic moves to the healthy one without a runbook, and the 99.999% SLA covers workloads running at least two replicas in at least two locations.
During the October 20, 2025 AWS outage in us-east-1, affected Control Plane workloads were active and running in healthy locations within 10 seconds, with no customer downtime, according to Control Plane internal incident telemetry (Beyond Backups). That is the operating model: agents propose and execute changes, humans set policy and review the trail, and the platform keeps the result online.
FAQ
What is an AI agent sandbox?
An AI agent sandbox is an isolated environment where an agent can run code, call tools, and use a filesystem without access to the host or to other workloads. On Control Plane, each Sandbox runs in a dedicated Kata Containers microVM with its own guest kernel and a persistent workspace.
How do you secure AI agent execution?
Run untrusted, model-generated code in a Sandbox, which on Control Plane always gets a dedicated Kata Containers microVM. Run the production agent as a workload isolated with cgroups, namespaces, and restricted syscalls and capabilities, with deny-by-default networking and mutual TLS. Universal Cloud Identity gives the agent short-lived, least-privilege access to services such as S3, BigQuery, Cosmos DB, or RDS instead of stored keys, and every change lands in a tamper-proof audit trail.
Can AI agents access private networks?
Yes. Agents that need a private VPC or an on premises network reach it through Cloud Wormhole, which opens the connection without a VPN or a client installed on either side.
What happens to production agents during a cloud outage?
A production agent deployed to two or more locations runs active-active, and the built-in global endpoint routes requests to the nearest healthy location. If a region or provider fails, traffic moves to the remaining locations automatically, and the 99.999% SLA covers workloads running at least two replicas in at least two locations.
Next steps
- Read the Sandboxes guide and the AI agents overview in the docs.
- Sign up free, or talk to the Control Plane team about running agents in production.