Créer ESPACE : environnements d'exécution sécurisés et efficaces

À mesure que les flux de travail des agents deviennent plus longs et plus autonomes, les environnements dans lesquels ces agents opèrent revêtent autant d'importance que les modèles qui les pilotent. Les agents doivent effectuer un travail réel, comme exécuter du code, modifier des systèmes de fichiers et accomplir des tâches en plusieurs étapes sur des heures ou des jours. Les utilisateurs souhaitent que les agents aient accès aux outils et aux fichiers nécessaires à l'exécution de ces tâches, tout en ayant la certitude que leurs systèmes resteront sécurisés, même en cas de compromission des agents. Un bac à sable permet de rendre tout cela possible : un environnement isolé où un agent peut opérer librement, tandis que l'hôte, les autres locataires et les informations d'identification sensibles restent protégés.

Les approches traditionnelles de bac à sable basées sur des conteneurs ne sont pas conçues pour ces tâches. Elles supposent généralement des travaux de courte durée, sans état, et ont le noyau comme point de défaillance unique. En revanche, les sessions des agents sont persistantes et avec état : un agent accumule des heures de contexte, un système de fichiers de travail et des processus en cours d'exécution qui ne peuvent pas être simplement supprimés et reconstruits à partir de zéro. De plus, la charge de travail interne doit être considérée comme non fiable par défaut, ce qui nécessite des mesures de sécurité renforcées. Les sessions d'agents à exécution longue nécessitent un substrat capable d'isoler un invité hostile, de préserver son état et d'être exploité à grande échelle.

Le principal défi de l'ingénierie des bac à sable provient de la tension qui surgit souvent entre la sécurité, la fonctionnalité et l'efficacité. Par exemple :

Accorder un accès plus large permet à un agent d'accomplir davantage, mais expose une plus grande partie du système à une charge de travail à laquelle vous ne faites pas confiance.

Partager davantage entre les bac à sable accélère la création, mais élargit la surface d'attaque.

La réalisation plus fréquente d'instantanés améliore la récupération et permet des fonctionnalités telles que la restauration, mais nécessite du temps et de l'Espace de stockage.

Les bac à sable agentiques, tels que ceux requis pour exécuter du code, utiliser des Agent Skills, ou exécuter des pipelines Search as Code dans les requêtes Computer, nécessitent ces trois éléments. Nous avons travaillé sans relâche au cours des derniers mois pour concevoir la nouvelle génération d'infrastructure d'agents alimentant nos produits. Aujourd'hui, nous introduisons ESPACE (Sandboxed Platform for Agentic Code Execution) : une plateforme de bac à sable conçue pour les flux de travail agentiques, sécurisée, fiable et efficace à grande échelle. Le mois dernier, nous avons commencé à déployer ESPACE en tant que couche de bac à sable alimentant Perplexity Computer. Au cours de la semaine dernière, elle a pris en charge en toute sécurité des millions de créations de bac à sable et des dizaines de millions de reconnexions, avec des temps de démarrage 3 à 5 fois plus rapides que notre solution précédente.

Cet article présente les décisions architecturales et de conception derrière ESPACE. À ce jour, 100 % des sessions Computer s'exécutent désormais sur ESPACE. Nous sommes impatients de déployer cette plateforme sur encore plus de surfaces afin de fournir à nos utilisateurs et développeurs un environnement d'exécution agentique de premier ordre.

Architecture

À haut niveau, le système est organisé en trois couches.

Le plan de contrôle est le cerveau du système, décidant de ce qui doit exister et où. Il se compose de la passerelle API et des modules de gestion d'état au niveau du cluster.

Les services locaux aux nœuds sont les mécanismes locaux requis pour exécuter le plan du plan de contrôle. Ils assurent le cycle de vie du bac à sable, le stockage, la mise en réseau et les opérations privilégiées sous-jacentes.

Le bac à sable est l'environnement d'exécution isolé lui-même. Il est implémenté sous forme de machine virtuelle couplée au démon space : un processus d'arrière-plan au sein de l'invité qui court-circuite le système de fichiers, le processus et l'accès réseau pour la charge de travail.

Plan de contrôle

La passerelle API est le point d'entrée. Les demandes entrantes sont authentifiées et autorisées, puis traduites en enregistrements de l'état souhaité.

