How SPACE Sandbox Uses Cryptographic Identity to Achieve Tens of Millions of Secure Executions

When AI agents run code in a sandbox, one often-overlooked question is: after the sandbox is paused, resumed, or migrated, how do you ensure the request is still bound to the correct execution instance? Recently, a technical team disclosed the solution used by its sandbox system SPACE — a cryptographic identity mechanism that maintains an error rate below 0.0002% across millions of executions per day.

The Scale Challenge of Sandboxes: Millions of Executions Per Day

According to information the team shared on social media, the SPACE sandbox handles millions of executions per day with an error rate below 0.0002%. That figure means no more than 2 errors occur per million executions. For AI code execution scenarios that demand high reliability, this is a notable level of performance.

The core tension in sandbox environments is this: you must isolate untrusted code while also guaranteeing traceability and consistency of execution. When state changes occur during the sandbox lifecycle — pause, resume, migration — the binding between request and execution can break, leading to security vulnerabilities or execution errors.

Cryptographic Identity: Locking Requests to Executions

SPACE's approach is to assign each execution a cryptographic identity. Specifically, the system uses encrypted credentials to bind a request to a particular execution instance, so that even if the sandbox is migrated physically or logically, the identity remains valid.

The key to this mechanism is "unforgeability." Traditional session IDs or tokens can be guessed or stolen, whereas cryptographic identity is based on a key system, making it difficult for attackers to forge legitimate credentials to hijack the execution flow. When a sandbox resumes after being paused, the system can verify the legitimacy of the request's origin by validating the cryptographic identity, rather than relying on volatile in-memory state.

Cryptographic identity generally refers to an identity built on asymmetric key systems — for example, using public-private key pairs to generate digital signatures or credentials. In a sandbox scenario, each execution instance can have a unique key pair, and the requesting party must hold the corresponding private key to sign and prove its identity. Compared with symmetric keys or session tokens, asymmetric mechanisms avoid the risk of exposing keys during transmission, and signatures are non-repudiable. In addition, short-lived credentials (such as short-term tokens) are often combined with cryptographic signatures to reduce the impact window after a key leak. Understanding this foundation helps assess the actual strength of the "unforgeability" in SPACE's approach.

Pause, Resume, and Migration: Security Consistency Under State Changes

Pausing and resuming sandboxes are common operations — for example, freezing idle instances during resource scheduling, or migrating executions to other nodes during load peaks. Each state change can introduce an attack surface: is the resumed sandbox still the original execution environment? Are credentials leaked during migration?

SPACE unifies these issues under a single framework through cryptographic identity. The credentials carried by a request are bound to the identity of the execution instance; during migration, the identity moves with the execution; during recovery, the system re-verifies the identity chain. According to the original description, this mechanism ensures that "requests are always tied to the right execution."

You may not have noticed that the original article does not disclose the specific cryptographic algorithms or key management details, so its security boundaries in extreme scenarios cannot be evaluated.

Sandbox migration typically involves checkpoint and restore mechanisms: serializing execution state to persistent storage, then deserializing and rebuilding it on another node. During this process, in-memory session information may be lost or tampered with, so identity credentials must be persisted and encrypted together with execution state. The migration trust model must also consider mutual authentication between source and target nodes to prevent man-in-the-middle attacks. SPACE's emphasis on identity moving with execution essentially requires that checkpoint data contain a verifiable identity chain and that integrity be re-validated upon recovery.

Behind the Low Error Rate: A Balance of Engineering and Design

An error rate below 0.0002% is not achieved by cryptographic identity alone. It reflects the overall engineering capability of the entire sandbox system in scheduling, isolation, and state management. Cryptographic identity solves the problem of "identity correctness," while the error rate also involves factors such as the stability of the execution environment and the thoroughness of resource isolation.

Based on public information, SPACE's design approach is worth learning from: pushing the security boundary down from the "network layer" to the "execution layer," and replacing traditional session management with cryptographic primitives. This has reference value for building multi-tenant AI code execution platforms.

An error rate below 0.0002% means only single digits to tens of failures across millions of executions. Such metrics typically cover events such as execution failures, state inconsistencies, or security violations. Reaching this level requires multi-layered fault-tolerance design: resource isolation of the execution environment (such as namespaces and cgroups), atomicity guarantees for state persistence, and idempotent retry mechanisms during failure recovery. Although cryptographic identity can prevent identity mis-binding, it cannot eliminate occasional failures of the underlying infrastructure. Therefore, the low error rate is the combined result of identity correctness, scheduling reliability, and thorough isolation.

Implications for AI Infrastructure

As AI agents increasingly write and execute code autonomously, sandbox security and reliability will become key infrastructure metrics. SPACE's practice shows that cryptographic identity can serve as the cornerstone of sandbox state management, maintaining consistency between requests and executions in dynamic scenarios such as pause, resume, and migration.

However, the team has so far only briefly disclosed its approach via social media, and full technical details (such as identity revocation, key rotation, and trust models for cross-domain migration) have not yet been made public. For developers hoping to replicate a similar solution, more detailed technical documentation is still needed.

One-line Summary

SPACE sandbox uses cryptographic identity to bind requests to executions, handling millions of executions per day with an error rate below 0.0002%.

Paragraph Summary

A technical team disclosed that its sandbox system SPACE uses a cryptographic identity mechanism to solve the problem of broken binding between requests and executions when a sandbox is paused, resumed, or migrated. SPACE handles millions of executions per day with an error rate below 0.0002%. The system assigns each execution an encrypted credential based on a key system, binding requests to specific execution instances in an unforgeable way; when state changes occur, the identity moves with the execution and is re-verified. The low error rate also depends on engineering capabilities such as scheduling and isolation. The approach pushes the security boundary down to the execution layer and offers reference value for AI code execution platforms, though specific algorithms and key management details have not yet been disclosed.