Keep Agent Credentials Outside the Sandbox

On October 15, 2026, Perplexity open-sourced SPACE, the sandbox platform that runs every task in Perplexity Computer. It ships under Apache 2.0. Each agent task gets its own Firecracker microVM. Credentials and outbound traffic are controlled from outside the VM.

The microVM gets the headlines. The second sentence matters more. In SPACE, the sandbox needn’t hold secrets. A gateway on the host adds them to requests on the way out, and only for destinations the policy names.

Our read: that pattern is worth copying whether or not you ever run SPACE. Isolation keeps a compromised agent off your host. It does nothing for the API key sitting in the agent’s environment variables. We read the repository to see how SPACE handles that, and where the approach stops.

Key Takeaways

• SPACE is Perplexity’s production agent sandbox, now open source: Rust, Apache 2.0, version 0.8.0, with an E2B-compatible API.
• A microVM per task isolates execution. It doesn’t protect secrets the agent can read. A prompt-injected agent can send any token it holds to any host it can reach.
• SPACE’s network policy names credentials by reference only. The gateway terminates TLS and injects the secret as a header for an exact host, method, and optional path prefix.
• Version one injects only for GET and POST. Injection can’t stop misuse inside an allowed scope, so you still need narrow tokens and evals.
• This week, list every secret inside your agent sandboxes. For each, write down the host, path, and methods it needs. That list is your policy.

What did Perplexity open-source?

Perplexity released the full SPACE platform, not a client library. SPACE stands for Sandboxed Platform for Agentic Code Execution. The repository is mostly Rust, and the versioning guide names 0.8.0 as the public baseline. Perplexity plans 0.9.0 as the last breaking release before stable 1.0 contracts.

Applications use it over HTTP and server-sent events. A template is the starting filesystem. A sandbox is a microVM created from it. A command session runs one process and streams its output through a separate data plane. Sandboxes can pause, suspend to a snapshot, and wake again. By default, an idle sandbox suspends after six hours without activity.

SPACE also ships an E2B Compatibility Wrapper. It’s tested against the e2b==2.21.1 Python SDK. If you already use E2B’s client, you can point it at a SPACE deployment.

SPACE already runs in production. Perplexity’s launch post from July 15, 2026 says SPACE took 10 weeks to build. It reports “millions of sandbox creations” in the week before launch. It also describes snapshots taken as often as every minute, restorable up to a week back.

Why isn’t a microVM per task enough?

A microVM per task is the right baseline, and it’s now cheap. Firecracker, the VM monitor AWS built for Lambda, claims under 125 ms to boot and under 5 MiB of memory overhead per VM. It can create up to 150 microVMs per second per host. Containers share the host kernel; a microVM gives each task its own.

But isolation answers one question: can the agent escape to the host? With agents, that’s rarely the first threat. The agent itself becomes the attacker the moment it reads hostile input. A web page, an issue comment, or a README can carry a prompt injection. If the agent holds a GitHub token, the injected instruction can send it anywhere the sandbox can reach.

SPACE’s own architecture guide is candid about the limits. It says Firecracker isolates guest execution, while host-side services still need privileges. The VM boundary protects the host. It doesn’t decide what crosses the network, or with which credentials.

So the useful question for any agent sandbox is simple. What can a fully compromised agent do with everything inside its VM? If the answer includes “use our production API keys from anywhere,” the microVM bought you less than you think.

We made a related argument in Complexity Is Easy. Reliability Takes Design. Boundaries are a design decision, not a property you inherit from your infrastructure.

How does SPACE keep credentials out of the VM?

SPACE moves the secret to the network path. The sandbox’s network policy says which credential applies to which request. The secret value never enters the VM or the policy. A gateway on the host adds it after the request leaves the guest.

The policy schema makes the boundary concrete. In policy.proto, each NetworkCredentialRuleV1 holds four things:

• A destination: an exact host, a port that defaults to 443, and an optional path prefix. The prefix is segment-aware, so /v1 matches /v1/... but not /v10. Without a prefix, the rule matches every path on that host, so always set one.
• Header bindings: a header name mapped to an opaque credential reference ID. A comment in the schema says resolved secret values “are never part of network policy.”
• Allowed methods: version one supports only GET and POST. Every other method fails closed.
• A rule ID that the caller chooses.

To add a header, the gateway has to see the request. So it terminates TLS, presenting certificates from a guest-facing interception CA. It then verifies the real upstream separately.

The credential manager’s resolution path is strict. Its source comments describe four steps. It reads the sandbox’s committed state, fences it to the requesting node and execution, and resolves only the referenced secrets. Then it reads the state again and discards the secret if anything changed. The resolution module doesn’t cache or persist resolved values. Delivery to the gateway is a separate step.

The design has a clear effect. For intercepted traffic that matches a rule, the agent never holds the token. It can still make an authenticated call to the allowed endpoint. It can’t read the token, print it, or send it to another host. The main leak path left: an allowed API that echoes request headers back.

What does egress control add?

Credential injection limits where secrets go. Egress policy limits where anything goes. You need both, because an agent can leak source code or customer data without any token.

A SPACE network policy sets a default action, allow or deny. It adds allow and deny lists of IPs, CIDR ranges, exact domains, and wildcard domains. Explicit denies and platform guardrails win over allows. Operators can also define named egress profiles that add destinations to a tenant’s policy. In the local Kind setup, sandboxes can reach only the public IPv4 internet and cluster DNS.

Each piece covers a gap in the others:

Control	Stops	Doesn’t stop
MicroVM per task	Escape to the host, cross-task interference	Anything the agent does over the network
Default-deny egress	Data sent to unlisted hosts	Misuse of allowed hosts
Credential injection	Secret theft and reuse elsewhere	Harmful calls inside the allowed scope
Narrow token scopes	Damage beyond what the token permits	Harmful calls the token does permit

