Compare · sandbox APIs
A sandbox is a computer. Not a boundary.
E2B, Daytona, Modal, Runloop, Fly, and Vercel Sandbox all solve a real problem well: give the agent a machine that cannot nuke production. That is necessary and it is not sufficient.
01 / credit where it is due
If all you need is a place to run Python, buy one of these.
E2B's Firecracker isolation is genuinely good and their SDK is pleasant. Daytona's persistent workspaces start fast and fork cleanly. Modal is the best answer in the market for GPU-heavy work. Fly gives you a real Linux box you can checkpoint. These are strong products built by strong teams.
We are not trying to win an isolation bake-off. We will happily run on top of a sandbox vendor you already pay for, because the gap we care about opens after the box exists.
02 / where it stops
The gap we exist to fill.
- No idea who is asking
- A sandbox API authenticates your account, not the agent. It cannot tell you that agent:claims-bot acting for user:mara requested this shell command, because that concept does not exist in the API.
- No decision before execution
- You can run anything in the box. There is no gate that evaluates a tool call, its arguments, and an amount, then allows, denies, or escalates it. Teams end up writing that gate themselves, badly, in the harness.
- No human in the loop
- Approval on irreversible actions is not a sandbox concern, so it becomes a queue, a Slack bot, and a state machine you own and maintain.
- No evidence chain
- You get logs of what the box did. You do not get a tamper-evident record tying each action to an identity and an approval, which is the artifact a regulated buyer actually needs.
- Credentials still leak in
- The usual pattern is to pass an API key into the sandbox environment. Any dependency in that box can read it. Zero standing credentials requires something outside the sandbox to hold them.
- Egress is partial
- Some vendors offer network controls; most treat egress as a networking detail rather than a per-session policy primitive with pinned resolution.
- Shared kernel, sometimes
- Several popular options are Docker-based under the marketing. For untrusted agent code holding real access, a shared host kernel is a materially weaker claim than a microVM.
03 / side by side
| Velone | Sandbox API | |
|---|---|---|
| Isolated compute | Yes, Firecracker | Yes, varies by vendor |
| Snapshot and fork | Yes | Yes, usually |
| Agent identity | First-class principal with delegation | Your account key |
| Pre-execution policy | Yes, on tool and arguments | No |
| Human approval | Yes, signed | No |
| Default-deny egress | Yes, per session | Partial |
| Zero standing credentials | Yes, minted per call | No, you inject keys |
| Tamper-evident audit | Yes, verifiable | No |
| Replay a run | Yes | No |
| Runs in your cloud | Yes, BYOC and air-gapped | Sometimes |
04 / choosing
Pick the right one.
choose them when
- You need a fast, cheap place to execute code and nothing more
- Your agents are internal, low-stakes, and touch no customer data or money
- Nobody is going to ask you to prove what the agent did
- GPU-heavy inference is the workload and Modal already fits
- You have a platform team happy to own identity, policy, and audit yourselves
choose velone when
- Your agents hold access that would matter if it were misused
- Someone needs to approve an action before it happens
- An auditor, a customer, or a regulator will ask for a record
- You want one boundary instead of a sandbox plus a gateway plus a secrets manager plus glue
- Prompt injection is on your risk register and 'we told it not to' is not an answer
05 / questions
Can Velone run on top of E2B or Daytona?
Yes. If you already have a contract, we can schedule sessions onto their sandboxes and keep the identity, policy, and evidence layer. You lose the microVM guarantee if the underlying vendor is container-based, and we will tell you that explicitly rather than quietly.
Why not just add policy to our sandbox ourselves?
You can, and the first version takes a week. The maintenance is the problem: argument-level rules, an approval queue with signing, egress pinning, a hash-chained record, redaction that preserves joins, and a verifier. That is a product, and it is not the product you are trying to ship.
Is your isolation actually better?
Against the Firecracker vendors, it is comparable — same primitive. Against the Docker-based ones, yes, materially. The difference we would emphasise is not the VM, it is that the VM is bound to an identity and a decision.
What does this cost compared to a sandbox API?
More per session, because you are buying four things instead of one. Less in total than a sandbox plus a gateway plus a secrets manager plus the engineer maintaining the glue, which is the comparison that matters.
keep reading
Ring 0
Keep your sandbox. Add the boundary.
If you already pay for isolation, we will sit on top of it and give you the identity, policy, and evidence layer that is missing.