Le plan de contrôle est sans état par conception, toutes les informations durables étant déchargées dans une base de données partagée. Il suit les informations au niveau du cluster sur les bac à sable, telles que le nœud auquel ils sont assignés, leur emplacement d'exécution et s'ils ont été sauvegardés sur un stockage durable. Il compare continuellement l'état souhaité à l'état observé et conduit les deux vers une convergence. Les opérations sont idempotentes, de sorte que le plan de contrôle peut récupérer automatiquement après tout crash, redémarrage ou défaillance partielle.

Services locaux aux nœuds

Les services locaux aux nœuds effectuent le travail réel de préparation des modèles, de démarrage des bac à sable, de câblage du réseau et d'exécution des services d'exécution côté hôte. Chaque nœud exécute un petit ensemble de démons qui gèrent chaque bac à sable qui y est placé, et le nœud est la source de vérité pour les états en direct de ces bac à sable.

Le gestionnaire de bac à sable sait quels bac à sable sont en cours d'exécution, en pause, suspendus ou arrêtés, ainsi que leurs ressources réelles. Il s'exécute sans privilèges et délègue tout travail privilégié au gestionnaire de nœuds, le processus racine unique qui court-circuite les primitives sous-jacentes. Le stockage est géré localement et durablement : les instantanés des états actuels des bac à sable sont enregistrés sur le nœud, et un gestionnaire de volume déplace les instantanés et les modèles vers et depuis le stockage objet si nécessaire pour permettre des opérations entre nœuds. Les portes de sécurité protègent ce à quoi un bac à sable peut accéder : le gestionnaire d'informations d'identification régit l'injection d'informations d'identification sous une autorisation par service, et la passerelle réseau applique la politique de sortie de chaque bac à sable.

Bac à sable

Le bac à sable lui-même est une machine virtuelle (VM) avec son propre noyau invité, exécutant la charge de travail de l'utilisateur derrière une limite d'isolation matérielle. Étant donné que chaque bac à sable possède son propre noyau, une charge de travail compromise ne peut pas s'appuyer sur un noyau hôte partagé comme point de défaillance unique ; même si elle exploite avec succès son noyau invité, cette compromission est confinée à la limite de la VM du bac à sable plutôt que de se propager aux autres charges de travail.

Un démon space s'exécute à l'intérieur de chaque machine virtuelle, servant d'agent léger qui régule chaque action ou modification que la plateforme effectue à l'intérieur de l'invité. Il gère l'accès au système de fichiers et la gestion des processus. Il signale également la disponibilité de l'invité et suit l'activité, afin que la plateforme sache quand un bac à sable est devenu inactif et peut être mis en pause ou récupéré. Il est crucial que le démon space ne parle pas directement aux clients, mais communique plutôt avec l'hôte via un canal privé au sein de la VM. Cela maintient toute l'interaction avec l'invité sur un chemin contrôlé et réserve le réseau du bac à sable uniquement au trafic sortant de la charge de travail.

Trois piliers : sécurité, fonctionnalité et efficacité

Ensuite, nous plongeons dans les propriétés clés qu'ESPACE doit fournir à travers trois piliers : la sécurité, la fonctionnalité et l'efficacité. Comme indiqué précédemment, ces trois piliers tirent les uns contre les autres. Pourtant, nous ne pouvons faire de compromis sur aucun d'entre eux si nous souhaitons prendre en charge des agents puissants à la hauteur des capacités des modèles actuels. La sécurité empêche une charge de travail non fiable, potentiellement hostile, de nuire à l'hôte, aux autres locataires ou aux secrets d'un utilisateur. La fonctionnalité donne aux agents le riche cycle de vie dont ils ont besoin. L'efficacité rend tout cela abordable avec une mémoire, un disque et une puissance de calcul finis.

Sécurité : protection des données et des systèmes

Les plateformes de bac à sable ont besoin d'une sécurité renforcée pour garantir que le code erroné, voire malveillant, exécuté à l'intérieur des bac à sable ne puisse pas causer d'effets nocifs ailleurs. Sans appliquer un contrôle de sortie strict et maintenir les secrets hors du bac à sable, un seul mauvais pas d'un agent pourrait fuiter les clés d'un utilisateur ou exfiltrer le travail.

