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

Quand on demande à un agent d’IA d’analyser une feuille de calcul ou de tester un logiciel, on lui confie ses fichiers et ses données en comptant sur lui pour les manipuler en toute sécurité. Les agents ont besoin d’environnements isolés où ils peuvent accomplir ce travail sans exposer les données d’autres utilisateurs ni perturber leurs charges de travail.

À mesure que les agents prennent en charge des tâches plus complexes avec une plus grande autonomie, ces environnements aident à contenir les erreurs et à limiter les dommages que peut causer du code dangereux ou malveillant. Les bacs à sable assurent cette isolation tout en partageant des services du plan de contrôle, des nœuds de travail et une infrastructure de routage.

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

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é des bacs à sable dépend aussi de l’acheminement de chaque requête vers la bonne destination. Même une simple lecture de fichier passe par une infrastructure partagée qui doit suivre l’endroit où le bac à sable s’exécute lorsqu’il est mis en pause, reprend ou se déplace d’une machine à l’autre.

Une lecture de fichier passe par plusieurs composants. Le plan de contrôle de SPACE associe le bac à sable à une exécution et à un nœud de travail. 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 transmet par VSOCK, le transport par socket entre l’hôte et l’invité, à spaced-guest, à l’intérieur de la microVM Firecracker.

Chaque décision repose sur un état qui peut accuser un retard sur les changements d’infrastructure. Une base de données peut conserver un ancien placement, une adresse 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 nœud de travail préserve son identité logique, mais lance une nouvelle exécution. Une requête retardée ou une connexion qui subsiste peut atteindre l’exécution précédente et renvoyer un ancien état sous le bon nom de bac à sable.

Agrandir

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

SPACE sépare l’environnement de l’utilisateur de l’environnement d’exécution 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 d'exécution sélectionnée et son placement, y compris son worker, son substrat et son activation.

Une génération d’exécution distingue les incarnations de l’environnement d’exécution. Sur Kubernetes, la route comprend aussi 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 s’exécute en tant qu’exécution 7 sur le nœud de travail A, puis reprenne en tant qu’exécution 8 sur le nœud de travail 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 ce désaccord.

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 permis. Le composant destinataire compare cette preuve à sa propre identité d’exécution 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 permis. Les capacités visant des ports de service publics précisent aussi le port et le protocole autorisés.

Le gestionnaire de bac à sable destinataire vérifie la signature et compare l’identité complète avec son enregistrement d’exécution conservé 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 deuxième vérification à 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 nœuds de travail et les passerelles ne peuvent pas en émettre.

Les capacités durent 120 secondes, avec une tolérance d’au plus 15 secondes pour le décalage d’horloge à 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 nœud de travail destinataire peut détecter une erreur de routage même lorsque la requête elle-même est autorisée. Il vérifie s’il héberge bien 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 prend toujours en charge l'exécution 7, le worker A la rejette avant de la transférer. Dès qu'un récepteur installe l'identité de l'exécution 8, il rejette aussi les capacités de l'exécution 7, avant même leur expiration.

Cette garantie comporte une limite importante. Une capacité visant l’exécution 7 peut encore correspondre à un nœud de travail qui sert l’exécution 7, jusqu’à ce que ce nœud soit informé du retrait 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 d’exécution correspondant établit l’exécution prévue. Le pont de contrôle doit aussi atteindre les processus et le transport qui appartiennent à cette activation, plutôt qu’un remplaçant qui a 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 associent l’écouteur VSOCK au processus Firecracker attendu à l’aide de la propriété du socket, de l’identité de l’invité et des données du noyau relatives au socket. Le pont ne transfère les opérations qu’après vérification et refuse les reconnexions transparentes. Chaque nouvelle connexion doit de nouveau réussir les 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 à sa passerelle; il n’atteste pas l’identité d’une application arbitraire à l’intérieur de l’invité.

Agrandir

Durée de vie des flux et rétablissement 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 admissibles de se reconnecter à l’exécution courante, sous les mêmes vérifications de sécurité.

Les terminaux et les surveillances de fichiers peuvent survivre aux requêtes qui les ont ouverts. SPACE associe les flux du backend à une époque d’identité, de sorte qu’un flux ne puisse 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été se distinguent du remplacement d’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 touchent que la tentative d’activation, au sein de la même route et de la même génération d’exécution. Les nouvelles ouvertures exigent l’identité mise à jour.

La reprise 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 reprise distinctes, propres à chaque opération. Les signatures, finalités ou profils de port non valides restent refusés.

Une opération admissible peut résoudre l’exécution courante et effectuer une seule nouvelle tentative reconstruite. Le remplacement de l’entrée en 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 sépare la réparation de la route 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 franchir l’admission, même lorsque le WebSocket côté client reste ouvert.

Agrandir

Compromis et limites 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 ensembles 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 nœud de travail et aux services de gestion locaux au nœud. La compromission de l’accès root d’un nœud de travail ou d’un administrateur de grappe privilégié n’entre pas dans le modèle de menace. La vérification du pont est une vérification locale des processus et du transport, et non une attestation à distance appuyée sur le matériel.

La vérification des signatures, les comparaisons d’exécution et la validation du pont ajoutent du traitement 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 sectorielle

La comparaison pertinente porte sur la façon 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é vérifiés le 8 octobre 2026 :

• OpenShell : offre une sélection d’exécution comparable pour les nouveaux appels et une liaison du superviseur à l’environnement d’exécution grâce à des vérifications de génération et d’autorisation à la passerelle, à la validation de l’identité du backend et à la confirmation des connexions actives du superviseur (admission à la passerelle, authentification et liaison de l’environnement d’exécution). SPACE achemine la sélection signée tout au long de son chemin de service et ajoute une vérification des processus et du transport locale au nœud de travail; OpenShell répartit les vérifications correspondantes entre sa passerelle, son identité de lancement et son protocole d’exécution authentifié (conception de l’environnement d’exécution).
• E2B : suit les ID d’exécution et isole les groupes de proxys selon le cycle de vie de 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 au proxy). Ces vérifications ne permettent pas de distinguer de l’exécution plus récente sélectionnée une exécution plus ancienne encore enregistrée comme active sur un destinataire périmé disposant d’identifiants correspondants, bien que le démantèlement normal supprime les routes et ferme les connexions liées au cycle de vie (identifiants, démantèlement).
• CubeSandbox : répare le routage à la reprise et invalide les caches, mais l’entrée privée utilise des identifiants propres au bac à sable et transfère les requêtes sans incarnation d’exécution attendue (routage à la reprise, routage d’entrée). La réparation des routes réduit les fenêtres de routes périmées; la capacité liée à l’exécution de SPACE donne aussi au destinataire un fondement indépendant pour rejeter la mauvaise incarnation.

L’identité comme limite d’isolation

Une délégation sûre exige que le travail de chaque agent reste dans les limites prévues pour lui. 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 validant les points de terminaison du pont et en liant les connexions à l’exécution qui les a autorisées, SPACE préserve ces limites à mesure que les bacs à sable sont mis en pause, reprennent et 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 lacunes.