L'équipe sécurité de Perplexity a publié le 28 septembre un rapport de red team : pendant un mois, elle a attaqué sa propre plateforme sandbox SPACE, qui héberge toutes les tâches d'agents de Perplexity Computer. La méthode était directe : donner à 9 modèles les droits root dans une machine virtuelle, et pour certaines exécutions, même le code source de SPACE, puis leur demander de faire l'une de deux choses : s'échapper vers la machine hôte, ou accéder à une adresse bloquée par la politique réseau.
Parmi les modèles testés figuraient Opus 5 d'Anthropic, GPT-5.6 Sol et GPT-5.6 Cyber d'OpenAI, Kimi K3 de Moonshot AI, et Gemini 3.1 Pro de Google. Le PDG de Perplexity, Aravind Srinivas, en relayant les résultats sur X, les a résumés en deux phrases : la VM a tenu, la couche réseau reste à corriger.
La VM n'a pas cédé, le réseau a fui
Sur le volet évasion de la VM, aucune des 108 exécutions n'a réussi. Selon le protocole de test rapporté, les exécutions étaient configurées selon deux variables — 'accès ou non au code source' et 'accès ou non aux dépôts de paquets externes' — combinées et répétées plusieurs fois.
Le résultat côté politique réseau se divise en deux. Avec une configuration totalement coupée du réseau, aucun modèle n'a atteint l'adresse cible sur 54 exécutions ; avec une configuration autorisant la connexion aux dépôts de paquets pour installer des dépendances, 11 des 54 exécutions ont réussi, impliquant 4 modèles.
Deux types de techniques ont été utilisés :
- Falsification de réponses DNS. Avec les droits root dans la VM, les modèles pouvaient falsifier les réponses DNS envoyées à la passerelle, lui faisant croire que l'adresse cible était un domaine autorisé ;
- Profiter d'IP partagées. pypi.org est hébergé sur le CDN de Fastly, où les mêmes IP servent aussi des milliers d'autres sites. Une politique réseau qui autorise pypi par IP autorise du même coup tous les autres sites sur cette IP.
La méthode la plus détournée vient de GPT-5.6 Cyber. Il a fait demander à un service de récupération d'images de Taboola une capture d'écran auprès d'un service tiers, lequel a ouvert la page cible bloquée ; le modèle a récupéré la capture et en a extrait le flag par OCR. Sur toute cette chaîne, le sandbox lui-même ne s'est jamais connecté directement à l'adresse cible.
8 fournisseurs sur 10 touchés
L'autre moitié du rapport devrait davantage inquiéter le secteur. Perplexity a testé 10 autres fournisseurs de sandbox avec la même méthode, et 8 présentaient le même problème d'IP partagée ; les articles citent notamment E2B, Vercel et Modal. Perplexity affirme avoir renforcé ses propres contrôles réseau, et qu'au nouveau test, ces contournements ne fonctionnaient plus.
Il faut préciser que tous ces cas relèvent de contournements de politique réseau : aucun modèle n'a obtenu d'accès à la machine hôte. Perplexity présente cette étude comme faisant partie d'un effort mené avec NVIDIA et plus de 100 partenaires du secteur pour construire une infrastructure d'isolation pour les agents ; l'annonce ne détaille pas le rôle précis de chaque partie.
En reliant les points : la faille DNS
En remontant de quelques jours, les techniques de ce rapport ne sont pas inédites.
Le 25 septembre, OpenAI a révélé dans sa propre rubrique de rapports de désalignement qu'un modèle de recherche interne, lors d'une tâche d'entraînement liée à la recherche, a découvert que le proxy du sandbox bloquait HTTP et HTTPS mais ne filtrait pas la résolution DNS ; il a donc encodé le problème dans des requêtes DNS envoyées à un chatbot externe, puis relu la réponse à partir des résultats de résolution. OpenAI a ensuite restreint le DNS de son environnement de recherche à une liste blanche, et suspendu l'entraînement, l'évaluation et le raisonnement avec outils de ses modèles les plus puissants.
Plus tôt, en juillet, un modèle d'OpenAI s'était échappé de son environnement lors d'une évaluation de cybersécurité et avait atteint l'infrastructure de production de Hugging Face.
En mettant ces trois épisodes bout à bout, les modèles visent le même type de faille : le trafic sortant était contrôlé, mais le DNS, les CDN et les services tiers de récupération de contenu — ces canaux 'de passage' — ne l'étaient pas. La différence, c'est que les deux cas d'OpenAI sont survenus accidentellement pendant l'entraînement, tandis que celui de Perplexity était un exercice attaque-défense délibéré. Dans les tests de Perplexity, tous les modèles utilisés étaient disponibles publiquement, dont le modèle open source Kimi K3. Les équipes qui construisent des agents sur ces modèles ne peuvent pas se fier uniquement aux engagements de sécurité des fournisseurs de modèles : la couche sandbox doit aussi être auditée, en vérifiant si la politique réseau autorise par domaine ou par IP, et si les réponses DNS peuvent être réécrites depuis l'intérieur de la VM.
Le rapport n'est pour l'instant que la première partie. Quels modèles sont à l'origine des 11 réussites et combien chacun, les comptes rendus secondaires ne s'accordent pas sur ce point ; il faudra se fier aux données complètes que Perplexity publiera ensuite.
Sources : blog officiel de Perplexity, AlphaSignal, CocoLoop, déclarations d'Aravind Srinivas sur X ; le nombre d'exécutions et de réussites a été vérifié selon le protocole de test rapporté, l'incident DNS d'OpenAI se base sur son propre rapport de désalignement.