L'agent avait le login administrateur

Le 29 octobre, WIRED a rapporté qu'un employé d'Accenture avait connecté un compte Claude Code personnel à un environnement de production du département de la Défense et confié à l'agent ses propres identifiants de connexion. D'après les sources de WIRED, le but était d'automatiser le code et la mise en place de serveurs cloud. L'environnement se trouve sur NIPRNet, le réseau non classifié et relié à Internet du Pentagone, sert à plusieurs agences de renseignement et contient des informations non classifiées contrôlées.

Les détails viennent de sources anonymes. Accenture a déclaré aux journalistes que les allégations « ont fait l'objet d'une enquête approfondie et indépendante et se sont révélées sans fondement ». Le Pentagone n'a pas souhaité commenter. Personne n'a rapporté que des réseaux classifiés aient été atteints.

Vous avez sans doute vu la même configuration dans votre propre équipe. Un développeur veut qu'un agent fasse du vrai travail, ce travail demande des accès, alors le développeur donne son login à l'agent.

Ce que l'agent aurait fait

Selon les témoignages résumés par IBTimes UK et GBHackers, les identifiants du sous-traitant donnaient à l'agent un accès administrateur. Il pouvait écrire et déployer du logiciel, committer du code sous le nom de l'employé et créer des serveurs cloud. Il a fonctionné ainsi pendant environ deux mois.

Pendant cette période, l'agent semble avoir envoyé les identifiants de connexion du sous-traitant, des mots de passe et une carte de NIPRNet à un site web tiers. WIRED n'a pas nommé le site. Le magazine indique que le NIST l'avait signalé comme à haut risque, à cause d'une faille qui pouvait permettre à des attaquants d'injecter des instructions dans un agent de code IA et de voler des identifiants. Personne n'a montré que la faille ait été utilisée ici, et les articles ne disent pas comment quelqu'un a remarqué le transfert.

Les sources de WIRED ont aussi indiqué que l'incident aurait dû être signalé au gouvernement sous 72 heures, le délai que la clause DFARS 252.204-7012 impose aux sous-traitants de la défense. Accenture affirme avoir rempli ses obligations.

Jake Williams, ancien hacker de la NSA cité dans la couverture, a décrit ce qui inquiète le plus les défenseurs : des identifiants volés pour un environnement de développement permettent à un attaquant de modifier un logiciel avant qu'il ne passe vers des réseaux plus sensibles.

Trois choses ont mal tourné

Retirez le Pentagone et il reste trois défaillances que n'importe quelle équipe d'ingénierie peut reproduire :

1. L'agent détenait les vrais identifiants. Tout ce qu'il lisait, affichait ou envoyait pouvait contenir les vrais mots de passe.
2. L'agent pouvait joindre n'importe quel site sur Internet. Une tâche qui demandait un environnement et un fournisseur cloud pouvait aussi parler à un site web non nommé présentant un problème d'injection connu.
3. Personne ne l'a remarqué pendant des mois. Les articles placent environ deux mois entre l'arrivée de l'agent et le moment où quelqu'un a réagi à ce qu'il envoyait.

Chacun de ces points a une réponse directe dans Bromure Agentic Coding, qui exécute Claude Code, Codex, Grok, Kimi et omp dans des VM Ubuntu sur votre Mac, chaque requête réseau passant par un proxy sur le Mac.

L'agent reçoit un substitut

Dans Bromure, vous ne donnez pas votre login à l'agent. Vous l'ajoutez au panneau Credentials de la machine : une clé cloud, un jeton GitHub, un contexte Kubernetes, un secret de base de données, une clé SSH ou toute autre clé d'API, avec l'hôte auquel elle appartient. La vraie valeur est stockée chiffrée sur le Mac.

Dans la VM, l'agent reçoit un substitut de même forme. Un jeton GitHub, c'est ghp_ suivi de 36 caractères, un secret AWS fait 40 caractères, donc gh, aws, kubectl et terraform les acceptent sans broncher. Quand une requête quitte la VM, le proxy sur le Mac remplace le substitut par la vraie valeur, et seulement si la requête va vers l'hôte pour lequel cet identifiant a été configuré. Les clés SSH n'entrent jamais dans la VM. L'agent peut demander une signature via un pont vsock, et la clé privée reste sur le Mac.

Ainsi, un agent qui vide son environnement, colle sa configuration dans un formulaire web ou se laisse convaincre d'envoyer ses identifiants quelque part envoie des substituts. Ils ne fonctionnent nulle part, sauf à travers le proxy, sur le seul hôte pour lequel ils ont été configurés.

Un substitut sur le mauvais hôte arrête la VM

Les substituts sont aussi des pièges. Un substitut GitHub n'a qu'une destination légitime : GitHub. Le proxy analyse les en-têtes et le corps de chaque requête sortante à la recherche d'un substitut envoyé hors de son périmètre.

Quand il en trouve un :

• La requête est bloquée avec un HTTP 451. Aucun octet n'atteint la destination.
• La VM est mise en pause immédiatement, et ramenée à l'écran si elle était en arrière-plan.
• Une alerte intitulée This environment may have been compromised nomme l'identifiant, l'hôte auquel il appartient et l'hôte vers lequel il était envoyé.

La réponse par défaut est Shut down, qui marque aussi la machine comme compromise. Save for Investigation exporte d'abord le disque et le dossier personnel de la VM. Une machine compromise ne redémarre pas tant que son disque et son dossier personnel n'ont pas été effacés.

