SPACE ties sandbox API capabilities to execution incarnation after migration

Perplexity's SPACE runs agent code inside Firecracker-backed execution environments and separately governs which worker receives requests for a logical sandbox. These are different security boundaries. A microVM addresses isolation between guest execution and its host, while distributed routing must ensure that an authorized call reaches the correct sandbox execution, even after a restart or migration changes its worker and generation.

The architecture describes signed capabilities binding sandbox ID, worker placement, execution generation and a permitted purpose. Receiving components check the signature and the current local execution identity. Streams, sockets and worker routes can outlive one incarnation, so checks that validate only a stable sandbox ID risk directing a legitimate request to stale or wrong execution state. The published note describes a 120-second capability life plus 15 seconds of clock-skew allowance; old capabilities may remain effective at a retiring worker until expiry or retirement reaches the relevant enforcement point.

This is a released implementation with a documented design, not an independent proof that a production cluster cannot be confused. Signed placement does not attest arbitrary code inside the guest, repair unsafe network egress or certify credential segregation. Adversarial verification would exercise stale routes, recycled sockets, abrupt migrations and conflicting leases while checking the actual destination and resulting filesystem or network effects. These are separate tests from Firecracker escape attempts.