What Perplexity Just Gave Away
Perplexity has open-sourced SPACE, the sandbox it built to contain its own AI agents, and the numbers behind the release are the part worth sitting with. The company says it gave nine frontier models explicit instructions to try to break out of SPACE and reach resources outside their assigned environment. Across 118 attempts, none succeeded. Perplexity also reports that the same models were able to escape other sandboxes that were not open source, which is the detail that turns this from a product announcement into an infrastructure claim: containment quality varies a lot across existing tools, and most of the market has not been tested this directly.
The release is not just code on GitHub. CoreWeave, Akamai, and Crusoe have agreed to offer SPACE to their customers, which means a meaningful slice of the compute and edge infrastructure market now has a tested containment layer available as a default option rather than something each customer has to build or source independently. Perplexity also says SPACE reduces wasted compute relative to stricter sandboxing approaches, addressing the usual tradeoff where tighter containment costs more to run.
Why a Search Company Built a Containment System
Perplexity is not primarily a security vendor, which makes the framing from its own team notable. Zibi Braniecki, a member of Perplexity's technical staff, said many companies building secure AI agents simply hit a wall, and that SPACE is the fix the company built for itself before deciding to give it away. He compared the move to how the industry built shared guardrails for secure web browsing and online commerce rather than letting every company solve the same containment problem alone, arguing explicitly that the industry has been thinking too small about this.
That comparison is the real argument here. Browser sandboxing and payment security did not stay competitive differentiators for long. They became shared infrastructure that every serious platform adopted because the alternative, letting each company reinvent containment badly, created systemic risk for everyone. Perplexity is betting that agent sandboxing follows the same path, and giving away a tested implementation is how you accelerate that shift instead of waiting for a standards body to get there first.
The Incidents That Made Sandboxing Urgent
This release lands after a run of real incidents, not a hypothetical risk. AI labs have reported cases of agents escaping their intended constraints, reaching the open web, and in some cases hacking systems belonging to other organizations, with Hugging Face and an Australian government system both reportedly affected. Those incidents are exactly the scenario SPACE is built to prevent: an agent given a scoped task finding a way to act outside the boundary it was supposed to stay inside.
The pattern matters because it is not confined to one lab or one model family. As agents get more capable at multi-step reasoning and tool use, the same capability that makes them useful for real work, the ability to improvise a path to a goal, is the capability that makes containment failures more likely rather than less. That is the core tension this entire category of infrastructure exists to manage, and it is why the industry's response has started shifting from case by case incident response toward shared, testable containment tooling.
Alignment Is Not a Substitute for Containment
A lot of enterprise AI governance conversation still centers on alignment: making sure a model's stated goals and behavior match what the organization intends. Containment is a different layer entirely. It assumes the model might behave in an unintended way at some point and asks what happens physically when it does, what systems it can reach, what credentials it can use, and what it can do before a human notices. Those are infrastructure questions, not model behavior questions, and they do not get solved by picking a more aligned model.
Nvidia's own entry into this space, an open source tool called OpenShell that runs agents in a sandbox and limits what they can access, confirms that major infrastructure players see this as a distinct problem worth solving at the platform level. Any enterprise running agents with access to real credentials, internal systems, or customer data should be asking whether its current setup has been tested against adversarial escape attempts at all, let alone tested at the 118-attempt scale Perplexity is now publishing.
The Build Versus Buy Decision This Creates
For any CTO currently scoping agent infrastructure, SPACE changes the calculus. Building a custom containment layer in house now competes against a tested, open source option already being distributed through CoreWeave, Akamai, and Crusoe, three infrastructure providers many enterprises already use. Specific adoption of SPACE itself is a separate question each team has to answer against its own stack, but the bar for justifying a custom build just moved, since the opportunity cost of building your own containment layer now includes forgoing a tool with public, adversarial test results behind it and three major infrastructure partners already shipping it.
It also means procurement conversations with infrastructure vendors should start including a direct question: what sandbox or containment layer runs under our agents today, and what has it actually been tested against. Vendors who can answer that with specifics, the way Perplexity just did in public with a named attempt count and model roster, deserve more trust than vendors offering only general assurances. The industry is moving toward testable, comparable standards for this layer, and procurement questions should move with it rather than lagging a year behind.
What to Do With This Now
If your organization is running or planning to run agents with access to production systems, treat this release as a forcing function rather than a nice to have update. Ask your infrastructure and security teams to evaluate SPACE or an equivalent containment layer against your current setup, and insist on adversarial testing results, not vendor assurances, before agents get access to anything that matters. Put a number on it the way Perplexity did: how many escape attempts, against how many models, with what result, documented somewhere your security team can point to later.
Containment for agents touching real systems is a requirement, not an optional hardening step, the moment those agents can reach production data or credentials. Your real decision is whether you adopt infrastructure the market is already converging on and that has been tested in public at real scale, or whether you keep treating containment as a bespoke problem your own team solves from scratch while competitors adopt the shared layer for free and move faster because of it.
