Le journal de l'agent était dans leur cloud

Le vendredi 23 octobre, Warp a pris connaissance de ce que son fondateur et PDG, Zach Lloyd, a appelé « une exploitation active et étroitement ciblée d'un fournisseur de l'infrastructure de Warp ». Warp, parti d'un terminal, est devenu ce qu'il appelle un environnement de développement agentique, et les données dérobées sont des traces d'agent et de la télémétrie utilisateur. Lloyd fixe la limite haute à environ 1 % des utilisateurs de Warp. Le site de l'entreprise revendique au moins 800 000 utilisateurs : 1 %, c'est de l'ordre de 8 000 développeurs. BleepingComputer a rapporté l'annonce hier.

Warp dit avoir détecté l'opération en quelques heures et l'avoir contenue. L'entreprise a fait appel à CrowdStrike, informé les forces de l'ordre et prévenu les utilisateurs concernés. Selon Risky Business, Lloyd affirme que les intrus ont utilisé un essaim d'agents IA pour pénétrer chez le fournisseur. Warp n'a ni nommé ce fournisseur, ni décrit la vulnérabilité, ni précisé si les traces volées contenaient du code source, des prompts ou des identifiants. Son conseil aux utilisateurs : surveiller l'activité de leur compte et traiter les messages non sollicités avec plus de prudence que d'habitude.

C'est la deuxième fuite touchant un agent de code ce mois-ci à partir des serveurs d'un fournisseur. Le 16 octobre, des attaquants ont atteint les clés d'API de fournisseurs qu'environ 1,4 % des utilisateurs d'OpenCode Console avaient enregistrées, et certains ont découvert des factures allant jusqu'à 1 700 $ qu'ils n'avaient pas générées. Nous en avons parlé dans Les clés étaient dans leur console.

Ce que contient une trace d'agent

Un agent de code travaille en boucle. Il lit un fichier, lance une commande, lit la sortie et décide de la suite, et une trace enregistre chaque étape. Cela comprend le prompt que vous avez tapé, les fichiers que l'agent a ouverts, les diffs qu'il a écrits, les commandes shell qu'il a lancées et ce que ces commandes ont affiché.

C'est par ce dernier point que les secrets s'y retrouvent. Un agent qui débogue un déploiement en échec lance env, ouvre .env, affiche un fichier de configuration et colle une stack trace contenant une chaîne de connexion. Dans Le jeton est resté dans la transcription, Trellix a montré des agents de code qui copiaient des secrets du trousseau vers des lignes de commande, l'historique du shell et leurs propres transcriptions, comme simple effet de bord d'un travail ordinaire. Les données clients y entrent de la même manière : l'agent ouvre un CSV ou interroge une table pour vérifier un correctif, et les lignes atterrissent dans la trace.

Une trace contient aussi votre code par morceaux, les noms des hôtes internes et la chronologie de ce sur quoi vous avez travaillé. Pour un attaquant, quelques milliers de traces forment une liste de développeurs à hameçonner, chacun avec une histoire crédible sur le projet qui l'occupait cette semaine-là. C'est ce risque qui se cache derrière le conseil de Warp sur les messages non sollicités.

La même session sur une machine Bromure

Bromure Agentic Coding exécute Claude Code, Codex, Grok, Kimi et omp dans des VM Ubuntu sur votre Mac. Chaque requête d'une machine, y compris chaque appel de l'agent à son modèle, passe par un proxy sur le Mac. C'est dans ce proxy que Bromure enregistre la trace, échange les identifiants et applique vos règles réseau. Reprenez la session de débogage ci-dessus et lancez-la là.

La trace est écrite sur votre Mac

La trace de session de Bromure répond à la question qu'on se pose après un incident : qu'a fait l'agent ? Les nouvelles machines enregistrent les AI request details : un enregistrement de métadonnées pour chaque requête, plus les corps complets des requêtes et des réponses pour les fournisseurs de modèles. Le Trace Inspector (⇧⌘I) analyse ces corps et en tire une vue conversation avec chaque appel d'outil, chaque commande shell lancée par l'agent et chaque fichier qu'il a lu ou écrit. bromure-cli trace vous donne les mêmes données dans un terminal.

Tout cela se trouve dans ~/Library/Application Support/BromureAC/traces/ sur votre Mac. Les corps capturés sont scellés en AES-GCM sous une clé conservée dans votre trousseau, avec les permissions de fichier 0600. Pour une installation individuelle, aucun enregistrement de trace, aucun corps ni aucun résumé n'est envoyé où que ce soit, et le proxy n'a aucun point de collecte analytique branché pour les utilisateurs individuels. Les classificateurs d'injection de prompt qui lisent le même trafic tournent eux aussi sur le Mac.

Aucun éditeur n'en détient de copie, ni ses fournisseurs. Un attaquant qui pénètre chez un prestataire de journalisation n'y trouve aucune de vos sessions.

Les secrets dans la trace sont des substituts

Revenons à la session de débogage. L'agent lance env, ouvre .env et affiche la configuration de déploiement. Sur une machine Bromure, chaque identifiant que vous avez configuré est un faux à l'intérieur de la VM. ANTHROPIC_API_KEY contient une valeur sk-ant-api03-brm-, GH_TOKEN et ~/.git-credentials contiennent un substitut ghp_, ~/.aws/config pointe vers un assistant qui fournit une fausse clé secrète, et les clés SSH restent sur l'hôte derrière un socket d'agent. Les clés que vous importez depuis un .env existant deviennent elles aussi des substituts. Le proxy ne met la vraie valeur sur le fil que pour l'hôte auquel cet identifiant appartient.

