Perplexity Opens SPACE Agent Sandbox Under Apache 2.0

Perplexity has released SPACE as a sandbox platform for AI agents, opening up a piece of infrastructure built for a problem that gets sharper every time an assistant gains permission to browse, run code or use someone’s account: how do you let it work without letting a bad instruction run the show?

SPACE is the platform Perplexity says runs tasks in its Perplexity Computer system. Its design gives each agent task a Firecracker microVM, a lightweight virtual machine, while credential handling and outbound network traffic sit outside that environment. Perplexity has released the code under Apache 2.0, a permissive license that lets other developers examine and adapt it. The release describes an architecture, but leaves production policy settings and independent attack-test results unspecified.

That combination offers a useful way to think about agent safety. A task gets a room of its own. Access to the keys and the exits is supposed to be controlled from outside the room. Whether the arrangement holds up depends on what the agent may ask for, what those external controls allow and how the whole thing is operated.

Why an Agent Needs Its Own Room

An ordinary chatbot can produce a wrong answer. An agent with tools can act on one. If it can fetch web pages, read files, execute code or call an external service, text it encounters along the way can try to redirect its behavior. A webpage that should be treated as data might contain instructions telling the agent to ignore its task and send a document somewhere else. That is prompt injection: an attempt to smuggle commands through material the agent was meant to read, not obey.

Giving each task a microVM limits the damage that one task’s code can do to another task’s environment. A virtual machine separates a guest system from the host and from other guests; Firecracker is designed to run small virtual machines without the weight of a full conventional VM setup. The security idea is familiar even if the AI wrapper is new. You do not let every houseguest wander into every bedroom just because they arrived through the same front door.

Task-level isolation also gives operators a place to draw boundaries around temporary work. An agent running a script for one request should have no automatic reason to see another request’s files or process state. The microVM is a boundary around execution, including code the agent chooses to run. It cannot decide whether a sentence on a webpage is a trustworthy instruction. That decision, and the permissions attached to it, require other controls.

The Keys Stay Outside

SPACE’s placement of credential handling outside the task microVM addresses a different failure mode. An agent may need access to a service to complete a user’s request, but handing the execution environment a reusable secret would increase the consequences of a compromised task. Keeping credential handling outside the VM can reduce direct exposure to that secret.

The remaining question is what requests the agent can make through the credential-handling system. A tool that can legitimately fetch a calendar entry, for example, might also be asked to fetch entries unrelated to the user’s request. An external service can protect the credential itself while still carrying out an action the user never intended. Effective controls would have to consider the scope of access and the permitted action, not just the location of the password or token.

Outbound network controls tackle the other half of the journey. If a task can connect to any address it chooses, it has a route for sending data out. Controlling traffic beyond the VM can restrict that route even when code inside the VM behaves badly. But an agent often needs network access to do its job. If a destination is permitted, the policy still has to decide what the agent may send there and under what circumstances.

That is the awkward security trade-off at the center of useful agents. Lock down every connection and the assistant becomes a very polite brick. Allow broad access and the sandbox may faithfully contain a task while that task uses its authorized tools to do the wrong thing. Isolation and permission checks solve different problems; deployment requires both to line up with what users actually authorized.

Open Code Gives Teams Something to Inspect

The Apache 2.0 release lets developers examine SPACE’s implementation and adapt it for their own systems. Teams weighing an agent deployment can study how it separates task execution from credential and network controls, then decide whether that layout fits their own tools and threat model. Apache 2.0 also permits commercial use and modification under its terms, so adoption need not require buying Perplexity’s product.

Openness creates room for scrutiny, though scrutiny still takes effort. A company evaluating the software would need to test the paths through which its own agents obtain permissions, reach services and handle user data. A sandbox integrated with a tightly scoped document tool faces a different set of consequences from one attached to a broad account with permission to send messages or change files.

That difference is especially easy to miss when security discussions stop at the VM. The VM controls an execution environment. An agent’s reach also comes from the tools connected to it. If the system grants a task authority to act on behalf of a user, the important question becomes how narrowly that authority is defined and checked when the task uses it. A perfectly separated room does little to limit a guest who has been handed the building manager’s keycard.

The release also gives smaller developers a concrete architecture to evaluate rather than requiring every team to invent task isolation from scratch. That could broaden who gets to build with agents. It also shifts work onto adopters: they must choose permissions and network rules suitable for their users, operate the infrastructure and keep it maintained. The license grants access to code, not a ready-made security policy.

What to Ask Before Trusting an Agent

For a team considering SPACE or a similar design, the practical questions start with the task. What files and tools can this agent reach? Does it receive access to a whole account when a single action would suffice? Can a request from inside the VM cause an external service to use a credential, and what checks stand between the request and that action? Which outbound destinations are allowed? What happens to a task’s data when the work ends?

Users need answers at a different level. If an agent reads an untrusted page while helping with a sensitive document, can that page induce it to share the document through an allowed tool? Will the system ask before taking a consequential action? Those questions follow from the agent’s permissions and workflow, whether its code runs in a microVM or somewhere else.

Perplexity’s choice to publish SPACE makes the room, its doors and the external controls easier for others to study and adapt. The next decision belongs to whoever deploys an agent: which keys does the task receive, and who checks what it does with them?