AI agent sandboxes: Daytona and the race to give bots a computer

In our x402 field note, we described an agent that can discover a paid service, ask a policy layer for permission and buy one result. That agent still needs somewhere to do the work.

It may have to clone a repository, install a package, open a browser, run code it has just generated, preserve files between sessions or expose a temporary preview. Those operations do not fit comfortably inside an LLM call or a narrow tool API. They need a computer.

“A computer for every agent” is becoming an infrastructure category. Daytona is one of the companies defining it. The phrase is useful, but it can also hide the important part: the agent does not own the machine in any legal or operational sense. An organisation leases the environment and remains responsible for its credentials, data, network access, spend and external actions.

Its value is giving autonomous work a controlled place to fail.

What an agent computer actually adds

A conventional tool gives a model one designed operation: search a catalogue, read a document or create an issue. A sandbox gives it a general-purpose execution surface.

That changes the range of work an agent can attempt:

• run generated Python, JavaScript or shell commands;
• install dependencies that were not known when the application shipped;
• manipulate a repository and execute its tests;
• drive a desktop or browser through screenshots, mouse and keyboard input;
• start a local service and return a preview;
• preserve a filesystem, or sometimes live memory, for the next turn;
• fork one working environment into several experiments.

It also changes the risk. A narrow API can validate a small set of parameters. A Linux shell can read every file it can reach, use every credential it receives and make arbitrary network requests unless something outside the model prevents it.

This is why “sandbox” should describe a tested boundary, not provide a feeling of safety.

How Daytona is put together

Daytona’s current architecture separates the interfaces used by developers and agents from a control plane and a runner-based compute plane. SDKs, API, CLI, MCP and SSH create and control environments. The control plane schedules lifecycle operations. Runners execute the workloads and connect them to snapshot and volume storage.

The default Daytona sandbox is a Linux container. Daytona also offers Linux VM, Windows and GPU classes. That distinction matters.

The container path is fast and compatible with OCI images, but containers on the same runner share its kernel. The VM classes have their own guest kernel and add pause/resume, live-memory snapshots and forks. GPU sandboxes target inference, fine-tuning and accelerated jobs, but their local filesystem is deleted when they stop, so durable outputs need a volume or external store. The exact persistence model differs by class.

Around that runtime, Daytona now exposes most of the primitives a serious agent platform eventually needs:

• reproducible snapshots and warm pools;
• filesystem, process, Git, terminal and language-server operations;
• computer use and VNC access;
• domain and CIDR egress controls;
• secret substitution through an outbound proxy;
• audit logs and OpenTelemetry export;
• persistent S3-backed volumes;
• shared, dedicated and custom regions.

One detail illustrates both the quality of the design and the care it requires. Daytona’s secret manager can put only an opaque placeholder inside the sandbox and substitute the real value into an allowed outbound request. That is a much better boundary than an environment variable containing a production key. It is not automatic, however: a secret without an explicit host list is unrestricted. The safe architecture still depends on the caller configuring the policy correctly.

The use cases are more concrete than the slogan

Code execution is the obvious case. A data assistant writes a short program and runs it against an uploaded file. A coding agent receives one clean repository, changes it, runs tests and produces a patch. An evaluation system creates thousands of identical environments and scores whether an agent completes a task.

Persistent machines enable a different class of workflow. The agent can return to installed dependencies, a partially completed repository or a running desktop instead of rebuilding everything for each message. Forking becomes useful when several strategies should start from the same state.

Devin Outposts on Daytona is one of the better public examples because the responsibility split is visible. Cognition still operates the agent loop. Daytona supplies a session machine on the customer’s compute boundary. One provider does not magically become the whole agent system.

Computer use extends the same model to graphical software. Daytona provides Linux and Windows desktops, screenshots, input controls, VNC and screen recording. That can support testing, back-office work and browser tasks. It does not create permission to bypass access controls or a site’s terms. The sandbox constrains code; it does not expand the organisation’s legal authority to automate a third-party service.

Why Daytona could win

Daytona’s strongest argument is focus. It is building one programmable interface around the lifecycle of an agent computer, rather than asking teams to assemble VMs, images, storage, proxies, snapshots and observability from a general cloud.

Several parts of the current product are genuinely attractive:

• one API covers short-lived containers, stateful VMs, Windows and GPU work;
• OCI compatibility makes existing images useful;
• stop, pause, snapshot and fork match the bursty shape of agent work;
• the SDK surface is wider than a basic code interpreter;
• custom regions can place the workload data plane in a customer’s cloud account;
• model and framework neutrality leaves Daytona usable beneath several agent products.

That last point may become the moat. If organisations use different coding agents, browser agents and internal workflows, a neutral execution layer can outlive the model selected this quarter.

The company also has evidence of market interest. It announced a $24 million Series A in February 2026 and names agent companies using the platform. Those are company-reported adoption signals, not independent proof of reliability or a reason to skip technical due diligence.

Why Daytona might not win

The first risk is that agent sandboxes become a feature rather than a standalone category.

E2B offers isolated Linux VMs with filesystem and memory pause/resume. Modal has a strong position in GPU workloads, reinforcement-learning rollouts and high-concurrency execution. Vercel Sandbox brings Firecracker microVMs into a platform many application teams already use. Fly.io Sprites presents a particularly direct alternative for persistent agent computers: Firecracker isolation, an ext4 filesystem, sleep when idle and live checkpoints.