Tout ce que l'agent affiche et colle dans sa conversation est donc un substitut. C'est vrai pour chaque copie : les journaux du fournisseur de modèle, les fichiers d'historique de la CLI de l'agent, un rapport de plantage, une trace. Hors de la machine, les substituts n'authentifient nulle part. Si l'un d'eux part vers un hôte pour lequel il n'a pas été émis, le proxy bloque la requête avec un HTTP 451, met la VM en pause et affiche This environment may have been compromised avec l'identifiant, l'hôte auquel il appartient et l'hôte vers lequel il a été envoyé.

La trace de Bromure va encore plus loin. Les en-têtes Authorization, Cookie, api-key et similaires sont réécrits en <redacted> avant toute écriture, et chaque échange d'identifiant est conservé sous forme d'aperçu limité aux premiers et derniers caractères, comme sk-a…f9q3. Le vrai secret n'entre jamais dans un enregistrement de trace, chiffré ou non.

Les données clients restent sur le Mac

Activez PII Protection dans les réglages de la machine et le proxy repère les données personnelles dans chaque requête avant qu'elle parte vers le fournisseur de modèle : noms, adresses e-mail, numéros de téléphone, numéros de carte et de compte bancaire, identifiants officiels et adresses postales. Il remplace chaque valeur par un substitut réaliste, un nom inventé ou une adresse @example.com, et remet les vraies valeurs dans la réponse, y compris dans les arguments des appels d'outils. La détection tourne sur le Mac avec le modèle Rampart intégré.

L'agent travaille avec les vraies lignes, et le fournisseur voit les substituts. Un même client reçoit le même substitut à chaque tour, si bien que le cache de prompt continue de fonctionner. La Security Timeline compte chaque échange, 3 names · 1 phone number → api.anthropic.com, sans journaliser une seule valeur.

Pour le travail qui doit rester sur le Mac, dirigez l'agent vers un modèle local. Les modèles MLX tournent sur le GPU du Mac, et ces tours ne vont nulle part ailleurs.

Vous choisissez qui reçoit quoi que ce soit

Les CLI d'agents ne parlent pas qu'à leur modèle. Le signalement d'erreurs, les feature flags et la télémétrie d'usage partent chacun vers un hôte différent. Dans le panneau Guardrails de la machine, réglez Unmatched traffic sur Deny et autorisez les hôtes dont le projet a besoin : le fournisseur de modèle, votre forge, vos registres de paquets. Toute autre connexion est refusée au niveau du Mac, et chaque refus est une ligne dans la Security Timeline. Vous obtenez une liste écrite des entreprises qui reçoivent des données de cette machine, et c'est vous qui l'avez écrite.

Les équipes gardent la supervision sans collecter les transcriptions

Les organisations ont toujours besoin de voir ce que font leurs agents. Un Mac inscrit dans un espace de travail bromure.io transmet les métadonnées de session aux administrateurs : outils utilisés, fichiers touchés, commandes lancées, consommation de tokens. Les prompts bruts ne sont jamais émis. La conversation complète reste dans la trace chiffrée sur le Mac du développeur. Un point rouge dans l'en-tête de la fenêtre indique qu'une machine transmet, et le Private mode garde en local l'activité d'un espace de travail, par exemple un espace qui utilise une clé d'API personnelle.

La semaine d'après

Les utilisateurs touchés de Warp doivent maintenant déterminer ce que contenaient leurs traces et renouveler tout ce qui a pu s'y trouver. Sur un Mac avec Bromure, la première partie prend quelques minutes. Ouvrez le Trace Inspector, filtrez par espace de travail et activez Conversations only pour voir chaque commande lancée par l'agent et chaque fichier qu'il a lu. Leaks only liste toute requête qui transportait un vrai jeton que Bromure n'a pas émis, ce qui montre si un secret brut est un jour passé à côté des substituts.

Le renouvellement se fait à un seul endroit. Les vraies clés vivent dans un seul coffre chiffré sur l'hôte. Collez la nouvelle valeur dans le panneau Credentials de la machine et le prochain lancement écrit le substitut correspondant. Une clé stockée sous forme de référence 1Password est résolue à nouveau toutes les deux minutes : un renouvellement dans 1Password atteint les machines en cours d'exécution sans redémarrage.

Garder le journal là où le travail a eu lieu

Les traces d'agent valent la peine d'être conservées. C'est grâce à elles qu'on découvre ce qu'un agent a fait à 3 heures du matin et qu'on répond à un auditeur. La question est de savoir qui les détient. Chaque entreprise qui stocke le journal de décisions de votre agent est une entreprise de plus dont les fournisseurs peuvent le perdre, et les attaquants font désormais tourner leurs propres agents pour trouver le fournisseur fragile.

Bromure Agentic Coding conserve le journal complet sur la machine où l'agent a travaillé, chiffré sous votre trousseau, et le remplit de substituts à la place des secrets. Quand le prochain éditeur annoncera une fuite, vous répondrez à « étions-nous concernés ? » depuis votre propre Trace Inspector.

Pour voir comment les agents dispersent des secrets dans leurs propres transcriptions, lisez Le jeton est resté dans la transcription. Pour la fuite d'OpenCode Console plus tôt ce mois-ci, lisez Les clés étaient dans leur console.