The last row is outside SPACE. The gateway injects whatever token you give it. If that token can delete repositories, a POST to an allowed path can still do damage.

Where does this approach stop?

Credential injection solves secret exposure. It leaves several problems for you, and the repository is honest about most of them.

Header-only, GET and POST only. Version one injects headers for two methods. Many real APIs use PUT, PATCH, and DELETE. Request signing schemes such as AWS SigV4 cover the whole request, not just a header. For those, you’ll need a different path for now.

TLS interception has costs. The guest must trust the gateway’s CA. Clients that pin certificates will typically fail, which is why exemptions exist. SPACE supports TLS interception exemptions, but its docs say exempt traffic bypasses HTTP inspection and credential injection. Every exemption is a destination where the sandbox needs its own credentials, or none.

Scope misuse is still possible. An injected credential is still a credential. Prompt injection can make the agent call the allowed endpoint with harmful arguments. That’s an eval and authorization problem. In How to Design Evals for AI Agents, we cover building tasks from real failures, including adversarial inputs.

It’s heavy to operate. The installation guide needs a Linux x86_64 host with KVM, btrfs, and privileged Docker. The full stack adds PostgreSQL, object storage, and Kubernetes or a direct worker mode. The documented setup doesn’t run directly on macOS, or in a VM without nested virtualization.

It’s young in public. The GitHub repository was created on October 1, 2026, and it’s still before 1.0. Per its security policy, only the latest minor release gets security fixes. Perplexity was running it in production by July. Your team hasn’t, and that’s the experience that counts when it breaks.

Should you run SPACE, keep a hosted sandbox, or build your own?

Most teams shouldn’t start by running SPACE. They should start by adopting its credential pattern, whatever sandbox they use.

Option	Fits when	Watch for
Hosted sandbox service	You want sandboxes in days, not quarters	Whether secrets must live inside the sandbox
Self-hosted SPACE	Data must stay on your infrastructure, at volume	KVM hosts, Postgres, S3, pre-1.0 upgrades
Your own egress proxy	You already run containers or VMs	Building TLS interception and policy safely

Ask any hosted vendor one question: can your platform add a credential on the network path, so my agent never sees it? If the answer is no, ask where the token lives instead. Network-path injection is one way to keep it out of the agent’s reach. A tool server outside the sandbox, holding its own credentials, is another. The E2B wrapper lowers the cost of switching later, which makes trying SPACE in staging cheaper.

If you build your own, SPACE’s schema is a good reference. Copy the reference-only policy, the exact-host matching, the segment-aware paths, and the fail-closed method list. Those choices are cheap to adopt and costly to retrofit. Scoped permissions came up in our look at Menlo’s 2026 consumer AI data, too. Users trust agents that can do less.

What to do this week

Run a secrets inventory. Start with one agent sandbox.

1. List every secret the agent process can read. Check environment variables, mounted files, ~/.config directories, and git credential helpers.
2. For each secret, write down the host, path prefix, and HTTP methods the agent actually uses. Pull this from logs, not memory.
3. Mark which ones are header-based and use GET or POST only. Those can move to the network path today, with SPACE or your own proxy.
4. For the rest, narrow the token scope. Then add an eval case where a hostile document tells the agent to send the token somewhere.

Here’s the shape that list takes in SPACE’s JSON policy format, which nests the default action and lists under egress. It follows the NetworkPolicyV1 fixtures in the repository’s policy tests. The reference ID is a sample UUID; yours points at a secret the credential manager resolves.

{
  "version": "v1",
  "egress": {
    "default_action": "deny",
    "allow": [{ "domain": "api.github.com" }],
    "deny": []
  },
  "tls_interception": "on",
  "network_credential_rules": [
    {
      "rule_id": "github-read-repos",
      "destination": { "exact_host": "api.github.com", "path_prefix": "/repos" },
      "credential_header_bindings": [
        { "header_name": "Authorization", "credential_reference_id": "018f1e9d-7b7a-7d3a-8000-000000000001" }
      ],
      "supported_http_methods": ["GET"]
    }
  ]
}

Apart from DNS and any operator-added profiles, the agent can reach only api.github.com. The gateway adds the token only to GET requests under /repos, and the agent never sees it.

That list becomes your network policy, whatever enforces it. The real change is in how you think about the agent. Stop trusting what runs inside the sandbox, and decide what can leave it. For agents that sign in on a user’s behalf, the same question shows up in Personal Agent Protocol: What to Build Before Version 1.0.

Frequently Asked Questions

Is Perplexity SPACE open source?

Yes. Perplexity released SPACE under the Apache 2.0 license on October 15, 2026, at github.com/perplexityai/SPACE. The release includes the API, control plane, network gateway, credential manager, and Firecracker template tooling. The documented public baseline is version 0.8.0.

How does SPACE keep credentials away from the agent?

The sandbox’s network policy names credentials by reference ID, never by value. A network gateway on the host terminates the agent’s TLS connection. It matches the request against an exact host, method, and optional path prefix, then adds the secret as a header. The agent never holds the value.

Can SPACE replace E2B?

For many workloads, possibly. SPACE includes an E2B Compatibility Wrapper tested against the e2b==2.21.1 Python SDK and e2b-code-interpreter==2.6.2. Other SDK versions and the JavaScript SDK aren’t covered by its tests yet. You’d also take on running the infrastructure yourself.

Do I need Kubernetes to run SPACE?

No, but the documented setup uses it. The local guide deploys to a Kind cluster, and a reference AWS EKS deployment ships in the repository. The architecture guide also describes a direct adapter that manages workers without Kubernetes pods. Both paths run Firecracker, so hosts need KVM.