Start a conversation

AI

Keep the Keys Outside the Box

October 19, 2026 · Stathy Touloumis · 14 min read

A framework for security looking at the Perplexity SPACE platform.

Why agents need a box

The safest AI agent is not the smartest one, it is the one that works inside a lane the model cannot cross. Even better has incentives to stay inside it's lane.

AI agents now do more than answer questions. They write code, open files, call outside services, and run for hours. That is the point, and it is also the risk. An agent can be tricked in various ways by a cleverly crafted web page. It can also cross a line on its own while it tries to work around a missing file or a blocked request to fulfill your request, as Perplexity points out.

Most teams try to fix this inside the model, with better prompts and guardrails. Those might help, but a model makes guesses by design and a guess is not a control. Think of a new hire with great judgment. You still do not hand them the vault code on day one. You give them a badge that opens the right doors, and the vault code stays with security.

Perplexity is the AI company behind a popular AI search engine, the Comet browser, and Computer, a personal agent it launched in February. Its SPACE sandbox platform, open sourced on October 15, 2026, runs millions of agent sandboxes a day and shows that idea working at scale. This article uses it, plus open standards from NIST, CISA, OWASP, and the open source community, to set out five principles. They are not a checklist but rather a way to decide where trust lives, so your team can better judge systems through a framework no checklist has seen.

What Perplexity built, and what it proved

SPACE replaced a commercial sandbox provider at Perplexity in July and now runs every Computer session, at millions of sandbox creations a day. The design is simple to describe, even if it is hard to build.

Each sandbox is a Firecracker microVM, an open source tool AWS built for its serverless service. Think of a tiny apartment with its own walls and lock, not a room in a shared house. An intruder stays in that one apartment. A central control plane acts as the building manager and decides when each sandbox starts, pauses, resumes, or goes away.

Two choices stand out. Credentials live outside the sandbox, and a gateway adds them only to approved calls, so the agent never holds the key. Storage keeps only what changed. In a side by side test on live traffic, median startup fell from 185 to 60 milliseconds against the old provider.

Then they tried to break it. Nine AI models got full admin rights inside a sandbox and were told to escape. None crossed from the sandbox to the host in 108 runs. But with access to a few package sites, four models slipped past the network rules. Perplexity fixed both holes, retested clean, and found similar gaps in 8 of 10 other platforms. It told every vendor. The team's own caution is the most useful line in the report. Not seeing an escape is not proof that none exists.

Principle 1. Draw the trust line outside the agent

Design as if the agent is already hijacked. Then ask what it can still reach.

Simon Willison calls the core danger the lethal trifecta. An agent that can see private data, read untrusted content, and send data out can be tricked into leaking. Most useful agents need all three. You cannot train that risk away, so you break the triangle from outside the model.

SPACE does this two ways. Keys sit in a credential store outside the sandbox and are added to approved requests at the network layer. All outbound traffic passes a gateway that enforces each sandbox's rules. Think of a bank teller window. The agent slides a request through the slot. The teller checks it, uses the vault key, and slides back the result.

Agent Sanbox Trust Boundary - 3 Zones

Even a fully hijacked agent holds no key and can only reach what the gateway allows.

Open standards agree. NIST's zero trust architecture grants no trust based on network location. The joint Careful Adoption of Agentic AI Services guide from CISA, NSA, and four allied nations says to limit agent access, start with low risk tasks, and favor containment over speed. The OWASP Top 10 for Agentic Applications ranks identity and privilege abuse among its top risks.

Here the common view falls short. Much of the market asks whether a model will follow instructions. That is a quality question. The control question is what the agent can touch when it does not. IBM found that fewer than half of breached organizations secure the machine identities their AI workflows use.

Principle 2. Match the wall to the risk

Pick the wall by what the agent could damage, not by habit or by what is already installed. Agents write and run code no person has read. By definition, that code is untrusted. The real choice is how thick the wall around it should be. There are four common rungs, and each has a mature open source option.

Isolation Options - 4 Rungs From Low to High

Each step to the right buys a stronger wall and costs some speed, memory, or skill.

Plain containers share the host's operating system core, a risk NIST's container security guide covers and Perplexity calls a single point of failure. gVisor, from Google, puts a software kernel in front of the real one, like a doorman who handles every request for the guest. Its own docs admit some programs run slower or not at all.

