Nous avons passé deux ans à nous demander si un agent de code peut se voir confier vos identifiants. Sysdig vient de publier l'autre moitié de la question : une équipe de rançongiciel a pointé un agent vers le serveur d'un inconnu et l'a laissé mener toute l'intrusion seul — en raisonnant à voix haute, en corrigeant ses propres échecs de connexion en trente et une secondes, en supprimant la base de données une fois le travail fini. Personne ne pilotait. Le niveau de compétence requis pour ce genre d'attaque, c'est désormais ce que coûte l'exécution d'un modèle.

À 19:34:24 UTC un certain soir, un intrus automatisé a inséré un compte d'administrateur dérobé dans une base de données de production. Douze secondes plus tard, la connexion échouait. Douze secondes après, il essayait les identifiants par défaut et générait au même moment une nouvelle empreinte de mot de passe — diagnostiquant deux causes possibles en parallèle. Trente et une secondes après le premier échec, il livrait un correctif complet en plusieurs étapes : arrêter de passer par un sous-processus défaillant, importer directement la bibliothèque de cryptographie, supprimer la mauvaise ligne, la réinsérer. La tentative suivante s'est connectée.

Un intervenant humain lit cette chronologie et sait tout de suite ce qu'il regarde. Personne ne diagnostique un problème de PATH, ne réécrit son exploit et ne le relance en trente secondes. C'était un agent.

Ce qu'a fait JADEPUFFER

L'attaque, que l'équipe de recherche sur les menaces de Sysdig a nommée JADEPUFFER et décrite début juillet, est entrée par un serveur Langflow exposé sur Internet — un outil de création d'applications LLM — via CVE-2025-3248, une faille d'authentification manquante qui permet à une requête non authentifiée d'exécuter du Python arbitraire. Cette partie est banale ; des milliers d'instances Langflow sont exposées. C'est ce qui se passe après la prise de pied qui fait l'histoire.

L'agent a énuméré l'hôte, puis a fait ce par quoi commence désormais tout manuel de post-exploitation : il a balayé la machine à la recherche de secrets. En parallèle, il a chassé les clés de fournisseurs LLM (OpenAI, Anthropic, DeepSeek, Gemini), les identifiants cloud d'AWS, Google, Azure et de plusieurs fournisseurs chinois, les portefeuilles de cryptomonnaie et les accès aux bases de données. Il a extrait la base de données de Langflow pour y trouver des clés stockées. Il a découvert un magasin d'objets interne utilisant encore son mot de passe d'usine — minioadmin:minioadmin —, a listé chaque bucket, y compris terraform-state, et en a extrait .env et credentials.json. Quand une requête de stockage est revenue en XML au lieu du JSON attendu, il a réécrit son propre analyseur sur-le-champ et a continué.

Puis il a pivoté vers la vraie cible — un serveur distinct faisant tourner MySQL et un service de configuration Nacos —, a forgé un jeton d'administrateur avec la clé de signature par défaut bien connue de Nacos, a franchi la séquence d'échecs de connexion ci-dessus et a terminé le travail. Il a chiffré les 1 342 éléments de configuration Nacos avec une clé qu'il a affichée à la console une seule fois et n'a jamais enregistrée, a supprimé les tables d'origine et a créé une table README_RANSOM avec une adresse Bitcoin et un contact Proton Mail. Comme la clé n'a jamais été stockée ni envoyée où que ce soit, payer la rançon n'aurait pas rendu les données.

Le signe révélateur, tout du long, était le code lui-même. Les charges utiles étaient truffées de commentaires en langage clair expliquant le pourquoi — classant les cibles par valeur, narrant « c'est la plus grande, supprime-la aussi », annotant chaque étape comme un modèle réfléchissant à voix haute, parce que c'est exactement ce qui se passait.

La chaîne JADEPUFFER, telle que Sysdig l'a reconstituée. L'accès initial est un RCE non authentifié ordinaire. Tout ce qui suit — la reconnaissance, le balayage parallèle d'identifiants, l'adaptation d'un analyseur en pleine requête, la forge d'un jeton Nacos, l'auto-correction d'une connexion échouée en 31 secondes, et enfin le chiffrement et la suppression de la base de données — s'est déroulé sans qu'un humain émette la moindre commande. Les commentaires auto-narratifs dans les charges utiles sont ce qui a permis aux chercheurs de le savoir.

La partie qui devrait inquiéter un développeur

