An AI agent sandbox for autonomous coding agents
An agent that can write code can also run it. The design brief for ainclave: every agent session gets its own microVM, a repo mount, and a network boundary that starts closed — so the interesting question stops being “what did it just do?”
- Own microVM
- Repo mount
- Network boundary: starts closed
What an agent sandbox actually has to do
A sandbox for a coding agent has a harder job than a sandbox for untrusted code. The agent is supposed to touch your repository, run your test suite, install packages and call a model API. You cannot lock it down by taking those away. What you can do is put a hard boundary around the session and make every crossing of it explicit.
Four things have to hold at the same time:
Isolation that survives a container escape. A shared kernel means one namespace bug away from the host.
Network that is closed by default. Not filtered after the fact — closed, and opened per destination.
Credentials with a short blast radius. Scoped per session, re-supplied per run, and discarded when the session is deleted.
A record of what happened. Per session, structured, and readable by someone who was not there.
One session, one microVM
A session is the unit of everything: isolation, budget, and audit. It boots a Firecracker microVM with its own guest kernel on KVM — not a container sharing the host kernel. The repo is mounted into it, and the filesystem and syscall policy is fixed when the sandbox is created: read-only and read-write paths are declared up front and enforced with Landlock where the guest kernel provides it, and a seccomp filter blocks the escape-relevant syscalls. Neither is negotiable from inside the guest afterwards.
Egress is a decision, not a filter
The session starts with no route out. The destinations it may reach are fixed when the session is created — the repository host, the model endpoint, any MCP endpoint its configuration names — and everything else the host drops. Enforcement sits on the host datapath, outside the guest, so it is not something the workload can route around: name resolution goes to a host resolver scoped to that session's list, and a TLS connection is forwarded only when the host it asks for is on it. One consequence falls out of a default-drop host: cloud metadata endpoints are not reachable from a session.
Your model, your token
Bring your own token for any provider you already use, or run against an EU-hosted model. The key is stored encrypted, is never displayed again after you save it, and is held on the host rather than baked into the session image or the sandbox specification. It is re-supplied to each run and discarded when the session is deleted, and it is not written to the driver log, the trace or the image registry. Source-control access is a scoped, per-user token rather than a shared deploy key.
A budget cap you set once
A lifetime cap per session and a runtime-minute budget per account, both with auto-stop, plus an idle timeout you set. The cap is measured in runtime minutes rather than in euros or tokens. That is the part that makes walking away reasonable: the worst case is a stopped session, not an agent still going at 3am.
What is not built yet
Honesty is cheaper than a support ticket. The following are on the roadmap and are not available today:
Where to go next
- How microVM isolation works — the architecture, in detail.
- EU data residency — what stays in the EU, and under what conditions.
- How pricing works — the billing model, which is session runtime.
- For engineering teams — run agents on your code without the sandbox ops.
- For security & compliance teams — review the boundary before you sign it off.
Run your agents behind a real boundary
We are onboarding a small group of design partners. Tell us what your agents need to reach, and we will tell you honestly whether we cover it yet.