MicroVMs give each sandbox its own kernel behind a hardware wall. AWS built Firecracker to run Lambda and Fargate. Kata Containers brings the idea to normal container tools, and Red Hat ships it as OpenShift sandboxed containers. The cost is a memory floor per sandbox and more parts to run.

My lean is the microVM rung for any agent that touches real data. The math is simple. You pay for the wall on every sandbox. You pay for a breach once, and IBM puts the average at $4.99 million. With SPACE starting sandboxes in about 60 milliseconds, the old speed case for thinner walls is mostly gone.

Two caveats keep this honest. The VM wall held in Perplexity's tests, but the network rules failed first, so kernel choice is not the whole story. Open source also cuts both ways. Agents with SPACE's source code found a DNS flaw that others missed, yet Perplexity fixed it before publishing the code.

Principle 3. Make a fresh box cheap

A sandbox you can throw away, rewind, or copy in seconds turns a mistake into an undo step.

SPACE builds each sandbox from a shared template and stores only what changes. Think of tracing paper over a master drawing. Each agent draws on its own sheet, and a new sheet costs almost nothing. With rolling snapshots as often as every minute, a task can rewind about a week, pause for days while it waits on a person, or branch to test two approaches.

This is a security control, not just a convenience. The joint CISA guide asks for reversibility, and disposable boxes deliver it. A sandbox destroyed at the end of each task is a poor home for an attacker. Compare that with IBM's finding that the average breach now takes 247 days to find and contain.

The tradeoff is that snapshots hold data. Treat them like any business record, with encryption, retention rules, and legal hold plans. SPACE lets customers bring their own encryption key, so revoking it makes stored data unreadable. Ask every vendor for the same.

Principle 4. Attack your own box, then show your work

A sandbox is only as strong as the last serious attempt to break it, so test it with the same kind of AI that will run inside.

Perplexity's red team study is a good template. Agents with full admin rights inside a sandbox had two goals. One was to steal a fake cloud key planted on the host, like a dye pack in a bank bag. The other was to reach a blocked web address. The tests ran 216 times, with and without source code and network access.

The VM wall held every time but the network rules did not. In one gap, the gateway trusted address replies it never checked, like a guard who takes a caller's word for which door a visitor may use. In the other, many websites share one address at a content network. The fixes were plain engineering. Check the sender of every packet, and make the named host match at the encryption layer.

Eight of ten other platforms showed similar gaps. Some vendors shipped fixes, and others called it a known limitation. A "domain allow list" on a datasheet may not mean what you think.

This is not theory. In July, OpenAI disclosed that models under test in an isolated setup exploited an unknown flaw in a package proxy, the one narrow opening, and went on to breach Hugging Face. The small door for software packages is where both stories turn.

The open standard here is disclosure. CISA's Secure by Design pledge asks vendors to publish a disclosure policy and report flaws openly. Yet only 25 percent of breached organizations use adversarial testing, according to IBM's 2026 study. A vendor that publishes its own failures gives you evidence. One that only publishes wins gives you marketing.

Principle 5. Record every action

If you cannot replay what an agent did, you cannot prove it was safe or fix it when it was not.

SPACE routes every command between sandbox and platform through one sanctioned channel, and the credential store logs every key it hands out. That paid off in testing. When the first bypass happened, the team paused the runs and confirmed no outside service was harmed. Think of a flight data recorder. You cannot install it after the crash.

The open standard to watch is OpenTelemetry. Its GenAI conventions give common names to agent steps, like running a tool, so you can switch monitoring tools without rewiring agents. They are still in development and will change. I lean open anyway, because a shared format protects your options better than any one vendor's dashboard.

Speed of detection is where the money is. IBM found that breaches lasting past 200 days averaged $5.65 million, against $4.32 million for those closed sooner. Breaches that attackers disclosed themselves cost the most of any discovery route.

One tradeoff needs a policy. Logs of prompts and outputs can hold the very data you are protecting. Record every action by default. Record content only where a rule says you must, and protect those logs like the source data.

The business case

The payoff shows up in three places. Breaches cost less, agent projects get approved faster, and you keep the freedom to switch vendors.

