Comment SPACE achemine les requêtes vers la bonne exécution de bac à sable

Lorsqu’une personne demande à un agent IA d’analyser une feuille de calcul ou de tester un logiciel, elle lui fait confiance pour manipuler ses fichiers et ses données en toute sécurité. Les agents ont besoin d’environnements isolés dans lesquels ils peuvent mener ce travail sans exposer les données d’autres utilisateurs ni perturber leurs charges de travail.

À mesure que les agents se chargent de tâches plus complexes avec une plus grande autonomie, ces environnements permettent de contenir les erreurs et de limiter les dégâts que peut causer un code dangereux ou malveillant. Les bacs à sable assurent cette isolation tout en partageant les services du plan de contrôle, les nœuds workers et l’infrastructure de routage.

Cette infrastructure partagée doit acheminer chaque opération vers l’exécution autorisée à la traiter. Une route obsolète peut envoyer une requête valide vers un autre bac à sable, ou vers une exécution antérieure du bon bac à sable. SPACE, la plateforme de bacs à sable sécurisée de Perplexity, lie chaque opération à une exécution sélectionnée et vérifie la destination avant de transférer la requête.

Depuis des mois, SPACE traite des millions d'exécutions par jour, chacune protégée par une identité cryptographique unique, avec un taux d'erreur inférieur à 0,0002 % et aucune connexion interrompue.

Le problème du routage

La sécurité d’un bac à sable dépend aussi de l’acheminement de chaque requête vers la bonne destination. Même une simple lecture de fichier transite par une infrastructure partagée qui doit savoir en permanence où s’exécute le bac à sable lorsqu’il se met en pause, reprend ou passe d’une machine à l’autre.

Une lecture de fichier traverse plusieurs composants. Le plan de contrôle de SPACE associe le bac à sable à une exécution et à un worker. La requête entre par node-api, passe au gestionnaire de bac à sable, sbx-manager, puis traverse un socket Unix jusqu’au pont hôte, spaced-host. Le pont la transfère via VSOCK, le transport par socket entre l’hôte et l’invité, jusqu’à spaced-guest au sein de la microVM Firecracker.

Chaque décision repose sur un état qui peut accuser un retard par rapport aux évolutions de l’infrastructure. Une base de données peut conserver un ancien placement, une adresse mise en cache peut pointer ailleurs, ou un chemin de socket peut être repris par un autre écouteur. Une connexion réussie peut tout de même atteindre la mauvaise destination. Une lecture pourrait exposer les données d’un autre utilisateur ; une écriture pourrait modifier le mauvais système de fichiers.

Les instantanés posent un autre problème. Reprendre un bac à sable sur un autre worker préserve son identité logique, mais démarre une nouvelle exécution. Une requête retardée ou une connexion persistante peut atteindre l’exécution précédente et renvoyer un ancien état sous le nom du bon bac à sable.

Agrandir

Identité du bac à sable et identité d'exécution

SPACE sépare l’environnement de l’utilisateur du runtime qui le sert :

• Identité du bac à sable : l’ID stable de l’environnement logique. L’autorisation de l’appelant établit l’accès à ce bac à sable.
• Identité de route/d'exécution : l'incarnation de runtime sélectionnée et son placement, notamment son worker, son substrat et son activation.

Une génération d’exécution distingue les incarnations du runtime. Sur Kubernetes, la route inclut également l’UID du pod. Les adresses localisent les points de terminaison ; l’identité d’exécution détermine si ces points de terminaison peuvent servir l’opération.

Supposons que le bac à sable S tourne en tant qu’exécution 7 sur le worker A, puis reprenne en tant qu’exécution 8 sur le worker B. Une requête sélectionnée pour l’exécution 8 doit échouer si elle atteint l’exécution 7. Vérifier uniquement l’ID du bac à sable ne permettrait pas de détecter cette divergence.

Agrandir

Sélection d'exécution signée

Chaque requête porte une preuve signée indiquant quelle exécution de bac à sable peut la traiter et quel accès est autorisé. Le composant destinataire confronte cette preuve à sa propre identité runtime avant de laisser la requête se poursuivre.

Après l’autorisation de l’appelant, SPACE émet une capacité signée de courte durée qui identifie le bac à sable, l’exécution, le placement et l’accès autorisé. Les capacités de port de service publiques précisent également le port et le protocole autorisés.

Le gestionnaire de bac à sable destinataire vérifie la signature et compare l’identité complète à son enregistrement runtime persisté localement. La signature établit qui a autorisé la sélection. La comparaison établit si cette sélection correspond au destinataire.

