Perplexity publie en open source SPACE, un bac à sable à base de microVM Firecracker pour agents IA
Perplexity a publié en open source SPACE (Sandboxed Platform for Agentic Code Execution), la plateforme de bacs à sable qui fait tourner chaque tâche de Perplexity Computer. Le code, écrit en Rust et diffusé sous licence Apache 2.0 sur GitHub dans sa version 0.8.0, attribue à chaque tâche d'agent sa propre microVM Firecracker, avec son noyau invité et son disque inscriptible. Les identifiants et le trafic sortant sont contrôlés depuis l'extérieur de la VM. Les applications pilotent le système via une API HTTP et des événements serveur (SSE). Il faut un hôte Linux x86_64 avec KVM, btrfs et Docker, en mode Kind (Kubernetes) local ou en mode direct, sans prise en charge de macOS. Les sandboxes passent par quatre états : en cours, en pause (mémoire conservée sur le worker, sans snapshot durable), suspendue (mémoire, état d'exécution et système de fichiers sauvegardés) et supprimée. Elles se suspendent par défaut après six heures d'inactivité. En production, la latence médiane de création est passée de 185 ms à 60 ms par rapport au précédent fournisseur, et le 90e centile de 447 ms à 89 ms. Perplexity affirme que 100 % des sessions Computer reposent désormais sur SPACE.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de MarkTechPost. Lire l'article original →
Pour les équipes qui conçoivent des agents de code ou de navigation, c'est une couche d'isolation éprouvée en production et auto-hébergeable. Son principe est que l'agent dispose des droits root dans le bac à sable, où il installe des paquets et appelle des services, tandis que l'hôte reste hors de son contrôle. Les secrets n'entrent jamais dans l'invité : ils sont injectés au niveau réseau, avec un magasin d'identifiants hiérarchisé, des limites de débit et une journalisation d'audit. Une passerelle réseau propre à chaque sandbox applique la politique de sortie à chaque connexion. L'architecture s'articule autour d'une API adossée à PostgreSQL, de contrôleurs, de services de workers (VM, réseau, volumes, modèles, identifiants) et d'un plan de données, et les systèmes de fichiers racine sont créés par copie sur écriture btrfs. Des pools de sandboxes déjà démarrées accélèrent les créations sous Kubernetes, et des snapshots de base jouent ce rôle sur un nœud unique.
Perplexity a aussi soumis SPACE à un test d'intrusion, publié sous le titre « Escaping SPACE: Part I ». Neuf modèles, avec les droits root dans l'invité, ont effectué 216 essais répartis sur deux tâches et quatre configurations. Aucune des 108 tentatives d'évasion vers l'hôte n'a atteint le secret protégé, et aucun contournement n'a réussi sans réseau (0 sur 54). Avec un réseau partiel, 11 essais sur 54 ont contourné la politique de sortie avant correctifs, grâce à l'usurpation DNS et à des adresses IP de CDN partagées. Quatre modèles y sont parvenus : Claude Opus 5.0, GPT-5.6 Sol, GPT-5.6 Cyber et Kimi K3. Perplexity a ajouté une validation d'adresse source via nftables, et la passerelle termine désormais le TLS en vérifiant le SNI et l'hôte HTTP face à une liste d'autorisation. Lors du nouveau test, aucun contournement n'a été vérifié. La même équipe a testé dix plateformes tierces, dont huit présentaient au moins un contournement de la politique réseau, et a informé chaque éditeur concerné.
Pas d'impact direct sur la France/UE
Le vrai message de SPACE, c'est que l'isolation d'un agent ne se joue plus dans le noyau mais dans le réseau : root dans la VM, secrets injectés de l'extérieur, et c'est la politique de sortie qui décide de tout. Bon, sur le papier, 0 évasion vers l'hôte, c'est propre. Mais 11 contournements sur 54 en réseau partiel avant correctifs, et 8 plateformes tierces sur 10 qui fuient, ça montre où ça casse vraiment. Reste à voir si ça tient en prod face à des modèles qui cherchent la faille tout seuls.