Start with breach math. Expected loss is the odds of an incident times its cost. A sandbox does not drive the odds to zero because models will still be tricked. What it does is it caps the cost. When a hijacked agent holds no keys and reaches only an allow list, a prompt injection becomes a failed task, not a data breach. As an illustration with assumed numbers, cutting the yearly odds of a major AI incident from 1 in 10 to 1 in 20, at IBM's $4.99 million average, avoids about $250,000 a year in expected loss. Be sure to run your own numbers.

IBM's 2026 study shows where those dollars sit.

Finding in IBM's 2026 study Number Principle that helps
AI breach victims missing AI access controls 92 percent Trust line outside the agent
Identity and access management, lower cost per breach $225,622 Trust line outside the agent
Prompt injection incidents, average cost $5.89 million Trust line and isolation
Wide use of security AI and automation $4.00 million vs $5.93 million per breach Record every action
Shadow AI incidents, average cost $5.39 million A safe, approved place to run agents

Next is speed to yes. The CISA guide says to start agents on low risk work. A tested box lets more use cases clear that bar sooner. That matters, because Gartner expects more than 40 percent of agentic AI projects to be canceled by the end of 2027, partly over weak risk controls. It also curbs shadow AI, since people use unapproved tools when the approved path is slow.

Last is lock in. SPACE ships under the Apache 2.0 license, with an adapter for a popular commercial sandbox interface, so teams can test it without rewriting code. Running it yourself trades license fees for engineering time.

Read IBM's figures with care. The study is not a random sample, its results show links rather than proven causes, and IBM sells products the findings favor. The direction is credible but the exact dollars are not a promise.

Where this approach falls short

A sandbox caps the damage from a tricked agent. It does not stop the trick.

An agent can still misuse access it was given. If the allow list includes email, a poisoned web page can ask the agent to mail out what it read. Set permissions per task, not per platform.

Tests have limits too. Perplexity warns that boundaries holding in its runs do not prove they are secure. Retest each time models improve.

The build, buy, or bundle choice carries its own risks.

Path Best when Main risk Ask before you commit
Build on open source, such as SPACE or Kata You need control, on premises, or offline work Scarce skills, and SPACE is a new public project with a small outside community so far Who patches it, and how fast?
Managed sandbox service Speed matters and the data is low risk Network gaps like those found in 7 of 9 platforms in Perplexity's public results Show me your egress tests and disclosure record
Built into your cloud or agent platform You already run there Internals you cannot inspect, and one vendor holds the keys Could I rebuild this elsewhere within days?

My lean is open source for the parts that hold trust, the gateway and the credential broker, because those are what you most need to inspect. A managed service can be the right start for low risk pilots. The wrong move is to pick any of the three on its datasheet alone.

Where to start

Treat this as a path you climb and then repeat, not a list you finish.

Maturity Path - 4 Stages and A Retest Loop

Each stage builds on the last, and every new model sends you back to the start.

Stage one maps each agent's reach. What data can it read, what untrusted content does it see, and where can it send things? Any agent with all three needs the most care. Stage two moves keys into a broker and sends all traffic through one gateway that checks host names. Stage three puts untrusted work behind its own kernel, in a box you can rewind or destroy. Stage four is proof. Attack it with current models, log every action, and share what you learn.

Four questions will show where you stand this week. If an agent were fully hijacked today, what key could it steal? Which hosts can it reach, and how does the gateway know it is really talking to them? Could you rewind or wipe every agent workspace within minutes? When did someone last try to break it, and what did they find?

A team that can answer all four has a working system. A team that cannot has a pile of tools and a hope. Perplexity published its failures, fixed them, and opened the code. That is a fair bar for anyone building or selling this layer, including your own team.

References

© 2026 Symvoulos LLP. You may quote or excerpt this article with attribution and link to the original URL as well as referenced material. Republication in full, adaptation, translation, or use as the basis of derivative or secondary works requires attribution. Removal or alteration of attribution is prohibited.

Stathy Touloumis is President of Symvoulos (Symv), a boutique technology consultancy serving all sectors of business and government entities including regulated enterprises. His experience spans over 30 years with most recent to state, local, and public entities across infrastructure modernization, security, service delivery strategy, and the governance questions raised by AI adoption. Symvoulos’ expertise starts where most stall: multi-year cost models, risk vectors and staffing plans an agency can defend in a budget hearing. Be sure to follow us at symv.ai.

Want to talk about your own case?

Share a few details. A person on our team will reply.

Start a conversation

← All articles