# Sandboxes · Neural Inverse Govern > Firecracker microVMs for agent and user work, started from templates within your organisation's limits, with no network unless an environment allows it, an MCP endpoint agents can drive, and artifacts that are approved before use. Source: https://neuralinverse.com/govern/sandboxes/ --- ![](/photos/facility.jpg) [Neural Inverse Govern / Sandboxes](https://neuralinverse.com/govern/) # Isolated sandboxes where agents run code without reaching anything they should not. Firecracker microVMs for agent and user work, started from templates within your organisation's limits, with no network unless an environment allows it, an MCP endpoint agents can drive, and artifacts that are approved before use. Isolation Firecracker microVM per sandbox Network None by default Agents MCP endpoint and REST API Output Encrypted artifacts, approved before use Stop Every sandbox of the organisation at once Overview A sandbox is an isolated runtime where an agent or a person runs commands, reads and writes files and streams logs. On hosts with KVM each sandbox is a Firecracker microVM with its own user, cgroup and network namespace; its guest agent answers only over a private channel with a token the host sets before anything runs. Sandboxes start from templates within your organisation's limits and each member's quota, have no network unless their environment allows it, and their output is approved before it is used. [What it does ↓](https://neuralinverse.com/#capabilities)[How it works ↓](https://neuralinverse.com/#workflow)[Enforced and recorded ↓](https://neuralinverse.com/#enforcement)[Where it runs ↓](https://neuralinverse.com/#where)[Get started ↓](https://neuralinverse.com/#get-started) What it does ## What sandboxes provide. Only what runs today. Partial and planned parts are listed at the end of the page. - **Sandboxes, exec and files:** Start a sandbox, run commands, read and write files, stream logs and keep a record of runs, through the API, the console or an agent. - **Templates:** Custom sandbox templates built from container images, with their build status. Images can be pinned by digest, and an image digest allowlist refuses any other. - **Firecracker microVMs:** Each microVM runs under the jailer with its own user ID, cgroup limits, network namespace and seccomp filters. The root filesystem is a checked, read-only template; every write lands on the sandbox's own disk. - **Guest agent with a token:** The agent inside the microVM listens on vsock only and requires a 256-bit token the host sends before anything runs. Nothing listens on the guest's network. - **Isolation on record:** Every sandbox records and shows how it is isolated and on which runtime: Firecracker microVM, gVisor container or plain container. - **Egress rules:** No network by default. With network, nothing connects into a microVM, microVMs never reach each other or a host service, and the metadata service and private ranges are always refused. - **Environments for sandboxes:** Agents and CLI sessions start sandboxes from an environment that fixes template, size, network access, setup script and variables, carried inside the signed job. - **Limits and quotas:** Organisation sandbox limits and a per-member quota, with sandbox minutes counted per organisation. - **Pause and resume:** On Firecracker workers a sandbox can be paused, holding no CPU or memory, and resumed with its processes as they were. - **Approved artifacts:** What a run produces is encrypted at rest and approved or rejected before it is applied. - **MCP endpoint:** An MCP endpoint over Streamable HTTP lets agents drive sandboxes with the same permissions as the API. - **Signed webhooks:** HMAC-signed callbacks on sandbox events, retried with backoff. - **Workers and emergency stop:** A view of the worker fleet with each worker's runtime, and an emergency stop for every sandbox of the organisation. - **Sandboxes in projects:** A sandbox can be tied to a project when it starts, and each project lists its sandboxes. - **Workers in your cloud:** With BYOC, an organisation's sandboxes run only on its own workers in its AWS or Azure account, even while they are unhealthy, and those workers never take another organisation's sandbox. How it works ## How an agent's sandbox run is governed. 1. Request An agent or person asks for a sandbox; permissions, limits and the quota are checked. 2. Place The job is signed and sent to a worker of the right placement and region. 3. Boot A microVM boots with its policy confirmed; it is reported running only after its agent answers. 4. Run Commands and file operations run inside it, with the network its environment allows. 5. Approve Artifacts the run produced are approved or rejected before anything applies them. 6. Record The run is kept with its logs, and its minutes are counted. Who uses it ## Built for every role that answers for AI. - **Platform engineers:** Run the worker fleet, publish templates and set organisation limits. - **Agent developers:** Drive sandboxes from agents through the MCP endpoint or the API. - **Security teams:** Decide network access, review artifacts and stop every sandbox at once when needed. - **Reviewers:** Approve or reject the artifacts a run produced before they are used. Enforced and recorded ## Refuses rather than degrades. When a sandbox cannot be run as its policy says, it is not run. Enforced - **Network policy:** A microVM with a network boots only after the host policy is confirmed or repaired. A worker that cannot apply an environment's network access refuses the session. - **Secrets:** An environment with vault references is refused for sandbox sessions rather than started without its secrets. - **Lost sandboxes:** A sandbox whose microVM or worker is gone fails as lost and is never restarted fresh. - **Who may act:** Creating, using and terminating sandboxes are separate permissions, checked on the sandbox or template. Recorded - **Session starts:** The environment, placement and network access each sandbox started with. - **Worker changes:** With BYOC, every connection, worker and certificate change in your audit trail. - **Usage:** Sandbox minutes counted per organisation. Where it runs ## On compute you operate, or in your cloud account. [Deployment options](https://neuralinverse.com/deployment/) - **Self-hosted:** Sandbox workers run on your own KVM hosts as part of your installation; hosts without KVM run containers. - **Your cloud account:** With the hosted service, sandbox workers can run in your AWS or Azure account with the same network policy as shared workers. - **Hosted by us:** Hosted workers in the region that serves your account. Get started ## Set it up with the documentation. - [Agent policy](https://neuralinverse.com/docs/govern/agent-policy/) - [BYOC compute workers](https://neuralinverse.com/docs/deploy/byoc/) - [Configuration reference](https://neuralinverse.com/docs/deploy/configuration/) What's next ## Being built now. These are in development and not part of the product today. - **Snapshots and port exposure:** Snapshots of running sandboxes and exposing a sandbox's ports. - **Time-limited sandboxes:** Reclaiming sandboxes automatically when their time to live ends. - **Proxied network on microVMs:** Trusted and custom network access for sandboxes on Firecracker workers, which today accept only no network. - **Secrets in sandbox sessions:** Delivering vault references into sandboxes started from an environment. Related [Agent policy and approvals → Allow, ask and deny rules for coding agents, with named approvers.](https://neuralinverse.com/govern/agent-policy/)[Cloud workspaces → Development workspaces from approved templates, with governed network access, secrets and terminals.](https://neuralinverse.com/govern/workspaces/)[Audit and evidence → A hash-chained audit log you can verify offline, and evidence toward your frameworks.](https://neuralinverse.com/govern/audit/) ![](/photos/team.jpg) ## Talk to our team. Neural Inverse is available by request. We work with your engineering, security and procurement teams from the first conversation. [Request access](https://neuralinverse.com/contact/?topic=access)[Contact us](https://neuralinverse.com/contact/)