Perplexity has open-sourced SPACE, the sandboxing platform it says underpins sessions run by Perplexity Computer, its computer-use agent. The project is designed to isolate agents that need to browse the web, execute code, manipulate files and interact with software rather than merely generate text. Perplexity says SPACE is built on Firecracker microVMs, and that Akamai is testing the platform for cloud deployment.[1]
The release matters because computer-use agents have a different operational risk profile from chatbots. A system that can open a browser, authenticate to services, download untrusted material, run shell commands or alter a document needs a constrained execution environment. SPACE positions that environment as reusable infrastructure: a layer that developers can inspect, operate and adapt rather than a safety claim embedded inside a proprietary agent product.
Why agent containment is becoming a deployment requirement
Language models can propose an action in text with limited immediate consequence. Computer agents convert those proposals into real operations: clicking interface controls, navigating sites, using credentials, writing code, handling local data and invoking tools. That makes the boundary around the agent at least as important as the model that plans its next step.
A capable agent can encounter hostile web content, misleading instructions embedded in a page, a compromised download, or an unexpected application state. It can also make ordinary mistakes at machine speed. An effective sandbox does not solve every one of those problems, but it can reduce the blast radius by ensuring that the agent operates in a disposable, separated environment with explicitly limited access to host resources, networks, data and credentials.
This is the practical challenge SPACE is meant to address. Perplexity describes the project as a sandbox platform for agents working across browsers, code and software. Its significance is less about a new agent interface than about making a core operational component available for independent use and inspection.[1]
For enterprises, a reusable isolation layer could make early deployments easier to approve. Security and platform teams generally need clear answers to basic operational questions: Where does an agent execute? What happens after a session ends? Can it reach internal systems? Can a suspicious file affect the worker running the task? Can the environment be rebuilt and audited? A sandbox is not a substitute for policy, identity controls or monitoring, but it gives those controls a more defensible place to operate.
What Firecracker microVMs bring to the design
SPACE is based on Firecracker microVMs, according to Perplexity.[1] A microVM is a small virtual-machine environment intended to provide stronger isolation than a conventional process container while remaining lighter than a full general-purpose virtual machine. The relevant distinction is architectural: containers commonly share the host operating system kernel, whereas a virtual-machine boundary places a guest operating system behind virtualization.
That distinction is attractive for untrusted or semi-trusted agent workloads. Browsers are large attack surfaces; developer tools execute arbitrary dependencies; and many agent tasks combine both. A microVM can package an isolated browser or coding workspace, give it a controlled filesystem and a narrowly defined set of network rules, then be discarded after work completes. Ephemeral environments also reduce the chance that state from one task unintentionally persists into the next.
Using Firecracker does not automatically make an agent deployment secure. Isolation quality depends on the host configuration, guest images, patching practices, device exposure, network egress rules, secrets handling, logging and the management plane that creates and destroys instances. A microVM can contain a compromised browser process, for example, but it cannot prevent an agent from sending legitimately accessible data to an allowed external endpoint if egress policy permits it.
Still, the choice points toward an important operational compromise. Agent systems need environments that are strong enough to separate risky activity, quick enough to create on demand and economical enough to run repeatedly. Traditional virtual machines may impose more operational overhead than some agent tasks justify; simple containers may not satisfy every security team’s threat model. MicroVM-based architectures are an attempt to occupy the middle ground.
From proprietary safety feature to stack component
Perplexity says SPACE has been used to run Perplexity Computer sessions.[1] That provides a meaningful, if limited, indicator that the technology has been exercised in a product context rather than released solely as a reference implementation. The announcement also says Akamai is testing SPACE for cloud deployment, suggesting that the company sees a path toward infrastructure-operated agent sandboxes rather than a tool used only within Perplexity’s own service.[1]
Open-sourcing the platform changes the conversation from whether a particular vendor claims to run its agents safely to whether operators can build a verifiable execution layer around many kinds of agents. Developers could potentially pair one model provider’s planning capabilities with another team’s browser automation, their own policy engine and a SPACE-based workspace. That separation is valuable because it reduces coupling: changing a model or agent framework need not require rebuilding the underlying isolation approach from scratch.
The open model also creates opportunities for security review. Researchers and infrastructure teams can examine how environments are provisioned, identify assumptions in the threat model, test failure modes and contribute hardening changes. In agent security, this matters because the risks are often in the integration points: browser profiles, temporary storage, service tokens, outbound network access and cleanup behavior after an interrupted task.
There is a commercial dimension as well. If cloud providers and enterprise platform teams can offer standardized, policy-controlled agent workspaces, computer-use capabilities become easier to procure as infrastructure rather than as an all-or-nothing hosted product. Akamai’s testing is therefore notable, although it should not be interpreted as a general availability commitment or an endorsement of SPACE’s security properties until deployment details are published.[1]
The controls a sandbox cannot replace
The strongest case for SPACE should be made precisely: it is containment infrastructure, not a complete agent-security system. Sandboxing cannot determine whether an agent was authorized to perform a business action. It cannot establish that the model correctly interpreted a request. It cannot, by itself, stop prompt injection delivered through a web page, though it may limit the damage after an agent follows malicious instructions.
Production deployments still need layered controls. Those include least-privilege credentials, scoped and short-lived tokens, allowlisted network destinations where practical, download and upload restrictions, separate workspaces for separate tasks, detailed audit logs, rate limits and human approval for irreversible or high-value actions. Agents with access to email, payment systems, source-code repositories or production administration consoles require especially tight boundaries.
There are also usability trade-offs. Restrictive sandboxes can break the very workflows that make agents useful: a task may require a corporate proxy, a hardware-backed authentication flow, a private package registry or access to a specific internal application. The engineering question is not whether to isolate agents, but how to expose the minimum necessary capability without turning policy exceptions into an unmanaged back channel.
Open source introduces another constraint: organizations must be prepared to operate the software. A public codebase improves inspectability but does not eliminate the need for image maintenance, vulnerability response, capacity planning and incident handling. The value of SPACE will depend heavily on documentation, deployment tooling, policy integrations and evidence from real workloads—not only on the fact that its source is available.
What to watch as agent infrastructure matures
The next test for SPACE is whether it becomes a component others can reliably deploy across different agent frameworks and cloud environments. Important signals will include how quickly isolated environments start, how straightforward it is to attach controlled browsers and developer tools, how policies are expressed, and whether operators can trace a task from user request through agent decisions to network and filesystem effects.
Another question is interoperability. The market is moving toward agents that need access to multiple tools and applications, while enterprises want consistent governance regardless of which model drives the task. A sandbox that can serve as a common execution substrate could become more strategically important than a single agent’s interface. Conversely, if every vendor ships an incompatible environment, customers will face the same fragmented operational model that has slowed other AI deployments.
Perplexity’s release is a concrete step toward treating computer-use agents as workloads that require conventional infrastructure disciplines: isolation, identity, observability, lifecycle management and policy enforcement. That approach is more likely to make agents useful in real organizations than demonstrations that focus only on an agent’s ability to complete a task on an unconstrained desktop.
Editor’s Take
I see SPACE as a more consequential release than another benchmark or browser-agent demo. The hard part of deploying computer-use agents is not persuading a model to click through a website once; it is letting that model operate repeatedly without granting it the effective privileges of a human workstation. A disposable microVM workspace is a sensible default for that job, especially for mixed browser-and-code tasks.
The open-source label should not be confused with a finished enterprise safety answer. Buyers should ask for concrete controls around egress, secrets, identity, audit trails and teardown, then test those controls against hostile pages and failed sessions. If SPACE makes those tests easier and gives cloud operators a common way to run isolated agent workspaces, it can move computer agents from impressive demonstrations toward deployable systems.
.jpg){kind=link}