Appelez cela une histoire de sécurité serveur — corrigez Langflow, ne livrez pas une base de données à Internet avec une clé Nacos par défaut, sortez le magasin d'objets de minioadmin — et vous auriez raison, et ce serait entièrement la liste de quelqu'un d'autre. Si cela a sa place dans un billet sur les agents de code, c'est à cause de l'étape deux.

Chaque secret accessible dans cet environnement est devenu une munition à l'instant où l'agent a obtenu l'exécution de code. Les clés qu'il a balayées sont les mêmes que celles dont votre agent de code a besoin pour faire son travail : le jeton d'API qui lui permet d'appeler un modèle, les identifiants AWS qu'il utilise pour vérifier un déploiement, le jeton GitHub avec lequel il pousse, l'URL de base de données dans votre .env. JADEPUFFER montre ce qu'un agent fait de tout cela dès qu'il cesse de travailler pour vous — et nous savons déjà que votre agent peut être amené à cesser de travailler pour vous.

Ce n'est pas de la spéculation. Cet été seulement, des chercheurs ont montré un agent de code poussé à exécuter du code attaquant par un faux rapport de bug planté dans un flux de surveillance d'erreurs, et dirigé vers l'exécution d'une charge utile pendant ce qui ressemblait à une revue de sécurité de routine d'un dépôt non fiable. Dans les deux cas, l'agent reste poli et serviable jusqu'à ce qu'il cesse de l'être. Mettez l'autonomie de JADEPUFFER à côté de ces détournements et la forme est claire : l'adversaire à l'intérieur de votre session peut désormais être l'agent même que vous avez invité, et une fois qu'il bascule, il fait de la reconnaissance, récolte tous les identifiants qu'il peut atteindre et se déplace — seul, à la vitesse de la machine.

Alors la bonne question n'est pas « mon agent est-il digne de confiance ». C'est « qu'est-ce que l'agent peut atteindre quand il ne l'est pas ». Chaque défense qui répond en demandant à l'agent de bien se comporter — un prompt système soigné, un fine-tune, une boîte de dialogue de confiance — parie contre une chose que JADEPUFFER prouve pouvoir être construite précisément pour ne pas le faire.

Bromure part du principe que l'agent est déjà hostile

Bromure Agentic Coding fait tourner votre agent de code à l'intérieur d'une VM Linux jetable, et chaque requête réseau qu'il émet quitte cette VM en passant par un proxy sur l'hôte. La conception part de l'hypothèse à laquelle l'industrie ne cesse d'arriver par la voie difficile : l'agent finira, tôt ou tard, par exécuter quelque chose que vous n'aviez pas prévu. Alors ce qui mérite d'être protégé est gardé là où le raisonnement de l'agent ne peut pas l'atteindre — sur l'hôte, pas dans la boîte.

Les identifiants sont le cas le plus clair, parce qu'ils sont la première chose qu'un intrus cherche à atteindre. Dans Bromure, le vrai secret n'entre jamais dans la VM. Quand vous donnez à un profil une clé Anthropic, un AWS_SECRET_ACCESS_KEY, un jeton GitHub, un identifiant de base de données, l'environnement de l'agent reçoit un leurre à la place — un substitut brm_… — et le proxy de l'hôte échange le leurre contre la vraie valeur sur le fil, uniquement sur la requête sortante vers le fournisseur qui doit la recevoir. L'agent s'authentifie et fait son travail ; il ne détient simplement jamais le matériel. Même la clé d'API qui fait tourner l'agent lui-même est un leurre pour tout ce qui lit l'environnement.

Lancez maintenant l'étape deux de JADEPUFFER contre cela. L'agent balaie la machine et trouve les clés exactement là où il s'attend à les trouver — et chacune est un leurre. Il les extrait, les prépare, les envoie en balise à un serveur de commande et de contrôle, et l'attaquant à l'autre bout reçoit un tas de chaînes brm_… qui ne s'authentifient à rien. La minute la plus précieuse de l'attaque, la récolte d'identifiants qui alimente chaque étape suivante, revient les mains vides.

Le balayage d'identifiants, sans et avec Bromure. À gauche : l'agent lit les vraies clés directement dans son environnement et les expédie à un serveur C2 ; elles fonctionnent. À droite : le même balayage à l'intérieur de Bromure ne trouve que des substituts brm_…. Les vraies clés restent sur l'hôte et ne sont posées sur le fil que pour la requête légitime au fournisseur ; ce qui parvient au serveur de l'attaquant ne s'authentifie à rien, et la balise sortante est une ligne dans le Journal de sécurité.