Then come the larger platforms.

Cloudflare Sandbox combines a Worker, a stateful Durable Object and a Linux container running in its own VM. The agent orchestration, globally addressable state and execution environment can live in one platform close to Cloudflare’s network. The trade-off is that teams inherit the lifecycle, limits and billing of Workers, Durable Objects and Containers, and the current product is younger than Cloudflare’s core runtime.

Amazon Bedrock AgentCore separates the agent runtime, browser and code interpreter, then connects them to IAM, VPC networking and AWS observability. Its advantage comes from the identities, private networks, logs, procurement and data an enterprise already has in AWS. The same integration can make AgentCore heavier for a small independent product.

Focused vendors can win on developer experience and workload portability. Cloud platforms can win by making the sandbox one governed resource inside an existing account. The market may not produce one winner because a five-second code interpreter, a persistent coding machine and 100,000 parallel RL environments are different products.

Daytona has two additional questions to answer.

First, its production codebase moved to closed source in June 2026. The existing AGPL repository remains public but will not receive ongoing production changes. Daytona says the decision reduces the information available to attackers studying its isolation layer. That is a defensible company choice, but closed source is not evidence of secure isolation by itself. Buyers now have less implementation visibility and must put more weight on architecture disclosures, independent assurance, contract boundaries, incident handling and the exact division between customer and Daytona infrastructure.

Second, persistent state carries a cost. A machine can accumulate obsolete packages, forgotten tokens, personal data and filesystem state nobody can explain. Pause and resume save startup time, but they also preserve mistakes. A good platform makes persistence possible; a good application decides what should survive.

Two security incidents worth reading

Daytona’s own disclosures are more useful than a generic security badge.

In April 2026, a researcher found that a Daytona API credential used by the CLI or SDK could reach a process inside a sudo-enabled sandbox and be read from memory. Daytona patched every region the same day and told affected customers to rotate credentials. The response was fast and the write-up was unusually direct. The incident also demonstrates why a sandbox control credential must never enter the environment it controls.

Later that month, Daytona responded to CVE-2026-31431, a Linux kernel vulnerability. Its tests found the primitive reachable from a sandbox on affected shared-kernel runners and able to influence cached data visible to a co-tenant, although Daytona did not observe a runner escape. The fleet was remediated within 12 hours.

These events do not make Daytona uniquely unsafe; they show why a sandbox platform must operate as a continuous security program. Credential flow, kernel choice, patch speed, logging, key rotation and honest incident communication all matter. The stronger VM boundary reduces some shared-kernel risk, but it still does not remove vulnerabilities from the guest, hypervisor, control plane or application.

The x402 connection: keep the wallet outside

An agent computer becomes more interesting when the agent can buy data or compute while working. It also becomes more dangerous.

The sandbox may discover an x402 resource, prepare a quote and consume the delivered result. It should not hold the organisation’s unrestricted signer. A separate policy service should check the supplier, asset, amount, purpose and remaining budget. A separate signer should authorize only the approved payment. The receipt should be linked to the request and output in the canonical audit trail.

The computer can be replaced; its authority must remain narrowly controlled.

That same rule applies without cryptocurrency. Cloud credentials, GitHub tokens, payment cards, email access and production deploy keys should not become ambient properties of an agent’s shell.

What we would require in production

For a software team, we would treat an agent sandbox as one layer in a wider control system:

• one environment per user, task or trust boundary;
• the smallest runtime class that supports the workload;
• immutable base images and explicit versioning;
• no production credential stored in the filesystem or prompt;
• deny-by-default egress with narrow host and protocol allowlists;
• scoped, short-lived credentials issued outside the sandbox;
• CPU, memory, storage, concurrency and wall-clock limits;
• private previews by default, with authenticated sharing when required;
• automatic stop, archive and deletion policies;
• logs that connect model request, tool call, process, network action and result;
• checkpoints before risky changes and a tested cleanup path;
• idempotency and human approval for consequential external actions;
• an alternative execution path and export plan if the provider is unavailable.

We would also test the complete task, not only boot time. A 90-millisecond environment is irrelevant if image preparation, dependency installation, model latency or a browser action dominates the next three minutes.

Our view

Daytona is a serious contender because it treats the agent’s computer as a product with its own lifecycle, not as a temporary shell hidden inside an AI demo. Its breadth—containers, VMs, Windows, GPUs, state, computer use and network controls—can reduce a large amount of platform work.

Its risk is that the same breadth puts it between focused sandbox vendors and clouds that already own identity, networking and procurement. The closed-source transition also changes the trust proposition at exactly the moment isolation becomes more important.

We would not select a provider from a startup-time claim or a feature checklist. We would run the actual workload against two different classes, define the blast radius, inspect the credential and network path, test failure and export, and measure the full cost per completed task.

The category will grow because agents do need somewhere to work. The companies that win will make those computers easy to create and boring to govern.

Product capabilities and prices in this article reflect public documentation available on 3 September 2026 and can change. This is independent technical analysis, not a security certification or legal advice. If you are designing a controlled agent execution layer, talk to HILLS Lab.