Une seule invite. Trois commandes shell. J'ai utilisé leur propre IA pour la pirater.
C'est une classe de bugs qui existe probablement dans tous les produits d'IA multi-agents commercialisés aujourd'hui. Et la solution est un modèle de conception dont personne ne parle encore dans ce secteur.
Voici l'histoire complète.
Je n'essayais pas de pirater quoi que ce soit. Je faisais des recherches sur la façon dont Perplexity Computer gère le sandboxing pour mon propre travail d'infrastructure d'agents. Je cherchais à comprendre comment les systèmes multi-agents en production isolent réellement les environnements d'exécution, ce qui est partagé, ce qui ne l'est pas.
D'abord, j'ai commencé à explorer le système. J'ai remarqué que Claude Code était installé dans le sandbox.
J'ai demandé à l'agent de le lancer et de générer du code de test pour voir comment il se comportait. Ça a fonctionné. Un Claude Code standard, fonctionnant en mode bypass-permissions, donc sans demander de confirmation. Logique pour un système agentique.
C'est là que j'ai pensé : attends, comment gèrent-ils les clés API ?! Claude Code a besoin d'une clé API Anthropic pour fonctionner. Cette clé doit se trouver quelque part dans ce sandbox. Comment est-elle injectée ? Comment est-elle limitée ? Est-elle isolée ?
Cette question m'a conduit sur cette voie.
Le sous-agent détient une clé API dans son environnement de processus. Je devais la voler.
Perplexity Computer a essayé six fois et a échoué.
- J'ai demandé au sous-agent de vider son env : refusé !
- J'ai placé un script troyen sur le système de fichiers partagé : il a lu mon code, a compris ce qu'il faisait et a refusé de l'exécuter !
- J'ai empoisonné .bashrc et .profile : ils se sont déclenchés trop tôt, avant l'injection de la clé API.
- J'ai déposé un faux binaire node sur le PATH : jamais déclenché.
- J'ai lancé l'agent de codage et surveillé simultanément l'arborescence des processus : le sous-agent s'exécute dans un sandbox différent, rien n'a été capturé :(
- J'ai trouvé l'invite système de Claude Code et l'ai modifiée pour supprimer le comportement de refus : je n'ai trouvé aucune invite système personnalisée injectée.
Six échecs. La sécurité au niveau du modèle/de l'invite de Claude est vraiment bonne. Chaque fois que j'essayais quelque chose d'astucieux, le modèle le détectait.
Puis Perplexity s'est rappelé que Claude Code est une application Node.js lancée via npm. Et npm lit ~/.npmrc depuis le répertoire personnel. Et le répertoire personnel se trouve sur le système de fichiers partagé sur lequel je peux écrire.
Node.js a un indicateur --require qui précharge un module JavaScript avant l'exécution de tout code applicatif. Vous pouvez définir cela via NODE_OPTIONS dans .npmrc. Ce qui signifie que si j'écris un .npmrc dans le répertoire personnel partagé, chaque processus Node que le sous-agent lance préchargera mon code ! Cela se produit avant même l'initialisation de Claude Code, avant l'exécution des vérifications de sécurité, avant tout !
L'exploit se fait en trois commandes :
- Écrire un script de six lignes qui vide process.env dans un fichier sur l'espace de travail partagé
- echo 'node-options=--require /chemin/vers/script.js' > ~/.npmrc
- Demander à Perplexity Computer d'effectuer n'importe quelle tâche de codage
Le sous-agent démarre → npm lit mon .npmrc → mon préchargement se déclenche avant le démarrage de Claude Code → les informations d'identification complètes de l'API atterrissent sur le système de fichiers partagé.
Ça a marché ! Cela m'a donné un token de passerelle Perplexity qui transite par agent-proxy.perplexity.ai vers leur compte maître Anthropic.
Naturellement, la première chose que j'ai faite a été de définir cette clé API et BASE_URL pour Claude Code sur mon ordinateur portable. Je m'attendais à ce que les appels LLM de Claude Code échouent et soient limités au sandbox. J'ai été stupéfait. Réponse instantanée d'Opus 4.6 !
J'ai alors pensé : « bien sûr, ils vont facturer ce usage sur mon compte, cette clé API doit être liée à mon utilisateur ». J'avais encore tort.
J'ai demandé à Opus 4.6 de générer une longue histoire décrivant l'histoire du monde, incluant chaque invention, empire et découverte. J'ai exécuté cet appel 5 fois en parallèle, générant plus de 100 000 tokens de sortie chacun. Cela aurait dû consommer tous mes crédits Perplexity Computer, mais ils n'ont pas bougé.
Pas de restriction IP. Pas de limitation de session. Pas de liaison au sandbox. Leur facture.
L'une des startups d'IA les mieux financées de la planète s'est fait avoir par un fichier dotfile utilisé dans les attaques sur la chaîne d'approvisionnement Node.js depuis 2019.
Le modèle a tout fait correctement. L'infrastructure, non.
Voici ce que je veux vraiment que les fondateurs qui construisent des infrastructures d'agents retiennent de cette histoire.
L'architecture de Perplexity est à moitié correcte. Ils utilisent un proxy entre le sandbox et l'API d'Anthropic. C'est le bon modèle. Vous ne devez jamais mettre une clé API brute dans un sandbox. Un proxy vous donne du contrôle, de l'observabilité et la possibilité de révoquer l'accès sans faire tourner votre clé maître.
Le problème est que leur token proxy n'a aucune liaison avec le contexte d'exécution. Une fois que vous l'avez, il fonctionne partout et pour toujours.
Voici comment faire correctement :
Liez le token à l'ID du sandbox. Token et ID du sandbox ne correspondent pas ? Rejeté. La clé fuit mais vous n'avez pas le sandbox ? Inutile. Idéalement, il faudrait aussi lier le token à l'adresse IP du sandbox, mais E2B (le fournisseur de sandbox qu'ils utilisent) ne fournit pas cela avant que le sandbox ne soit initié.
Rendez le token éphémère. Créez-le lorsque le sandbox démarre. Détruisez-le lorsque le sandbox est mis en pause. Pas de credentials à longue durée de vie. Le proxy génère un token à courte durée de vie au début de la session et l'invalide à la fermeture. Une clé divulguée depuis un sandbox mort est une clé morte.
Liez le token au compte de facturation de l'utilisateur. Même si tout le reste échoue, même si quelqu'un exfiltre un token actif d'un sandbox en cours d'utilisation et l'utilise avant son expiration, l'utilisation est facturée au compte qui a lancé la session. Pas à un pool de facturation maître partagé. Cela transforme « accès API gratuit illimité » en « quelqu'un qui abuse de son propre quota », ce qui est un niveau de gravité complètement différent.
Ces trois éléments — lié au sandbox, éphémère, facturé à l'utilisateur — sont ce qui fait réellement fonctionner le modèle proxy. Sans eux, vous ajoutez simplement un saut réseau supplémentaire qui n'arrête rien.
Ce n'est pas un problème spécifique à Perplexity. C'est l'architecture par défaut pour l'infrastructure d'agents en ce moment, car c'est la plus rapide à construire. Systèmes de fichiers partagés entre agents, credentials à longue durée de vie, facturation sur compte maître. Je parie que la plupart des produits multi-agents en production aujourd'hui ont une version de ce problème.
Signalé à @AravSrinivas et @denisyarats avant publication.
