Sophos a extrait une semaine de télémétrie de postes de travail et a trouvé des agents de codage déclenchant les règles conçues pour repérer les intrus. Cinquante-six pour cent de l'activité bloquée relevait de l'accès aux identifiants — des agents déchiffrant les mots de passe enregistrés du navigateur, vidant le coffre d'identifiants Windows, arrêtant des processus de navigateur pour lire leurs magasins. Rien chez ces agents n'est malveillant. Ils atteignent ces magasins parce qu'ils tournent sur votre machine, en tant que vous, avec tout ce que vous pouvez toucher.

Un développeur ouvre Claude Code, lui demande de vérifier quelque chose, et part chercher un café. À son retour, l'agent du poste signale la session : un processus vient d'utiliser une API système de Windows pour déchiffrer le blob d'identifiants enregistré du navigateur. C'est un geste d'infostealer par manuel. C'est aussi, cette fois, l'agent de codage faisant exactement ce qu'on lui a demandé — lire une page qui se trouvait derrière une connexion, de la manière pratique, en déverrouillant le mot de passe que le navigateur avait déjà enregistré.

Sophos X-Ops a passé une semaine de juin 2026 à compter ces collisions. Ils ont pris les déclenchements de règles, bloquants et silencieux, de leur moteur comportemental sur des postes Windows, les ont comptés par machine unique et triés par tactique MITRE ATT&CK. Le tableau est sans détour. Parmi les règles bloquantes, l'accès aux identifiants représentait 56,2 % de ce qui s'est déclenché et l'exécution 28,8 %. La plus grosse règle d'identifiants — 42,6 % de ce groupe — se déclenche sur un processus utilisant l'API de protection des données de Windows, ou DPAPI, le service de l'OS qui déverrouille les secrets qu'un programme a stockés plus tôt. C'est l'appel que fait un infostealer pour retransformer le fichier de mots de passe chiffré du navigateur en clair. C'est désormais aussi l'appel que fait un agent de codage quand une compétence veut une page connectée.

Comportement d'attaquant, intention bénigne, même télémétrie

Chaque étape de la chaîne captée par Sophos est un outil qu'un développeur reconnaîtrait. Un « pack de compétences » — un ensemble de capacités toutes prêtes que vous installez dans un agent — appelé GStack livre une compétence /browse. Quand l'agent l'utilise, l'arbre de processus exécute bash → browse.exe → node → PowerShell, et le PowerShell charge System.Security et appelle l'Unprotect de DPAPI sur les données enregistrées du navigateur. Sophos a capté cette chaîne tournant sous Claude Code. Ailleurs dans la semaine : cmdkey /list pour énumérer le Gestionnaire d'identifiants Windows, taskkill contre des processus de navigateur par PID pour libérer la lecture de leurs fichiers d'identifiants, certutil et bitsadmin — deux utilitaires Windows signés — récupérant un installateur Python, et PowerShell écrivant un script dans le dossier Démarrage pour qu'il s'exécute à la prochaine connexion.

Lisez cette liste sans les mots « agent de codage » et c'est une intrusion. Vol d'identifiants, binaires living-off-the-land — les outils signés de l'OS que les attaquants empruntent pour que rien d'inhabituel n'apparaisse — et un point d'ancrage de persistance. Le moteur comportemental avait raison de se déclencher sur tout cela. Sophos est prudent quant à la conclusion : il s'agit d'« un premier passage, un bref dump de signaux », pas d'un recensement, et les détections ne signifient pas que les agents sont malveillants. Ce qu'elles signifient est plus étroit et plus durable. Certaines de ces actions sont risquées quiconque les déclenche, et, selon leurs mots, « le fait qu'un agent IA les ait faites ne les rend pas sûres ».

Une semaine de télémétrie de postes Windows, par tactique MITRE parmi les règles bloquantes. L'accès aux identifiants domine : des agents déchiffrant les mots de passe enregistrés du navigateur via DPAPI, vidant le coffre d'identifiants Windows avec cmdkey, et tuant des processus de navigateur pour lire leurs magasins. Les règles ont été conçues pour repérer les intrus ; elles se sont déclenchées sur des agents de codage faisant un travail légitime avec la même portée qu'aurait un intrus.

La portée, pas l'intention, est le problème

La raison pour laquelle la même règle attrape un voleur et un assistant, c'est que, sur une installation normale, ils se tiennent au même endroit. L'agent tourne sous votre compte utilisateur, sur votre machine. Ce compte peut ouvrir les mots de passe enregistrés du navigateur parce que vous les avez enregistrés. Il peut lire le Gestionnaire d'identifiants Windows parce que ce coffre est le vôtre. Il peut écrire dans le dossier Démarrage et appeler certutil parce que tout programme que vous lancez le peut. L'agent hérite de toute votre autorité ambiante — chaque secret, chaque outil signé, chaque recoin inscriptible du disque — dès qu'il démarre. Une injection de prompt, une compétence empoisonnée ou une tâche légitime trop zélée a alors tout cela à sa disposition.