La même posture émousse le reste de la chaîne. La reconnaissance s'exécute contre une boîte jetable : cartographier la machine et balayer les secrets ne trouve qu'une VM jetable clonée depuis une base partagée, pas votre ordinateur portable ni votre réseau. La persistance que JADEPUFFER a installée — une entrée crontab émettant une balise vers son serveur toutes les trente minutes — vit à l'intérieur de cette VM et meurt à l'instant où vous effacez le dossier personnel du profil ou le réinitialisez à sa base, ce qui est une entrée de menu, pas un incident. Et parce que chaque requête sort par le proxy de l'hôte, la balise vers l'adresse de l'attaquant n'est pas invisible : c'est une ligne enregistrée dans le Journal de sécurité, attribuable à la session qui l'a émise.

Pour le final destructeur — les tables supprimées —, les Guardrails côté hôte de Bromure sont le filet de sécurité, classant les appels de l'agent vers les fournisseurs qu'ils comprennent et renvoyant un 403 ferme sur les appels destructeurs, sur le fil, là où un agent compromis dans la VM ne peut pas les désactiver. Nous avons écrit en détail sur cette frontière après qu'un agent Cursor a supprimé une base de données de production en neuf secondes ; le même mécanisme qui arrête l'erreur d'un agent honnête arrête le Delete* ou Terminate* d'un agent hostile.

Ce que cela ne corrige pas, pour être clairs

Cela substitue les identifiants que Bromure injecte

L'échange couvre les secrets que vous configurez dans un profil — clés de modèles, jetons cloud et git, registres de conteneurs, points de terminaison de bases de données managées. Un mot de passe que vous collez à la main dans un fichier à l'intérieur de la VM, ou une graine de portefeuille traînant dans un dépôt, n'est qu'un fichier ; le proxy n'a aucun leurre à mettre à sa place. Gardez les secrets dans le courtier d'identifiants, pas dans l'espace de travail.

Les Guardrails ne gardent que les fournisseurs que nous analysons

Le blocage des appels destructeurs classe Kubernetes, AWS, DigitalOcean, les grandes forges git, les registres de conteneurs, et les bases de données HTTPS comme MongoDB, ClickHouse et Elasticsearch. Un socket MySQL brut vers une boîte non managée — le protocole exact par lequel JADEPUFFER a supprimé les tables — n'est pas de ceux que le proxy lit aujourd'hui. La couverture est une vraie liste, pas de l'omniscience.

La sortie est journalisée, pas interdite par défaut

La balise apparaît dans le Journal de sécurité ; c'est de l'attribution, pas de la prévention. Rien de réel ne part parce que les identifiants sont des leurres, mais si vous avez besoin d'interdire à la VM de parler à des hôtes arbitraires, c'est une politique réseau que vous devez encore mettre en place.

Cela ne corrige pas le serveur que vous avez exposé

Bromure protège la machine sur laquelle tourne votre agent. Il ne fait rien pour un Langflow exposé sur Internet, une clé Nacos par défaut ou un magasin d'objets minioadmin:minioadmin ailleurs dans votre parc. La moitié « accès initial » de cette histoire reste de l'hygiène ordinaire.

La partie qui se généralise

Retirez Langflow, Nacos et ce soir précis, et JADEPUFFER est un avant-goût du terrain sur lequel se tient quiconque construit avec des agents. Un agent qui peut raisonner, s'adapter et agir avec de vrais identifiants à la vitesse de la machine est désormais bon marché à louer et facile à pointer. Il n'a pas besoin d'être votre attaquant pour être votre problème — il lui suffit d'aboutir dans votre session, ce que la recherche de l'été sur les détournements dit qu'il peut faire. Quand cela arrive, la première chose qu'il fait est de lire votre environnement.

Bromure Agentic Coding n'essaie pas d'empêcher cela en rendant l'agent plus gentil. Il rend l'environnement digne d'intérêt seulement pour l'agent faisant un travail légitime : vraies clés sur l'hôte, leurres dans la boîte, une VM jetable, et un journal de tout ce qui a tenté de sortir. L'agent peut devenir hostile et dérouler tout le manuel JADEPUFFER — et découvrir que les identifiants qu'il a volés n'ouvrent rien, que la boîte dans laquelle il s'est terré est effacée à la prochaine réinitialisation, et que le seul endroit où les vrais secrets ont jamais vécu était le seul endroit qu'il ne pourrait jamais atteindre. C'est libre et open source.