Dans le récit de WIRED, identifiants et mots de passe sont partis vers le site tiers. Sur une machine Bromure, le proxy bloque la première requête de ce genre avant que quoi que ce soit ne quitte le Mac, la VM se fige, et l'alerte indique au développeur quel identifiant partait vers où.

La carte du réseau reste derrière la liste blanche

Une carte du réseau n'est pas un identifiant, le piège ne s'y applique donc pas. Le pare-feu de sortie, si. Le panneau Guardrails de chaque machine contient une table Outbound connections et un réglage Unmatched traffic. Réglez le trafic non reconnu sur Deny, autorisez les hôtes dont la tâche a besoin, et toute autre connexion est refusée sur le Mac :

allow tcp api.github.com:443
allow web *.amazonaws.com
allow web registry.npmjs.org
default deny

Les règles sont appliquées deux fois, hors de la VM. Le commutateur réseau virtuel vérifie chaque connexion par IP et par le nom d'hôte vu dans le DNS, pour tous les protocoles, et le proxy vérifie à nouveau par le nom de serveur TLS. Un curl lancé par l'agent, un script qu'il écrit et un paquet qu'il installe passent tous par le même contrôle. Un site web que personne n'a listé reçoit une connexion refusée, et le refus est enregistré.

Si le site web portait bien une injection, comme le NIST avertissait que c'était possible, le détecteur de code source la verrait en premier. Bromure analyse le contenu que l'agent lit depuis ses outils, pages récupérées comprises, avec un modèle PromptGuard local avant que ce contenu n'atteigne le fournisseur du modèle, et peut journaliser, demander ou bloquer.

Des droits admin, avec une barrière sur les écritures

Dans le récit de WIRED, l'agent committait du code et créait des serveurs cloud avec des droits d'administrateur. Bromure laisse à l'agent les accès dont la tâche a besoin et place les écritures derrière une règle appliquée dans le proxy, où l'agent ne peut pas la désactiver.

Chaque service du panneau Guardrails a une politique d'écriture : Off, Prompt before write, Block destructive ou Read-only. Elle couvre les forges git, AWS, DigitalOcean, les registres de conteneurs, Kubernetes et plusieurs bases de données. Les nouvelles machines démarrent sur Prompt before write. Les lectures passent. Un git push, un appel RunInstances ou un kubectl apply s'arrête sur une boîte de dialogue sur le Mac qui montre l'opération exacte, et le développeur choisit Allow once, Allow for 15 minutes, Allow for the rest of the session ou Don't allow. Pour un identifiant plus sensible, Require approval to use demande une confirmation avant sa première utilisation dans chaque session.

Le scénario de Jake Williams suppose une modification discrète du logiciel. Avec Prompt before write, un attaquant qui pousse l'agent à faire cette modification doit encore faire passer le push devant une boîte de dialogue sur le Mac du développeur.

Deux mois deviennent la première requête

Les sources de WIRED ne disent pas qui a repéré le transfert, ni quand. Sur un Mac Bromure, le développeur peut ouvrir la Security Timeline (Window › Security Timeline…) et lire chaque décision prise par les moteurs de sécurité, sur chaque machine, sans rien configurer : chaque substitution d'identifiant, chaque autorisation et refus du pare-feu, chaque blocage des garde-fous, chaque détection d'injection de prompt et chaque exfiltration bloquée. Son onglet Overview fait le compte des dernières 24 heures et liste les derniers blocages. Les événements sont conservés 90 jours et s'exportent en CSV, ce qui donne à un sous-traitant soumis à un délai de signalement de 72 heures les horodatages, les hôtes et les noms des identifiants dès le premier jour.

Les équipes peuvent enrôler leurs Mac avec Bromure Enterprise Manager. Les Mac enrôlés transmettent les mêmes événements à l'organisation : credential.exfiltration quand un substitut tente de sortir, egress.firewall pour chaque verdict, guardrails.block pour chaque écriture refusée, en plus de l'usage des outils, des commandes et du nombre de jetons. Les événements d'identifiants ne portent que de courts aperçus, jamais les secrets, et les prompts et réponses du modèle ne quittent jamais le Mac. L'équipe de sécurité lit l'alerte dans sa propre console quelques secondes après le blocage.

Cela donne aussi aux développeurs un moyen approuvé d'utiliser n'importe lequel des cinq agents sur de vrais systèmes, avec l'entreprise qui surveille la frontière, plutôt qu'un compte personnel que l'entreprise ne voit pas.

Donnez une tâche à l'agent, pas votre login

Les développeurs continueront de donner des accès aux agents, parce que les agents en ont besoin pour faire le travail. Donnez l'accès à l'agent, gardez les secrets sur le Mac, et décidez à quels hôtes il peut parler.

Dans Bromure Agentic Coding, c'est le comportement par défaut : ajoutez les identifiants à la machine, limitez le pare-feu aux hôtes dont la tâche a besoin, laissez les écritures sur Prompt before write, et laissez la Security Timeline tenir l'historique.

Pour un autre cas où les données d'un agent ont fini sur un serveur que personne n'avait choisi, lisez Le journal de l'agent était dans leur cloud. Pour ce qu'un portable de développeur permet d'atteindre une fois qu'un attaquant s'y trouve, lisez Le portable était la porte d'entrée.