Perplexity SPACE binds requests to sandbox executions with signed proofs
Perplexity’s SPACE binds requests to sandbox executions using short-lived signed proofs, preventing stale executions from handling them. Perplexity reports millions of daily executions and an error rate below 0.0002%.

TL;DR
- SPACE handles millions of executions daily with an error rate below 0.0002%, Perplexity reports in its announcement.
- Requests target a specific execution, even when a resumed sandbox keeps its original ID, as the migration example explains.
- Workers compare short-lived signed proofs against their own runtime records and reject identity mismatches before forwarding.
- Terminals and file watches lose their old connections after a replacement identity is installed; Perplexity's explanation describes one reconnect attempt for eligible operations.
SPACE's technical write-up gets unusually concrete: capabilities expire after 120 seconds, and bridge checks inspect process start times and VSOCK ownership. A correctly signed request can still fail because the receiving machine is running the wrong incarnation of the right sandbox.
Sandbox IDs and execution generations
SPACE separates two identities in its routing model:
- Sandbox identity: The stable logical environment that the caller is authorized to access.
- Route/execution identity: The selected runtime incarnation and its placement. An execution generation distinguishes incarnations; Kubernetes routes also include the pod UID.
A stale route can therefore produce an identity mismatch even when caller authorization and the sandbox ID are correct.
Ed25519 capabilities
After caller authorization, SPACE issues a signed capability binding the sandbox, execution, placement and permitted access. The checks use local state rather than a remote authorization lookup at every private hop.
- Signing: Ed25519 private keys stay in the control plane. Workers and gateways receive public verification keys, which cannot mint capabilities.
- Lifetime: Capabilities last 120 seconds, with up to 15 seconds of expiration clock-skew allowance.
- Worker admission:
sbx-managerverifies the signature and compares the complete identity against its locally persisted runtime record. - Service-port admission: The per-sandbox gateway,
netgtw, checks identity against trusted activation state and enforces the permitted port and protocol before opening a guest connection.
Firecracker bridge verification
Control operations pass through a verified host-to-guest bridge:
node-api → sbx-manager → spaced-host → VSOCK → spaced-guest
An address can acquire a replacement listener, so successful connection establishment alone cannot establish the destination's identity. SPACE checks:
- Host-bridge peer credentials and the identities of both bridge and Firecracker processes, including start times to detect reused process IDs or changed executables.
- VSOCK socket ownership, guest identity and kernel socket evidence tying the listener to the expected Firecracker process.
- Every new connection. The bridge refuses transparent reconnects that would bypass those checks.
This verification covers the Firecracker control bridge on Kubernetes and directly managed hosts. ServicePort admission does not attest the identity of arbitrary applications inside the guest.
Stream epochs
SPACE ties backend streams to an identity epoch and rechecks durable identity before opening a stream. Replacing its route or execution cancels the lease and stops input and output.
Two narrower lifecycle changes can preserve established streams:
- A lifecycle-operation ownership handoff on an unchanged Kubernetes resident preserves route identity, unexpired capabilities and streams.
- An activation-attempt-only change within the same route and execution generation preserves established gateway streams. New opens require the updated identity.
One-shot route repair
Recovery distinguishes two identity failures:
RefreshRoute: An incarnation mismatch within the same sandbox can trigger route repair.Deny: A different sandbox is rejected. Invalid signatures, purposes and port profiles also remain denied.
An eligible operation can resolve the current execution and make one rebuilt attempt. Transport failures follow separate, operation-specific recovery rules.
Cache repair has two safeguards:
- Replacement is conditional on the rejected route, preventing a delayed rejection from evicting a newer cache entry.
- Native-session refresh preserves the original cache expiry, keeping route repair separate from renewal of caller authorization.
A replacement backend must pass admission again even when the client-facing WebSocket stays open.
Retirement and trust boundaries
Retirement takes effect as individual receivers install the update. A worker still serving execution 7 can accept a matching capability until it learns of retirement or that capability expires; a receiver that has installed execution 8 rejects execution 7's capabilities immediately, even before expiry.
The threat model assumes identity enforcement is enabled and trusts the control-plane signer, worker kernel and node-local management services. Worker-root and privileged cluster-administrator compromise fall outside its scope.
Bridge verification relies on local process and transport evidence. SPACE does not claim hardware-backed remote attestation for those checks.