# Every Useful Agent Eventually Needs a Computer I started with Grok Bot and ended up looking at the infrastructure underneath every agent that is allowed to do real work. Daytona is one of the more interesting bets, but this market will be won on trust, not demos. Author: Hrvoje Pavlinovic Published: 2026-09-03 Canonical: https://hrvoje.pavlinovic.com/blog/every-useful-agent-eventually-needs-a-computer Tags: AI Agents, Sandboxes, Daytona, Infrastructure, Security Use this Markdown when pasting the article into Codex, Claude, ChatGPT, a gist, or a personal runbook. I went down this rabbit hole while writing the previous article about x402. The idea of software paying other software is interesting, but after a while I realised I was skipping a step. Once an agent pays for some compute or downloads a file, it needs somewhere to continue working. It needs a filesystem, processes, network access, maybe a browser session, and probably some state that survives longer than one prompt. In other words, it needs a computer. It does not have to look like a desktop, and in many cases it probably should not, but the usual computer problems are still there. Files get left behind, processes crash, credentials leak and bad dependencies do bad things. I started reading about Grok Bot, then Daytona, then E2B, and eventually ended up comparing half the cloud industry. The category is still young and the terminology is all over the place, but there is a real product hiding under the demos. ## One computer, several bots [Grok Bot](https://docs.x.ai/grok-bot/overview) makes the idea easy to understand. The bot can browse, use tools, keep files and remain logged into websites. It feels much closer to giving someone a laptop than calling an API with a large prompt. I liked that immediately. Then I read that a user's bots share one persistent cloud VM, including the files and browser sessions. That choice makes sense from the user's side. You don't want to log in again every time you create a bot, and it is useful when one bot can see the work left by another. Still, the names in the sidebar are not real isolation boundaries. If one bot installs a compromised package or drops a token into a file, another bot on the same machine can inherit the problem along with the useful state. xAI documents [approvals and security controls](https://docs.x.ai/grok-bot/approvals-security-and-privacy), which helps, but I would not rely on approval dialogs for much. We all learn to click through them, and the visible command is not always a good description of what installed software will do afterwards. So I like "a bot owns a computer" as a way to explain the product. If I were putting company credentials inside it, I would ask different questions: which bot can read which file, which domains can it reach, how long does the state live, where are the logs, and can I delete the environment without losing the evidence I need to understand a failure? ## Why Daytona caught my attention Daytona is building exactly this layer. The company [raised a $24 million Series A](https://www.daytona.io/dotfiles/daytona-raises-24m-series-a-to-give-every-agent-a-computer) and uses the very direct line "give every agent a computer." The founders previously built Codeanywhere, so remote environments are not a new fashion they discovered last month. The product covers containers, VM-backed isolation, Windows, GPU machines, snapshots and persistent environments. I can see the appeal for coding agents. Start from a known image, let the agent make a mess, fork the environment when there are two possible solutions, and keep the version that worked. The best detail I found was in their [secret handling](https://www.daytona.io/docs/en/secrets/). Instead of placing the real key inside the sandbox, Daytona gives it a placeholder. When the sandbox makes an HTTPS request to an allowed host, a proxy replaces the placeholder with the actual secret. A random shell command has less chance of printing the key or sending it to another domain. I would still want to test the edge cases, especially with custom clients and anything that bypasses the proxy, but the design is going in the right direction. Credentials should be attached to a specific action and destination, rather than sitting in an environment variable waiting for every process on the machine. One wording issue in the docs made me pause. The [sandbox page](https://www.daytona.io/docs/sandboxes) mentions a dedicated kernel, while the [architecture page](https://www.daytona.io/docs/en/architecture/) describes Linux containers and namespaces as the default. A conventional container shares the host kernel. Daytona also offers a VM class, so this may simply be imprecise documentation, but for a security product that sentence should be exact. I would use a fast container for code I trust. If customers can send arbitrary code and an escape could cross account boundaries, I would pick the VM option and ask Daytona to spell out what sits underneath it. ## The security incident is worth reading In April 2026, Daytona disclosed a problem with its default sandbox image. Passwordless sudo was enabled and a platform credential was visible in the memory of a process inside the sandbox. Anyone with shell access could read it and act as the account that launched the machine. Their [incident report](https://www.daytona.io/dotfiles/updates/security-advisory-api-credential-exposure-in-sandboxes) says the issue was reproduced and patched across all regions in under five hours. They found no evidence of abuse, but also admitted they could not prove it had never happened because requests made with the stolen credential would look legitimate. That is a serious design mistake. It also tells me more about the company than another page full of security claims. They explained the failure, moved quickly and did not invent certainty they did not have. I would still want evidence that the control-plane credential can no longer reach the workload in any runtime class. Two months later, Daytona [closed the production codebase](https://www.daytona.io/dotfiles/updates/daytona-is-going-closed-source). Their explanation was that AI now makes it much cheaper to search public code for vulnerabilities. I can understand the business decision and still disagree with the security argument. Closing the code adds work for an attacker, but it does not fix the design. It also removes one way for customers to inspect a system whose main job is containment. If the implementation stays closed, independent audits and very clear runtime guarantees become more important. E2B is useful as a comparison because it publishes a detailed [Firecracker architecture](https://github.com/e2b-dev/infra/blob/main/docs/ARCHITECTURE.md): one microVM per sandbox, prebooted snapshots, lazy memory loading and copy-on-write filesystems. I am not saying open code makes E2B safe by default. It does make the architecture easier to challenge before handing it something important. ## The clouds are already moving in Daytona and E2B have focused products, but they are entering a market where the larger platforms can treat sandboxing as one feature in a much bigger bundle. Cloudflare has the most interesting approach to me because it does not start by booting a full machine. Generated TypeScript can run in a short-lived Worker isolate, the filesystem can live separately, and a [Linux container starts only when the task actually needs one](https://blog.cloudflare.com/agents-platform-flue-sdk/). For transforming some JSON and calling two APIs, that sounds much more sensible than carrying an Ubuntu box around. A compiler, browser or arbitrary binary changes the calculation. Cloudflare also removed its desktop API after low adoption and has been [cleaning up the Sandbox SDK before 1.0](https://developers.cloudflare.com/changelog/post/2026-06-09-deprecating-sandbox-sdk-features/). I find that more interesting than the desktop demos. In production, controlled tools will probably handle far more work than a model clicking around a screen. [AWS AgentCore](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agents-tools-runtime.html) bundles the runtime with identity, VPC access, browser use, code execution, memory, policy and audit. That is a lot of AWS, but a company already using IAM may prefer it because the security team knows where to look. Vercel can offer [Firecracker sandboxes](https://vercel.com/changelog/vercel-sandboxes-ga) next to the application that calls them. Google has gVisor and managed sandboxes in Cloud Run and GKE. [Modal](https://modal.com/docs/guide/sandboxes) is attractive when the same job needs GPU infrastructure, and Azure has [prewarmed Hyper-V sessions](https://learn.microsoft.com/en-us/azure/container-apps/sessions). Basic compute will not be a strong moat. Daytona and E2B already advertise the same base rate of $0.0504 per vCPU-hour and $0.0162 per GiB-hour, which puts a 2 vCPU, 4 GiB machine at roughly $0.17 for an hour before storage. The prices will get closer and the clouds will bundle more of it. Daytona can still do well if it becomes the neutral layer that works across models, agent frameworks and clouds. Customer-managed compute is useful, and the team knows the annoying lifecycle problems that only show up after the demo. The risk is that AWS or Cloudflare becomes good enough, or that E2B keeps a clearer story around isolation and trust. ## How I would use one today I would keep the first use case boring. A short internal coding job gets a container created from a known snapshot and deleted when the job is done. Untrusted code gets a microVM. Anything using my logged-in browser receives extra scrutiny because browser state is basically a collection of permissions pretending to be cookies. The sandbox would not get my usual API keys. It would get access to one repository, a short list of hosts, a spending limit and an expiry time. Logs would live outside the environment so a compromised process could not clean up its own story. This also completes the x402 idea from the previous article. An agent can have a budget, pay for a temporary machine, finish some work and shut it down. x402 can handle the payment between machines. We still need normal engineering around identity, permissions and recovery; money moving over HTTP does not make any of those disappear. I expect this category to become large, although probably with fewer visible desktops than the current demos suggest. What I want from an agent computer is fairly mundane: when a task goes wrong, the damage stays inside one environment, I can see what happened, and cleaning it up does not involve changing every credential in the company.