Le trafic ServicePort fait l’objet d’une seconde vérification au niveau de la passerelle réseau propre à chaque bac à sable, netgtw, avant l’ouverture d’une connexion vers l’invité. La passerelle compare l’identité à l’état d’activation de confiance et vérifie le port et le protocole. Les opérations de contrôle passent ensuite à la vérification des points de terminaison du pont.

SPACE utilise des signatures Ed25519. Les clés de signature du plan de contrôle émettent les capacités ; les clés de vérification publiques présentes sur les workers et les passerelles ne peuvent pas en émettre.

Les capacités ont une durée de vie de 120 secondes, avec une tolérance de décalage d’horloge pouvant atteindre 15 secondes pour l’expiration. Une signature valide et un jeton non expiré restent insuffisants lorsque l’identité sélectionnée et l’identité installée divergent.

Agrandir

Rejet à la mauvaise destination

Le worker destinataire peut détecter une erreur de routage même lorsque la requête elle-même est autorisée. Il vérifie qu’il fait bien tourner l’exécution sélectionnée pour cette requête et rejette la requête en cas de divergence.

Si une requête sélectionnée pour l'exécution 8 atteint le worker A, qui sert toujours l'exécution 7, le worker A la rejette avant de la transmettre. Dès qu'un récepteur installe l'identité de l'exécution 8, il rejette également les capacités de l'exécution 7, avant même leur expiration.

Cette garantie comporte une limite importante. Une capacité destinée à l’exécution 7 peut encore correspondre à un worker qui sert l’exécution 7, jusqu’à ce que ce worker soit informé du retrait de cette exécution ou que la capacité expire. L’application locale des contrôles et la durée de vie limitée des capacités agissent de concert pendant la propagation des mises à jour.

Agrandir

Vérification des points de terminaison du pont

Un enregistrement runtime correspondant établit l’exécution prévue. Le pont de contrôle doit aussi atteindre les processus et le transport appartenant à cette activation, plutôt qu’un remplaçant ayant hérité de la même adresse.

Les gestionnaires de bac à sable et de nœud vérifient les identifiants du pair du pont hôte ainsi que l’identité des processus du pont et de Firecracker, y compris leurs heures de démarrage, afin de détecter les ID réutilisés ou les exécutables modifiés

Les vérifications du transport lient l’écouteur VSOCK au processus Firecracker attendu à l’aide de la propriété du socket, de l’identité de l’invité et de preuves issues des sockets du noyau. Le pont ne transfère les opérations qu’après vérification et refuse les reconnexions transparentes. Chaque nouvelle connexion doit de nouveau passer ces vérifications.

Cette vérification couvre le pont de contrôle Firecracker sur Kubernetes et sur les hôtes gérés directement. Le trafic ServicePort fait l’objet de vérifications d’exécution et de port au niveau de sa passerelle ; il n’atteste pas l’identité d’une application arbitraire au sein de l’invité.

Agrandir

Durée de vie des flux et récupération des routes

Certaines connexions restent ouvertes pendant que l’exécution d’un bac à sable change ; les vérifications d’identité doivent donc aller au-delà de la requête initiale. SPACE retire les connexions liées à l’ancienne exécution et permet aux opérations éligibles de se reconnecter à l’exécution actuelle, sous réserve des mêmes contrôles de sécurité.

Les terminaux et les surveillances de fichiers peuvent survivre aux requêtes qui les ont ouverts. SPACE associe les flux backend à une époque d’identité afin qu’un flux ne puisse pas rester rattaché à l’exécution précédente une fois que le destinataire a installé une exécution de remplacement.

SPACE revérifie l’identité durable avant d’ouvrir un flux. Le remplacement de sa route ou de son exécution annule le bail du flux, ce qui interrompt les entrées et les sorties.

Les changements de propriétaire sont distincts du remplacement d’une exécution. Le transfert d’une opération de cycle de vie sur un résident Kubernetes inchangé préserve son identité de route, ses capacités non expirées et ses flux. La passerelle préserve également les flux établis lors de changements qui ne concernent que la tentative d’activation, au sein de la même génération de route et d’exécution. Les nouvelles ouvertures nécessitent l’identité mise à jour.

La récupération préserve ces vérifications. Le comparateur d'identité peut renvoyer RefreshRoute en cas de non-concordance d'incarnation au sein du même bac à sable, ou Deny pour un bac à sable différent. Seul un signal d'actualisation reconnu déclenche la réparation de la route après un rejet d'identité. Les défaillances de transport suivent des règles de récupération distinctes, propres à chaque opération. Les signatures, finalités ou profils de port invalides restent refusés.