C'est pourquoi Sophos présente la partie difficile comme une question de politique, pas de détection : « Que devrait-on permettre à un agent de faire sur un poste ? Quelles limites devrait-on imposer ? » Leur conseil de réglage sépare les règles en deux. Certaines devraient apprendre les signatures connues-bonnes de l'agent pour cesser de crier au loup. D'autres « devraient continuer à se déclencher, car l'activité qu'elles attrapent est risquée qu'un humain ou un agent l'ait initiée » — le déchiffrement DPAPI et les vidages de coffre d'identifiants parmi elles. Et cela laisse le défenseur dans une vraie impasse. Supprimez la règle d'identifiants pour faire taire l'agent, et vous devenez aveugle à l'infostealer qui fait l'appel identique. Laissez-la se déclencher, et votre file se remplit d'un outil que vos propres développeurs ont installé. Aucun choix n'est bon, car tous deux supposent que l'agent doit vivre sur le poste, à côté des secrets.

Déplacez l'agent, et le coffre n'est plus là à ouvrir

L'impasse ne tient que tant que l'agent vit à côté des secrets. Bromure Agentic Coding fait tourner chaque agent de codage à l'intérieur d'une VM Linux jetable, à un hyperviseur de votre Mac. Le monde de l'agent, c'est cette VM. Votre trousseau macOS n'y est pas. Le profil de navigateur où vous avez enregistré vos mots de passe n'y est pas. Il n'y a pas de Gestionnaire d'identifiants Windows, pas de dossier Démarrage de l'hôte, pas de processus de navigateur de l'hôte à tuer et à fouiller. Quand une compétence cherche le magasin de mots de passe enregistrés comme le fait le /browse de GStack, la recherche atterrit dans une VM neuve qui n'a jamais contenu ces mots de passe. L'appel peut s'exécuter ; il ne trouve rien qui vaille d'être pris.

Restent les identifiants dont l'agent a besoin pour faire le travail — la clé d'API du modèle, un jeton GitHub pour pousser une branche, un secret AWS pour déployer. Les remettre à la VM ne ferait que recréer le coffre dont vous vous êtes éloigné. Bromure ne les remet pas. Un proxy homme-du-milieu sur l'hôte se place sur le fil entre la VM et le monde extérieur. À l'intérieur de la VM, l'agent ne détient que des leurres — une chaîne brm_… fictive là où devrait être la vraie clé. Quand l'agent fait une requête vers api.anthropic.com ou github.com, le proxy échange le leurre contre la vraie valeur à la sortie et la réinverse à l'entrée. Le vrai secret est présent pour le seul saut qui en a besoin et n'entre jamais dans la mémoire de la VM. Un agent qui déchiffre tout ce qu'il peut trouver dans son propre environnement en repart avec des leurres.

À gauche : l'agent tourne sur l'hôte en tant que vous, dans votre autorité ambiante — le magasin de mots de passe du navigateur, le coffre d'identifiants de l'OS, le dossier Démarrage, les outils de téléchargement signés. Une recherche légitime et celle d'un infostealer sont le même appel, alors la règle du poste se déclenche dans les deux cas. À droite : Bromure fait tourner l'agent dans une VM jetable. Les magasins de l'hôte ne sont pas présents, et les identifiants que l'agent utilise sont des leurres que le proxy de l'hôte échange contre les vrais seulement sur le fil. L'appel en forme d'attaque s'exécute quand même ; il atterrit quelque part sans rien à prendre.

Deux règles qui gardent l'humain dans la boucle

L'isolation met les secrets hors de portée ; deux autres contrôles décident quand un vrai secret est autorisé à quitter l'hôte. Chaque échange d'identifiant peut être configuré pour exiger une approbation — la substitution leurre-vers-vrai s'interrompt et une boîte de dialogue sur votre Mac demande avant que la vraie valeur ne sorte. Pour une clé SSH ou une requête AWS, vous l'accordez pour cinq minutes, une heure ou le reste de la session, puis cela se reverrouille. Et pour les bases de données câblées via le proxy — MongoDB, ClickHouse, Elasticsearch — un garde-fou lit l'opération réelle sur le fil et peut bloquer les destructrices, si bien qu'un DELETE que l'agent s'est convaincu de faire n'atteint jamais le vrai point d'accès, même après l'échange de l'identifiant.

Rien de tout cela ne demande à l'agent de bien se comporter. Cela suppose que l'agent pourrait faire la chose en forme d'attaque — déchiffrer un magasin, vider un coffre, réessayer un téléchargement bloqué — parce que Sophos vient de voir de vrais agents faire exactement cela. La conception décide que, quand cela arrive, le magasin est vide, la clé est fausse et la requête destructrice s'arrête à la porte.

Les agents se comportent désormais comme la chose que vos défenses étaient réglées pour arrêter, et vous ne pouvez pas corriger cela en leur demandant de bien se comporter. Vous le corrigez en changeant l'endroit où ils se tiennent. Donnez à un agent une machine jetable sans mots de passe enregistrés, un coffre plein de leurres et un proxy qui garde les vrais secrets sur l'hôte — et la télémétrie qui a illuminé le dump de Sophos devient un processus fouillant une pièce vide. Installez-le, pointez-le vers un dépôt, et laissez-le chercher tout ce qu'il veut.