ESPACE adopte une approche multicouche pour assurer la sécurité des bac à sable. L'isolation du bac à sable comporte deux composants : l'isolation de la VM et l'isolation du processus du système d'exploitation hôte. Les deux doivent être violés pour un accès inter-bac à sable. La communication avec le bac à sable est strictement contrôlée ; les processus ne peuvent communiquer que par des canaux dédiés. La passerelle réseau force toute sortie à passer par elle. Le démon space est le seul canal autorisé entre le bac à sable (non fiable) et la plateforme (fiable).

Les informations d'identification ne vivent jamais là où un agent peut les voler. Le magasin d'informations d'identification se trouve en dehors de la limite du bac à sable et est responsable du cycle de vie des informations d'identification. Il stocke et récupère les secrets via un backend de coffre-fort enfichable, résout les informations d'identification à l'aide d'un scoping hiérarchique, gère les métadonnées telles que la méthode d'injection et l'expiration, et applique des limites de débit et des journaux d'audit sur tous les accès. Si nécessaire, les informations d'identification sont injectées au niveau de la couche réseau ou pré-remplies par un agent de navigateur, au lieu d'entrer directement dans le bac à sable.

Les données sont protégées au repos. ESPACE prend en charge BYOK (Bring Your Own Key) pour protéger les données stockées de manière externe. Les clés de cryptage proviennent du service de gestion des clés du client et n'entrent jamais dans le bac à sable. Si l'entreprise révoque la clé, ses données deviennent illisibles.

Fonctionnalité : alimenter les flux de travail agentiques

Pour prendre en charge les flux de travail agentiques, les bac à sable ont besoin d'un support riche du cycle de vie. Ils doivent être créés rapidement et à grande échelle, car un agent peut en faire démarrer plusieurs à la fois et ne devrait pas attendre que l'un d'entre eux démarre. Ils doivent persister pendant une durée indéterminée, car une Session peut durer quelques minutes ou plusieurs mois. Ils doivent être mis en pause proprement, parfois pendant de longues périodes, comme lorsqu'une tâche est bloquée sur une intervention humaine. Et ils doivent prendre en charge le forking, la restauration et la récupération après crash, afin qu'une session puisse se ramifier, annuler une mauvaise étape ou reprendre après une défaillance au lieu de recommencer à zéro.

ESPACE prend en charge tout ce qui précède. Il modélise le cycle de vie complet du bac à sable en tant que machine à états explicite, ce qui rend possibles des opérations telles que la création, la pause, la reprise, la suspension et la restauration.

Les instantanés sont le mécanisme sous-jacent à la plupart de ces capacités. Un planificateur se déclenche à intervalles réguliers et capture deux types d'instantanés : des instantanés de disque (copies ponctuelles du système de fichiers) et des instantanés complets (points de contrôle de la VM entière en pause). Les instantanés de disque sont capturés fréquemment, tandis que les points de contrôle complets sont moins fréquents. Tout reste sur le nœud et la rétention diminue par niveau. Ces instantanés peuvent être utilisés pour la récupération en cours de session ; par exemple, les instantanés de disque peuvent être utilisés pour restaurer le système de fichiers afin d'annuler une commande destructrice, et les points de contrôle complets permettent à un bac à sable en panne de reprendre à un point d'exécution récent au lieu d'un disque froid.

Lorsqu'un bac à sable est suspendu, la VM est mise en pause, un instantané complet est pris et les Artifacts de l'instantané complet sont téléchargés vers le stockage objet. Une ligne de base de données suit l'instantané et ne devient restaurable qu'une fois que chaque Artifact a atterri, de sorte qu'un instantané partiellement téléchargé ne puisse jamais être repris dans un état corrompu. La restauration est l'inverse de la suspension. Étant donné que l'instantané vit dans le stockage objet plutôt que sur le nœud d'origine, n'importe quel nœud peut ramener le bac à sable. Le planificateur choisit un nœud, ce nœud télécharge les Artifacts, réapplique le delta du système de fichiers sur le modèle et reprend la VM à partir de son état capturé.

Efficacité : optimisation du temps et de l'Espace

Il ne suffit pas d'implémenter les fonctionnalités ci-dessus dans le vide ; elles doivent également être possibles sous des contraintes de ressources strictes. La mémoire et le disque sur un nœud sont finis, et les utilisateurs veulent que les agents opèrent aussi rapidement que possible, de sorte que les opérations de cycle de vie doivent être peu coûteuses en temps et en Espace. Nous ne pouvons pas nous permettre de copier une image de machine complète chaque fois qu'un bac à sable est créé, mis en pause ou ramifié.