Une opération éligible peut résoudre l’exécution actuelle et effectuer une seule nouvelle tentative avec une requête reconstruite. Le remplacement du cache est conditionné à la route rejetée, ce qui empêche un rejet tardif d’évincer une entrée plus récente. L’actualisation de la session native préserve l’expiration initiale du cache, ce qui dissocie la réparation des routes du renouvellement de l’autorisation de l’appelant.

Les règles de rejeu restent propres à chaque opération. Un backend de remplacement doit de nouveau passer l’admission, même lorsque le WebSocket côté client reste ouvert.

Agrandir

Compromis et frontières de confiance

L’identité d’exécution devient un état critique pour la sécurité. Les mises à jour du plan de contrôle et les lots de clés de vérification doivent parvenir aux composants de service, et le retrait prend effet lorsque chaque destinataire installe la mise à jour. La courte durée de vie des capacités limite leur réutilisation pendant la propagation.

La conception suppose que l’application de l’identité est activée et fait confiance au signataire du plan de contrôle, au noyau du worker et aux services de gestion locaux au nœud. La compromission de l’accès root d’un worker ou d’un compte d’administrateur de cluster privilégié sort du cadre du modèle de menace. La vérification du pont est une vérification locale des processus et du transport, et non une attestation à distance reposant sur le matériel.

La vérification des signatures, les comparaisons de runtime et la validation du pont ajoutent du travail sur le chemin des requêtes. Elles s’appuient sur un état local plutôt que sur une consultation d’autorisation à distance à chaque saut privé.

Comparaison avec le secteur

La comparaison pertinente porte sur la manière dont les plateformes gèrent une requête autorisée qui atteint la mauvaise exécution du bon bac à sable. Ces constats concernent les implémentations examinées, et non la sécurité globale des plateformes. SPACE, OpenShell et E2B ont été examinés le 8 octobre 2026 :

• OpenShell : assure une sélection d’exécution comparable pour les nouveaux appels ainsi qu’une liaison entre superviseur et runtime, grâce aux vérifications de génération et d’autorisation de la passerelle, à la validation de l’identité du backend et à la confirmation des connexions actives du superviseur (admission par la passerelle, authentification et liaison du runtime). SPACE transporte la sélection signée tout au long de son chemin de service et y ajoute une vérification des processus et du transport, locale au worker ; OpenShell répartit les vérifications correspondantes entre sa passerelle, l’identité de lancement et son protocole runtime authentifié (conception du runtime).
• E2B : suit les ID d’exécution et isole les pools de proxys selon le cycle de vie Firecracker, mais son proxy entrant sélectionne le bac à sable logique et le port sans identité d’exécution attendue que le destinataire pourrait comparer (publication des routes, admission par le proxy). Une exécution plus ancienne, toujours enregistrée comme active sur un destinataire obsolète disposant d’identifiants correspondants, ne peut pas être distinguée par ces vérifications de la nouvelle exécution sélectionnée, même si l’arrêt normal supprime les routes et ferme les connexions liées au cycle de vie (identifiants, arrêt).
• CubeSandbox : répare le routage à la reprise et invalide les caches, mais l’ingress privé utilise des identifiants limités au bac à sable et transfère les requêtes sans incarnation de runtime attendue (routage à la reprise, routage de l’ingress). La réparation des routes réduit les fenêtres de routes obsolètes ; la capacité liée à l’exécution de SPACE donne en outre au destinataire une base indépendante pour rejeter la mauvaise incarnation.

L’identité comme limite d’isolation

Une délégation sûre suppose de maintenir le travail de chaque agent dans les limites qui lui sont assignées. Une microVM assure l’isolation, tandis que la plateforme qui l’entoure doit garantir que chaque requête et chaque connexion en cours atteignent l’exécution autorisée à les traiter.

SPACE intègre l’identité d’exécution à cette protection. En vérifiant les destinations, en contrôlant les points de terminaison du pont et en liant les connexions à l’exécution qui les a autorisées, SPACE préserve ces limites lorsque les bacs à sable se mettent en pause, reprennent ou se déplacent.

Nous poursuivons ce travail à mesure que l’infrastructure évolue. Pour SPACE comme pour les autres plateformes de bacs à sable, la sécurité exige de tester ces chemins face aux erreurs de routage courantes comme aux charges de travail hostiles, puis de renforcer les limites partout où ces tests révèlent des failles.