Review the boundary before you approve the agent.
Somewhere in your organisation a team is already pointing an autonomous coding agent at a repository. This page is the review package for that decision: what a session can reach, what leaves it, who holds the credentials, where it runs, and what evidence remains afterwards — including the controls that are still limited or unbuilt.
- Isolation — one microVM and its own guest kernel per session. Available
- Network — deny-default egress, enforced on the host datapath. Available
- Credentials — injected into the agent process. Limited
- Data residency — EU execution and storage; the model route is your choice. Limited
- Audit — a live structured event feed per session. Limited
The question is not whether the agent is trusted.
It is whether the environment around it is bounded. A review that ends in a signature needs five answers: what the process can reach, what leaves the environment, who controls the credentials it uses, under whose jurisdiction the whole thing runs, and what evidence remains once the session is gone. Everything below is one of those five, with the parts that do not hold yet named as such.
Five dimensions to review
Each row states the question, the control that answers it today, and the part that is still open. The open column is not an appendix: it is the half of the review that decides whether the control is enough for you.
Isolation
What does the agent process actually run inside?
Every session boots a Firecracker microVM on KVM with its own guest kernel — one session, one VM, so an escape has to defeat the hypervisor rather than a namespace. The filesystem and syscall policy is fixed when the sandbox is created and is not negotiable from inside the guest afterwards.
The syscall filter is a targeted set of seccomp blocks, not a default-deny surface, and filesystem policy is enforced with Landlock where the guest kernel provides it. Physical separation is tier-dependent: on shared capacity the claim rests on the microVM boundary, not on separate hardware.
Network and egress
What can leave the session, and who decides?
A 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 the host drops everything else. Name resolution goes to a host resolver scoped to that session, and a TLS connection is forwarded only when the host it asks for is on the list.
Editing that list yourself, per session and per destination, is roadmap; today the set follows from the configuration you picked. The boundary we test is the host datapath — the guest supervisor carries its own policy as a second layer, but we do not claim the two lists are congruent.
Credentials
Who holds the keys the agent uses?
Provider and source-control keys are stored encrypted, never displayed again after saving, and held on the host rather than baked into the session image or the sandbox specification. They are re-supplied to each run, discarded when the session is deleted, and 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.
The key is handed to the session as environment material, so the agent process can read what it is given — treat it like any key an agent holds. Agent-blind injection, where the credential never enters that process at all, is designed and not yet wired up.
Data residency
Where does this run, and under whose law?
Execution and storage run on EU bare metal at an EU provider. We operate the platform with guardrails, not with monitoring of what your agent is working on.
Sovereignty holds for the whole pipeline only when the compute, the model and the operator are all in scope. Bring your own token for a US provider — which you are free to do — and the prompts you send reach that provider under their jurisdiction, whatever our region setting says. EU data residency sets out the condition in full.
Audit and accountability
What evidence remains once the session is gone?
A running session streams a structured event feed, boundary decisions included, readable by someone who was not there.
The feed is live only. Persistence, export and retention, and anchoring it so it can be proven unmodified, are all open work. Until then it is an operational view, not an audit record you can hand to a regulator.
Where each boundary is enforced
Isolation is not one mechanism, and which layer enforces a control matters more than how many controls are listed. Read the stack from the outside in.
The distinction a reviewer should hold on to is between what the host enforces and what the guest carries. The host datapath sits outside the workload, which is why it is the boundary we test and the one every egress claim above rests on.
The full control stack, layer by layer and with its own limits, is on how microVM isolation works.
- Repository and model provider — Outside the boundary. Reached only over the connections the host forwards.
- Host policy boundary — Enforced by the host, outside the guest: default-drop forwarding, a resolver scoped to the session, and an exact match on the name a TLS connection asks for.
- Per-session microVM — Enforced by the hypervisor and its own guest kernel, with the filesystem and syscall policy fixed when the session is created.
- Agent process — Runs the model output and holds the credentials it is given. This is where the credential boundary stops today.
Control status
Three explicit states, not a compliance checklist. What the product does today, what it does with a named constraint, and what does not exist yet. None of this is a certification — we hold none today, and we will not imply one.
| Review dimension | Available | Limited | Roadmap |
|---|---|---|---|
| Isolation | One Firecracker microVM with its own guest kernel per session. Filesystem and syscall policy fixed when the session is created. | Syscall filtering is a targeted set of seccomp blocks, not a default-deny surface. Landlock applies where the guest kernel provides it, not unconditionally. Physical isolation is tier-dependent: dedicated bare metal exists in the dedicated tier, and on shared capacity the claim rests on the microVM boundary. How the tiers differ. | |
| Network and egress | Deny-default egress, enforced on the host datapath. | A self-service egress allowlist you edit per session and per destination. | |
| Credentials | Credentials are injected as environment material, so the agent process can read them. | Agent-blind credential injection, where the key never enters the agent process. | |
| Data residency | Execution and storage on EU bare metal at an EU provider. | EU residency covers execution and storage; the model route depends on the token you bring. | |
| Audit and accountability | A live structured event feed per session. | Persistence, export and retention for the session event feed, and tamper-evident anchoring on top of it. | |
| Independent verification | An external penetration test report and a published SBOM. |
Known limits
A security page that only lists strengths is a sales page. These are the current boundaries of the claim, in the same words they are stated in everywhere else on this site.
- Shared capacity is not dedicated physical hardware. Dedicated bare metal exists in the dedicated tier. On shared capacity the infrastructure is shared, and the isolation claim rests on the microVM boundary rather than on separate hardware.
- Encryption at rest does not protect a live compromise. Volumes are encrypted, but that control does not help against a compromised gateway while it is running.
- The agent process can read its own credentials. Provider and source-control keys are injected as environment material, so the credential is inside the process that uses it. Agent-blind injection is designed and not yet wired up.
- The event feed is live only, and not tamper-evident. A running session streams a structured feed. Persistence, export and retention, and anchoring the feed so it can be proven unmodified, are all open work.
Taking this internally
For the engineering champion
Send this page rather than a summary of it. Every control above is stated with the layer that enforces it and the part that is still open, so the first review meeting starts from the same text instead of from a feature list. What we want back is the actual requirement: the destinations your agents have to reach, and the evidence your reviewer expects to see afterwards.
Become a design partnerFor the reviewers
A security and architecture deep-dive covers the datapath behind every claim above: how egress is enforced outside the guest, what the session event feed contains, and where the credential boundary sits today.
The data processing agreement, the record of processing activities, the subprocessor list and the TOM document are in preparation. They do not exist yet, and we will not pretend otherwise in a sales conversation.
The known limits above are the ones we will repeat in the review. We hold no certification today, every control the matrix calls limited stays limited in the meeting, and nothing on this page is softened for a procurement conversation.
Request a security and architecture deep-dive
Related
Review microVM isolation
The control stack in detail, including what it does not cover.
Review EU data residency
Where sessions run, and the one condition attached to it.
Read frequently asked questions
The short answers, drawn from the same claims as this page.
Review us on a real workload
Bring a repository, a set of destinations and your reviewer. We will answer each line with implemented, limited, or not built — and we will not blur the middle one into the first.