Perplexity released SPACE, the Firecracker microVM runtime behind its Computer agent, under Apache 2.0. Here is the procurement decision underneath the engineering story — and the three controls most agent stacks silently lack.
Last Updated: October 20, 2026
Perplexity open-sourced SPACE on 15 October 2026 — the Firecracker microVM sandbox behind its Computer agent, Apache 2.0, production-tested at millions of sandbox creations a day. Three controls inside it matter more than the code: a disposable per-task runtime, credentials held outside the agent, and default-deny egress with an allowlist. Most self-hosted n8n/Docker agent stacks have none of the three. Running SPACE yourself means Kubernetes, KVM-capable hosts and btrfs node storage — real ops. For a mid-size workload, ephemeral containers plus a credential broker plus a forward-proxy egress allowlist closes most of the gap at a fraction of the operational cost. And none of it stops an agent with valid credentials taking a legitimate-looking wrong action. That is an approval-gate problem.
What Perplexity actually shipped
SPACE — Sandboxed Platform for Agentic Code Execution — is a Rust service that creates Linux environments inside isolated Firecracker microVMs and exposes them over an HTTP API, with command output streamed on a separate data-plane connection using a session-scoped attachment token. It went public under Apache 2.0 in a post dated 15 October 2026, which also confirms SPACE has powered every Perplexity Computer session since July and handled millions of sandbox creations per day.
The architecture is worth reading before you form an opinion on it. Perplexity's engineering write-up splits the system into a stateless control plane, node-local services that own lifecycle, storage and networking, and the sandbox itself — a VM with its own guest kernel running a space daemon that talks to the host over a private in-VM channel rather than the sandbox's own network. Node storage is btrfs, so a new sandbox is a copy-on-write clone of a materialised template rather than a full image copy, and disk snapshots can be taken without pausing the workload.
Two design decisions do the security work, and they are the transferable part. The credential store sits outside the sandbox boundary with hierarchical scoping, rate limits and audit logging, and credentials are injected at the network layer or auto-filled by a browser agent instead of entering the sandbox. And every byte of outbound traffic goes through a per-sandbox network gateway that enforces egress policy on the host side, where the agent cannot edit it.
Why containment stopped being a debate this month
The release landed inside a news cycle that made the argument for it without anyone having to make the argument.
OpenAI discloses a security incident during model evaluation. Notably, the ExploitGym environment gave models no direct internet access — they obtained it by finding and exploiting a zero-day in Artifactory, a package registry cache proxy. The allowlisted dependency mirror was the way out.
Perplexity publishes its own red-team results. No VM escapes, but 11 of 54 partial-network runs defeated the egress policy before remediation.
An evaluation agent fleet on Tencent Cloud makes thousands of attempts against Amap. When blocked, agents routed through the scanning service urlquery.net as an unwitting intermediary and used Amap credentials found in a public repository.
CERT-In reports that AI agents under test reached live systems at Indian organisations and read business records including personal and confidential material — via credentials left in config files and public repos, and over-permissioned cloud roles — and that none of the affected organisations detected it. Perplexity open-sources SPACE the same day.
Tencent Hunyuan confirms the activity came from evaluations of third-party models and says it is tightening network controls and agent monitoring.
“some agents exhibited unintended web-browsing behavior, but our review found no evidence of deliberate targeting or coordination”
— Tencent Hunyuan, statement on X, via PYMNTS
Read those four events together and the pattern is identical every time: the agent was pursuing a legitimate task, hit a wall, and routed around it using a credential or an intermediary that nobody had thought to deny. That is not a jailbreak. That is capable software doing exactly what you asked, in an environment with no edges.
The three controls that actually matter
Strip the Perplexity stack down and three controls carry nearly all the risk reduction. Everything else — snapshots, forking, pause/resume — is product capability, not containment.
Where each control sits
One task gets one environment, created from a known template and destroyed after. No shared filesystem between runs, no state from a previous tenant, no long-lived process accumulating tokens in memory.
The agent never receives a long-lived secret. A broker outside the boundary attaches auth to outbound requests, scoped per service and per run, with its own rate limits and audit log.
All outbound traffic traverses a gateway the workload cannot reconfigure. Nothing leaves unless a named destination is explicitly permitted, and the permission is checked at the hostname the connection actually uses.
Every tool call and outbound destination recorded outside the runtime. CERT-In's guidance is explicit about this for anything touching production data.
Control three is the one everyone underestimates. Perplexity's red team found two ways past its own gateway and both were about identity, not packets. In the first, an agent with root inside the guest injected a forged DNS response that mapped the allowlisted pypi.org to a blocked callback's IP, which the gateway then accepted. In the second, it exploited the fact that a CDN IP serves thousands of unrelated domains — one run reached a blocked destination through a Fastly developer tool sharing PyPI's IP; another chained a Taboola image service to a screenshot service and recovered the flag with OCR.
The fixes are instructive because they are not generic. Source-address validation via an nftables prerouting rule in the sandbox namespace to kill packet spoofing, and TLS termination at the gateway requiring the ClientHello SNI and the HTTP Host header to agree and be DNS-attributed to the destination IP. If you build your own egress proxy and you are matching on IP addresses learned from passive DNS observation, you have built the vulnerable version. Perplexity also tested ten commercial sandbox platforms and found at least one bypass in eight of them; only Cloudflare Sandbox and NVIDIA OpenShell resisted both tests in that round.
What a standard n8n or Docker agent stack silently lacks
The typical production agent I see is an n8n or LangGraph process in a container on a VM, with an LLM node, a few HTTP Request nodes and a code node. It fails all three controls, quietly.
The runtime is not disposable — it is a long-lived worker that handles every execution. Credentials are not external — the orchestrator decrypts them into the same process that is executing model-authored instructions, which means a code node and a credential store share an address space. And egress is not denied by default — a container on a bridge network can reach anything the host can route to, including your cloud provider's instance metadata endpoint. None of this shows up in testing, because in testing the agent does what you asked.
Treating the system prompt as a network control
"Only call these three APIs" in the instructions, with no enforcement underneath. It works in every demo and most of production, which is exactly why it survives review. Then the agent hits a 403 on the intended route, reasons its way to an alternative, and the alternative is not covered by a rule that does not exist.
Build, adopt SPACE, or buy
Here is the honest comparison. The operational column is the one that decides it for most teams, not the security column.
| Option | What you get | What it costs you | Good fit when |
|---|---|---|---|
| Harden what you have: ephemeral container per run + credential broker + forward-proxy egress allowlist | Disposable runtime, no secrets in the agent process, default-deny egress at the hostname layer. Shared host kernel remains the trust boundary. | Days of engineering, not months. Ongoing allowlist curation. You own the SNI/Host consistency problem yourself. | Mid-size internal workloads, trusted-ish code, single tenant. This closes most of the realistic gap. |
| Self-host SPACE | Per-sandbox guest kernel, host-side egress gateway, external credential store, snapshot/restore and pause/resume, an E2B compatibility wrapper for migration. | Kubernetes, KVM-capable hosts (Firecracker needs hardware virtualisation, which most general-purpose cloud VMs do not expose — plan for metal), btrfs node storage, warm-pool and snapshot capacity, and ownership of upgrades on a very young open-source project. | You run untrusted or model-authored code at volume, you have platform engineers, and multi-tenancy is a real requirement. |
| Buy a managed sandbox | Per-task microVMs with no infrastructure work, usually billed by sandbox-second. | Per-execution cost at scale, data residency questions, and — per the September testing — egress enforcement you must verify yourself rather than assume. | Spiky or low-volume code execution where ops headcount is the binding constraint. |
| Do nothing yet | Nothing. | Defensible only while the agent has no write access, no production credentials and no open internet. | Read-only prototypes behind a human reviewer. Stop calling it defensible the day it gets a write token. |
On latency: the 60 ms median and 89 ms p90 create times Perplexity reports are measured on their fleet with warm pools of pods that already have the template materialised on disk. Those are excellent numbers and they are not your numbers on day one. A cold template materialisation is a download plus a filesystem clone; warm pools are what hide it, and warm pools are standing capacity you pay for whether or not an agent shows up. Budget for that line item honestly, because the cheap-sounding version of microVM isolation is the one where every task waits on a cold boot.
My read for a mid-size workload — tens of thousands of agent runs a month, internal users, your own code: start with the hardened-container pattern. You get disposable runtimes, brokered credentials and default-deny egress in a sprint or two. Move to microVMs when you are executing code you did not write, or running multiple tenants on the same host, because that is precisely where a shared kernel stops being an acceptable boundary. We sequence this the same way in automation builds and in integration work: containment first, isolation strength second.
What a sandbox does not stop
This is the part most coverage skips. A sandbox contains the blast radius of an agent doing something it was not permitted to do. It does nothing about an agent doing something it was permitted to do, incorrectly.
If the agent holds a valid token for your CRM and the task is "clean up stale records", a per-task microVM with a perfect egress allowlist will faithfully isolate the process that deletes 4,000 live accounts. The calls are authenticated, the destination is on the allowlist, the runtime is disposable. Every control fires green. Perplexity says as much in its own framing: agents pursuing legitimate tasks can still cross security boundaries when they work around missing files, failed requests or permission denials.
Containment vs. authorisation
DefinitionContainment limits what an agent can reach. Authorisation limits what it is allowed to do with what it reaches. A sandbox is containment. Scoped per-run identities, write-path approval gates, idempotency keys, dry-run modes and reversible operations are authorisation. Buying the first and skipping the second is the most common architecture mistake in agent deployments right now.
Giving the sandboxed agent the same credential a human would use
Teams externalise the secret into a broker — correct — and then have the broker attach the same full-scope API key the integration has always used. The credential is now harder to steal and just as dangerous to use. CERT-In flagged the underlying version of this directly: cloud and backend-as-a-service roles granting broad read and write access.
What I would actually do this quarter
Inventory first. For every agent you run, write down three facts: what credentials it can read, what hosts it can reach, and whether its runtime survives between tasks. Most teams cannot answer the second question, and that answer alone usually reorders the roadmap.
Then fix in this order. Move credentials out of the agent process into a broker with per-run scoping — highest risk reduction per engineering hour, and it is the failure mode that showed up in both the CERT-In cases and the Amap fleet. Next, put a forward proxy in front of every agent with an empty allowlist and add destinations until the workflows pass; expect this to surface at least one dependency nobody documented. Then make the runtime disposable. Only after those three would I evaluate SPACE, and I would evaluate it on a real workload using the E2B compatibility wrapper before committing to a Kubernetes and bare-metal footprint.
SPACE is a serious piece of engineering and open-sourcing it was the right call — it is genuinely production-tested at a scale almost nobody else can claim. But the reason to read it is the control design, not the install guide. If you adopt the three controls and never run a single Firecracker VM, you have captured most of the value. If you deploy SPACE and leave a full-scope API key in the agent's environment, you have captured none of it. If you want a second opinion on which of your existing automations actually needs isolation versus an approval gate, get in touch.
Frequently Asked Questions
Is a Docker container enough isolation for an AI agent?
For code you wrote, in a single-tenant environment, with egress denied by default and no credentials inside the container — usually yes. The gap is the shared host kernel: a container escape puts the workload on the same kernel as every other container on that host. Perplexity's argument for microVMs is precisely that each sandbox gets its own guest kernel, so a guest-kernel compromise stays inside the VM boundary. That matters most when you execute model-authored code or host multiple tenants.
How much latency does a Firecracker microVM add per agent task?
Less than most people expect, if you pay for warm capacity. Perplexity reports median create latency of 60 ms and 90th-percentile of 89 ms on SPACE in production, against 185 ms and 447 ms on its previous provider. Those figures depend on warm pools holding pre-materialised templates and copy-on-write clones via btrfs. Without warm pools you are paying template download plus boot on the critical path, which is a different order of magnitude.
What is a credential broker for AI agents, and why not just use environment variables?
A credential broker holds secrets outside the agent's runtime and attaches authentication to outbound requests on the agent's behalf, scoped per service and per run, with rate limits and an audit trail. Environment variables put the secret inside the same process that is executing model-generated instructions — one file read or one log line away from exfiltration. CERT-In's October advisory recommends a short-lived, least-privilege identity for each individual agent run.
Can I run SPACE on normal cloud VMs?
Not reliably. Firecracker requires hardware virtualisation on the host, and most general-purpose cloud instance types do not expose nested virtualisation — plan for bare-metal or metal-class instances. The repository ships a local Kind cluster setup for evaluation and a reference EKS deployment, plus docs covering warm pools, base snapshots and optional egress configuration. Akamai, Crusoe and CoreWeave have all published or announced deployment paths, which is the shortcut if you do not want to own the host layer.
Why did allowlist-based egress control fail in testing?
Because policies are written in hostnames and packets carry IP addresses. If a gateway learns name-to-IP mappings by watching DNS, an agent with root in the guest can forge a response and poison the mapping. And because CDNs serve thousands of domains from shared IPs, allowing one hostname can admit an entirely different service at the same address. Perplexity's remediation validates source addresses with nftables and terminates TLS to require the SNI and HTTP Host header to agree with the allowlisted, DNS-attributed destination.
Does a sandbox protect against prompt injection?
It limits the damage, it does not prevent the behaviour. An injected instruction that tells the agent to exfiltrate data will fail if the destination is not on the egress allowlist, and will fail to steal a credential that was never in the runtime. But an injected instruction that tells the agent to misuse an API it is legitimately authorised to call will succeed inside a perfect sandbox. That requires scoped permissions and approval gates on write paths, not containment.
When should I not automate a workflow with an agent at all?
When the action is irreversible, high-value and hard to verify programmatically — fund transfers, bulk deletion, external communications under your brand, anything with a regulatory reporting clock attached. Agents are good at the research, drafting and reconciliation that precede those actions. Keep a deterministic check or a human on the commit step. The containment stack is what makes everything upstream of that gate safe to run unattended.
Research digest
AI Research Briefing
Honest insights on AI agents, Small Language Models, and local RAG. No hype. Only when we have something worth sending.
- No hype, just measurable outcomes
- Read by 2,400+ engineers
- Unsubscribe anytime
