Perplexity has open-sourced SPACE, the security infrastructure behind its Perplexity Computer AI agent, under the Apache 2.0 licence. Announced on October 15, 2026, SPACE stands for Sandboxed Platform for Agentic Code Execution. It provides isolated computing environments where AI agents can execute code, work with files and perform multi-step tasks without receiving unrestricted access to the underlying host system. Perplexity says SPACE has powered every Computer session since July and handles millions of sandbox creations per day.
The release gives developers access to infrastructure that Perplexity built to support more capable autonomous AI systems. SPACE uses Firecracker micro-virtual machines, controls network access and platform-held credentials, and allows tasks to be paused, resumed and restored. The announcement also comes with security testing that highlights both the platform’s strengths and the difficulty of securing AI agents: Perplexity reported no virtual-machine-to-host escapes in 108 attempts, but initially identified network-restriction bypasses that it subsequently addressed.
Key Takeaways
- Open-source release: Perplexity has released SPACE under the Apache 2.0 licence.
- Purpose: SPACE provides isolated environments for AI agents to execute code and work with files.
- Underlying technology: Each sandbox runs inside a Firecracker micro-virtual machine with its own operating system.
- Security controls: Network access and platform-held credentials are managed outside the sandbox.
- Production use: Perplexity says SPACE has powered every Perplexity Computer session since July 2026.
- Performance: The company reports sandbox creation was three to five times faster than its previous provider on the same production traffic.
- Security testing: No host escapes were observed in 108 virtual-machine escape attempts, although initial network bypasses were found and fixed.
- Developer access: The source code and documentation are available through Perplexity’s public GitHub repository.
What Is Perplexity SPACE?
SPACE is the infrastructure that provides AI agents with a controlled environment for executing tasks. Rather than allowing an agent to run arbitrary commands directly on a host machine, the platform creates a separate workspace with its own operating system and filesystem.
The distinction is important because modern AI agents increasingly do more than answer questions. They may install software, execute scripts, analyse spreadsheets, create files, interact with websites and coordinate several steps to complete a user’s request.
These capabilities make agents more useful, but they also introduce security risks. A faulty script or an agent following malicious instructions could attempt to access sensitive files, use unauthorised network connections or interfere with other workloads.
SPACE is designed to contain that activity. It combines virtual-machine isolation with external controls governing what an agent can access and how its workspace is managed.
Perplexity developed the platform for Computer, its agentic product that can carry out longer tasks using tools and files. By open-sourcing the infrastructure, the company is allowing other developers to inspect its implementation, adapt it to their needs and contribute improvements.
What does SPACE stand for?
SPACE stands for Sandboxed Platform for Agentic Code Execution. Its primary purpose is to give AI agents a separate environment in which to execute code and manipulate data while maintaining security boundaries around the host system.
The project is available on GitHub at perplexityai/SPACE and includes documentation for installation, configuration, API usage and development. The repository is primarily written in Rust and is released under Apache 2.0.
How the Firecracker-Based Sandbox Works
At the centre of SPACE is Firecracker, an open-source virtualisation technology originally developed by Amazon Web Services for running lightweight micro-virtual machines.
A Firecracker microVM provides a separate guest operating system, creating an isolation boundary between the guest and the host machine. In SPACE, the guest is the environment where an agent executes commands and works with files.
The platform adds several layers around that environment to manage the task’s lifecycle and restrict access to sensitive resources.
| Component | Purpose |
|---|---|
| Firecracker microVM | Runs agent tasks in an isolated environment with its own operating system |
| Control plane | Coordinates sandbox creation, pausing, resuming and removal |
| Network controls | Restrict outbound connections to permitted destinations |
| Credential management | Keeps platform-held credentials outside the sandbox |
| Snapshots and checkpoints | Preserve task state for recovery and continuation |
| API and runtime components | Allow applications to create and manage sandbox sessions |
The separation between these components is central to the security design. The agent can perform useful work inside its environment, while the surrounding infrastructure controls how that environment interacts with the rest of the system.
A sandbox is not automatically secure merely because it uses a virtual machine. Its configuration, network rules, credential handling and management interfaces also need to be designed and tested carefully.
SPACE attempts to address these different requirements as part of one platform.
Why AI Agents Need Dedicated Sandboxes
Traditional chatbots generally return text, code snippets or other content for users to review. Agentic systems can take additional steps by executing the generated code, changing files or interacting with external services.
That ability creates a larger attack surface. A coding agent might install a package containing malicious code. A research agent might encounter a webpage with instructions designed to manipulate its behaviour. An automation agent could make an unintended network request while trying to complete a task.
Even a legitimate request can lead to unexpected behaviour if the model misunderstands the task or attempts to work around a restriction.
Sandboxing reduces the potential consequences by limiting what the agent can reach. Instead of trusting the model to follow every instruction correctly, developers can use infrastructure controls to enforce boundaries independently.
For example, an agent asked to analyse a spreadsheet could receive a temporary workspace containing the relevant file. It could run calculations and create a new report without gaining unrestricted access to the computer’s other files.
The same principle applies to coding, data processing and longer research workflows. Agents can be given enough access to perform a task while remaining isolated from unrelated resources.
This is increasingly important as companies deploy agents that operate for extended periods and use multiple tools with varying permission levels.
Network Access and Credential Security
One of SPACE’s important design choices is that network access and platform-held credentials are managed outside the sandbox.
Credentials such as authentication tokens can grant access to private services, accounts or business data. If those credentials are stored directly inside an environment that an agent can manipulate, malicious code could potentially expose them.
SPACE is designed to keep these credentials outside the guest environment and provide access through controlled mechanisms when needed. This reduces the risk of an agent simply reading a secret from its local workspace.
Network controls serve a related purpose. An agent may need to connect to an authorised API or retrieve a package, but it should not necessarily be allowed to contact every destination on the internet or reach internal infrastructure.
The platform therefore applies network restrictions outside the sandbox. That provides an additional layer of defence even if an agent behaves unexpectedly.
These protections are particularly relevant for enterprise deployments, where AI systems may interact with confidential documents, customer records, internal tools and production code.
However, external controls must be implemented correctly. Perplexity’s own testing found initial ways to bypass network restrictions, illustrating that virtual-machine isolation and network confinement are separate security challenges.
Perplexity’s Security Testing: What the Results Show
Perplexity published security testing examining whether AI models operating inside SPACE could break out of their virtual machines or bypass network restrictions.
In the virtual-machine escape tests, nine models received root access inside a guest environment and attempted to obtain a secret stored on the host. Perplexity reported that none of the models escaped the guest virtual machine in 108 attempts.
The company also tested whether models could reach destinations blocked by the sandbox’s network policy. These tests uncovered bypasses involving DNS spoofing and shared-IP routing. Perplexity said it implemented fixes and that neither identified method succeeded in follow-up testing.
| Security test | Reported result |
|---|---|
| Virtual-machine escape attempts | 0 observed escapes in 108 attempts |
| Network-restriction testing | Initial bypass techniques were identified |
| Follow-up testing | The two identified bypass methods did not succeed after fixes |
| Broader significance | Isolation and network controls require separate evaluation |
These are results from Perplexity’s disclosed tests, not proof that SPACE is immune to every possible attack.
The findings offer useful evidence about the platform’s security boundaries, but they should be interpreted carefully. A finite number of tests cannot establish that a system will never be compromised under different configurations, software versions or attack techniques.
The network findings are especially instructive. A virtual machine may prevent an attacker from reaching the host operating system while a separate flaw still allows unauthorised network access. Both boundaries matter when an agent handles private data or uses external services.
Perplexity also said it disclosed relevant weaknesses identified in other sandbox platforms to their vendors. The broader lesson is that agent security requires ongoing testing, responsible disclosure and continued updates rather than reliance on a single protective mechanism.
Faster Sandbox Creation and Recovery
Performance is another reason Perplexity built SPACE in-house. Agentic tasks may require multiple environments, particularly when agents work concurrently or need to test alternative approaches.
Perplexity says SPACE created sandboxes three to five times faster than its previous commercial provider when compared using the same production traffic.
Faster startup can reduce the delay before an agent begins executing a task. At large scale, it can also help reduce infrastructure overhead and improve the responsiveness of applications that create many short-lived workspaces.
SPACE supports additional features for long-running tasks. Its snapshot and checkpoint mechanisms preserve workspace state so that a task can be paused and resumed without rebuilding everything from scratch.
Session branching is another capability. Developers can create separate paths from a preserved state to test different approaches without immediately losing the original workspace.
For example, a data-analysis agent could create two versions of a cleaned dataset, test separate transformations and compare the results. If one approach fails, the original state can remain available for recovery.
These capabilities matter because agents often perform work that spans multiple steps and may need human review or additional information before continuing.
What Apache 2.0 Means for Developers
By releasing SPACE under Apache 2.0, Perplexity is making the code available under a permissive open-source licence. The licence generally allows users to use, modify and redistribute the software, including in commercial projects, subject to its terms.
This gives developers and organisations an alternative to building all the underlying sandbox infrastructure themselves or relying entirely on a commercial provider.
Teams can examine how SPACE handles virtual machines, network restrictions, credentials and session recovery. They can also adapt the implementation to their own agent frameworks and deployment environments, subject to the project’s technical requirements and licence conditions.
Open source does not mean that every installation will be simple or that the platform is automatically suitable for every production environment. SPACE’s published setup instructions require a supported Linux environment, virtualisation capabilities and other infrastructure components.
The documentation also makes clear that deploying SPACE locally involves more than installing a single application. Teams must configure the runtime and authentication, prepare the required host capabilities and understand the security model.
For organisations evaluating the project, the availability of source code is an opportunity to inspect and test the platform, not a substitute for their own security review.
Which Companies Could Use SPACE?
SPACE could be useful to teams building coding agents, data-analysis assistants, research agents and other systems that need to execute commands or manipulate files.
Cloud providers and infrastructure companies can also integrate sandboxing into managed services, allowing customers to deploy agents without building every component from scratch.
Perplexity has identified partnerships involving Akamai, Crusoe and CoreWeave. Akamai has tested and launched SPACE on its cloud platform, Crusoe is working to include it in its managed AI services portfolio, and CoreWeave has published setup guidance for evaluation on its Kubernetes-based platform.
These efforts could help make the technology available beyond Perplexity’s own Computer product. Actual availability and support will depend on each provider’s implementation and commercial offering.
The opportunity extends beyond AI startups. Businesses deploying internal agents may want isolated environments for software development, document processing and data analysis. A standardised sandbox platform could help them enforce consistent controls across different applications.
Still, organisations will need to determine whether SPACE fits their workloads, infrastructure and compliance requirements. Some may prefer managed services, while others may need self-hosted or tightly controlled environments.
The Bigger Picture
Perplexity’s decision to open-source SPACE reflects a growing recognition that AI agents need more than capable models to operate safely. They also need infrastructure that controls code execution, protects credentials, limits network access and preserves work across long-running sessions. Making this infrastructure available under Apache 2.0 gives developers a new foundation they can inspect, test and adapt.
The security results also demonstrate why agent safety cannot depend on model behaviour alone. SPACE showed strong results in the reported virtual-machine escape tests, but its initial network bypasses required separate fixes. As AI agents gain more access to files, software and external services, the quality of the surrounding security architecture will become as important as the intelligence of the model itself.
Looking Ahead
Developers can begin evaluating SPACE through its public GitHub repository and official documentation. The next practical questions will involve deployment complexity, integration with existing agent frameworks, performance under different workloads and how well its security controls hold up under independent testing. Wider adoption will depend on whether teams find the platform reliable and manageable in their own environments.
For the broader AI industry, SPACE adds to the growing collection of open-source tools aimed at making autonomous systems safer. Its impact will depend not just on the initial release, but on continued maintenance, external contributions, responsible vulnerability disclosure and evidence from real-world deployments. The goal is to give agents room to complete useful work without giving them unrestricted access to everything around them.
Frequently Asked Questions
1. What is Perplexity SPACE?
SPACE stands for Sandboxed Platform for Agentic Code Execution. It is a platform that runs AI agent and user code in isolated Firecracker micro-virtual machines.
2. Is SPACE open source?
Yes. Perplexity released SPACE under the Apache 2.0 licence on October 15, 2026. The code is available in the public perplexityai/SPACE GitHub repository.
3. How does SPACE protect a computer from AI agents?
It runs tasks inside separate virtual machines and adds controls for network access, platform-held credentials and sandbox lifecycle management. These controls are designed to limit the consequences of unexpected or malicious agent behaviour.
4. Did Perplexity prove that SPACE cannot be hacked?
No. Perplexity reported no virtual-machine-to-host escapes in 108 attempts, but that does not establish immunity to all attacks. Its testing also found network-restriction bypasses that were subsequently addressed.
5. Can developers run SPACE themselves?
Yes, subject to its technical requirements. The official documentation describes installation and configuration on a supported Linux environment with required virtualisation and system capabilities.
6. Who could benefit from using SPACE?
Developers and organisations building coding agents, data-analysis tools, research assistants and other autonomous systems that need controlled access to code execution, files and external services.
Get the day’s top stories in your inbox
One concise email. No spam, unsubscribe anytime.
