# Building Secure AI Agents: An Introduction to Firecracker MicroVM Sandboxing with SPACE
## What Is a Sandbox Platform for AI Agents?
When AI agents are given the ability to execute code, browse the web, or install software, they also gain the potential to cause harm — either to the host system or to external networks. A sandbox platform solves this problem by running every agent task inside a tightly isolated environment.
SPACE is one such platform. Built in Rust and released under the Apache 2.0 license, it gives each agent task its own isolated virtual machine, keeping the host system completely separate from the agent’s activity.
## How Does It Work?
At the core of SPACE is a technology called Firecracker, developed by AWS. Firecracker creates lightweight microVMs — essentially tiny virtual computers — that boot in milliseconds and use minimal resources.
Here is how a typical session flows:
– **Templates define the starting point.** A template includes a base Linux filesystem that can be customized for different tasks, such as coding or web browsing.
– **A sandbox is a running instance.** Each sandbox gets its own microVM, its own guest kernel, and its own writable disk. Multiple commands can run inside a single sandbox.
– **The host controls everything outside the VM.** Credentials, network access, and outbound traffic rules are managed entirely from the host side, meaning the agent inside the VM never touches sensitive data directly.
## What Makes the Isolation Strong?
One of the most important design choices is that the agent’s secrets never enter the guest machine. Instead, credentials are injected at the network layer when the agent needs to authenticate with external services. This approach includes hierarchical scoping, rate limits, and audit logging, so administrators can track exactly what each agent does.
A per-sandbox network gateway on the host enforces egress policy for every outbound connection. In production deployments, the gateway terminates TLS connections and validates both the Server Name Indication (SNI) and the HTTP Host header against an allowlist, adding another layer of defense.
## Pause, Suspend, and Restore
Agent workloads are often long-running and stateful. SPACE supports four lifecycle states to handle this:
| State | What Happens |
|——-|————-|
| **Running** | The VM is active and executing commands. |
| **Paused** | Execution stops, but memory stays on the worker. This is not a permanent snapshot. |
| **Suspended** | The VM’s memory, runtime state, and filesystem are snapshotted, and resources are freed. |
| **Deleted** | The sandbox is removed and no longer accessible. |
By default, sandboxes suspend after six hours of inactivity. For faster creation times, Kubernetes deployments can use warm pools of pre-booted sandboxes, while single-node setups rely on base snapshots.
## Performance Improvements
In production benchmarks, SPACE showed significant gains over previous sandbox providers:
– **Median create latency** dropped from 185 ms to 60 ms.
– **90th-percentile create latency** dropped from 447 ms to 89 ms.
These improvements matter because agents that create and destroy environments frequently need sub-second response times to stay productive.
## Red-Team Testing Results
Security testing is critical for any sandbox. SPACE was tested against nine frontier AI models, with each model given root access inside the guest VM across 216 total runs.
The results were strong:
– **VM-to-host escape attempts:** 0 out of 108 succeeded.
– **No-network bypass attempts:** 0 out of 54 succeeded.
– **Partial-network bypass attempts:** Before applying fixes, 11 out of 54 succeeded. Four models found bypasses using DNS spoofing and shared CDN IP addresses.
After implementing source-address validation through nftables and strengthening the TLS gateway, all verified bypasses were eliminated. A follow-up study tested 10 third-party sandbox platforms, and 8 of them had at least one network-policy bypass, highlighting the importance of continuous security review.
## Comparing With Other Open Sandboxes
Several open-source sandbox platforms exist today. SPACE distinguishes itself through its use of Firecracker microVMs, its per-sandbox egress gateway, and its Apache 2.0 license. Other platforms vary in their isolation methods, language choices, and how they handle outbound traffic policy. When evaluating sandbox solutions, it is worth comparing isolation strength, egress control, and real-world security test results side by side.
## Who Should Use SPACE?
SPACE is designed for teams building coding or browsing agents that need a production-tested isolation layer they can self-host. It is particularly useful for organizations that:
– Want full control over their agent execution environment.
– Need strong network security guarantees for outbound traffic.
– Require audit logging and credential management at scale.
– Prefer open-source software with an Apache 2.0 license.
## Frequently Asked Questions
**What does SPACE stand for?**
SPACE stands for Sandboxed Platform for Agentic Code Execution.
**What programming language is SPACE written in?**
SPACE is written in Rust and is currently at release version 0.8.0.
**Can SPACE run on macOS or Windows?**
No. SPACE requires a Linux x86_64 host with KVM support, `/dev/kvm`, btrfs, and Docker. It can run locally or in a Kubernetes cluster using Kind.
**How are credentials managed?**
Credentials are never placed inside the guest VM. They are injected at the network layer from the host, with support for scoping, rate limiting, and audit logging.
**What happened when models tried to bypass the sandbox?**
Before fixes, some models found ways to bypass egress policy in partial-network scenarios using DNS spoofing. After nftables-based source-address validation was added, no verified bypasses remained.
**Does SPACE support the E2B SDK?**
Yes. An E2B Compatibility Wrapper is available, making it easier for teams already using the E2B ecosystem to migrate.
**Is there a reference deployment available?**
Yes. The repository includes a reference deployment on AWS EKS for teams looking to run SPACE in the cloud.
## Conclusion
Secure agent execution is no longer optional — it is a fundamental requirement as AI systems gain more autonomy. Platforms like SPACE provide the isolation, network control, and auditability that teams need to deploy agent-based applications with confidence. With its combination of Firecracker microVMs, host-managed credentials, and strong red-team validated security, SPACE offers a compelling option for anyone building coding or browsing agents in a self-hosted environment.
As open-source sandboxing continues to mature, we can expect to see tighter integration between agent frameworks and security infrastructure, making it easier to build powerful yet safe AI applications.
Thank you for reading