Un choix de conception clé rend cela possible : le système de fichiers. ESPACE utilise btrfs comme système de fichiers sur le nœud pour le stockage du bac à sable. Btrfs (système de fichiers B-tree) combine un système de fichiers à copie sur écriture avec une gestion intégrée des volumes logiques. Cela présente quelques avantages :

Les copies Reflink sont rapides, car vous partagez les étendues sous-jacentes, donc seules les métadonnées doivent être copiées.

Les instantanés sont atomiques et rapides, car il suffit de créer une nouvelle racine.

Un stockage minimal est nécessaire, car vous ne stockez que ce qui a changé.

En conséquence, les bac à sable peuvent être créés et restaurés rapidement. Au lieu de créer un bac à sable à partir de zéro à chaque fois, nous conservons un pool de pods déjà chauds qui ont déjà des modèles communs matérialisés sur le disque, et satisfaisons une demande en la liant à un pod dont le modèle correspond déjà. Donner à ce bac à sable son propre système de fichiers racine inscriptible est alors un clone de copie sur écriture plutôt qu'une copie complète. Lorsqu'aucun pod chaud ne convient, nous matérialisons le modèle à la demande ; nous réduisons les demandes simultanées pour la même image en un seul téléchargement, de sorte qu'une rafale de demandes identiques ne se transforme pas en une rafale de travail identique.

Le résultat est un environnement d'exécution de bac à sable qui est à la fois puissant, léger et extrêmement rapide. Lorsque nous avons lancé ESPACE, nous l'avons exécuté parallèlement à notre fournisseur de bac à sable précédent sur le même trafic de production. Tout au long de la semaine de lancement, ESPACE a créé des bac à sable trois à cinq fois plus rapidement dans toute la distribution. Plus précisément, la latence médiane de création est passée de 185 millisecondes à 60 millisecondes (amélioration de 3,1x), et la latence du 90e centile est passée de 447 millisecondes à 89 millisecondes (amélioration de 5,0x). Nous avons observé des améliorations du même ordre de grandeur sur d'autres indicateurs de performance et d'utilisation des ressources.

Cela facilite également la prise d'instantanés de disque roulants, car ils sont rapides, efficaces en termes d'Espace et ne nécessitent pas la mise en pause du bac à sable. De plus, le stockage delta efficace réduit l'Espace nécessaire pour stocker ces instantanés.

Conclusion

Lors de la conception de systèmes complexes, il est tentant de choisir un seul objectif à optimiser de manière isolée. Mais les développeurs d'agents de pointe exigent la sécurité, la fonctionnalité et l'efficacité à parts égales. Avec ESPACE, nous avons entrepris de réaliser une amélioration de Pareto sur les trois piliers.

Chaque choix de conception individuel peut servir plusieurs objectifs à la fois, rendant cet équilibre délicat possible. Les VM par bac à sable donnent à chaque charge de travail son propre noyau, renforçant la sécurité grâce à une isolation forte tout en fournissant la limite de point de contrôle propre sur laquelle les instantanés reposent. Btrfs permet l'implémentation efficace de l'instantané, du forking et d'autres opérations essentielles aux environnements d'exécution agentiques. Le démon space maintient toute interaction avec l'invité sur un chemin contrôlé côté hôte, scellant la limite invité-hôte tout en préservant la liberté de manœuvre des agents. La passerelle réseau centrale médie la sortie et l'injection d'informations d'identification sans jamais exposer les secrets à l'invité.

Le résultat de ces décisions de conception et d'autres est une plateforme qui permet l'orchestration d'agents du monde réel à grande échelle. ESPACE fournit le substrat sur lequel les agents persistants et avec état peuvent aborder en toute sécurité un travail d'une complexité ou d'une durée arbitraire, sans sacrifier ni les performances ni la sécurité.

Aujourd'hui, ESPACE alimente déjà des millions de sessions Perplexity Computer. Nous avons l'intention qu'ESPACE serve de couche unifiée pour le provisionnement et le contrôle des bac à sable dans n'importe quel environnement : des microVM Linux aux invités Windows jusqu'à la propre machine locale d'un utilisateur. Nous travaillons dur pour pousser ESPACE dans ces nouveaux paramètres, afin que les développeurs puissent expédier des produits d'IA qui fonctionnent partout où les utilisateurs travaillent.

Si vous avez envie de façonner la couche de calcul alimentant les agents de demain, nous vous invitons à rejoindre nos équipes.