A sealed box for every run.
An agent that can run code and touch files needs somewhere safe to do it. Sandboxes will give every run its own isolated machine — real tools inside, torn down clean when the work is done — provisioned out of the capacity already sitting inside your perimeter.
An isolated place to do the work.
Today you hand an agent a machine you built and hope it cleans up after itself. The sandbox will make that part of the deployment — a fresh environment per run, with everything the agent needs inside and nothing else of yours reachable from it.
One box per run
Every agent run will get a working space of its own — isolated from every other run, from your production systems, and from us. What an agent does inside its box stays inside its box.
Real tools inside
A shell, a filesystem, packages, room to write and read and try again. Somewhere an agent can actually do work — not a stubbed environment that fails the moment the task gets real.
Sealed and ephemeral
The box opens for the run and closes when it is done: torn down clean, nothing left behind, nothing carried into the next job. No long-lived environments to patch, no stray state to audit.
Cut from your own capacity
The sandbox will be provisioned inside the deployment you already approved — your hardware, your network, your storage. An agent that can touch internal systems is doing it from inside, not through a tunnel out.
Inside the runtime. On ground that already runs.
Sandboxes are one piece of the agent runtime — Layer 02 — which stands on the inference layer deployed and serving inside your boundary today. When your agents get a box, it will not be floating on something new.
Tell us what your agents need to reach.
What a sandbox has to contain depends entirely on the work — which runtimes, which packages, which internal systems it must reach from inside. Those constraints are what we are designing against now.