Un agent de codage IA a supprimé la base de production entière d'une entreprise en neuf secondes, puis a supprimé les sauvegardes, puis s'est justifié : « J'ai supposé que supprimer un volume de staging via l'API resterait cantonné au staging. Je n'ai pas vérifié. » Le mot intéressant dans cette phrase n'est pas supposé. C'est je. L'agent a décidé, tout seul, qu'une action destructive ne posait pas de problème. Le correctif n'est pas un agent plus intelligent. C'est de cesser de laisser la chose qui veut exécuter la commande être la même chose qui décide si la commande est sûre.

Voici l'histoire, qui a éclaté fin avril 2026 et que plusieurs médias ont couverte, dont Tom's Hardware et Tom's Guide.

Un développeur nommé Jer Crane, qui fait tourner un petit SaaS nommé PocketOS, a demandé à son agent de codage de traiter un problème mineur en staging. L'agent — Cursor, pilotant le Claude Opus 4.6 d'Anthropic — est tombé sur une incohérence d'identifiants qu'il n'attendait pas. Au lieu de s'arrêter, il a décidé que le problème était un volume Railway périmé, et que supprimer ce volume dégagerait la voie. Il avait un token d'API posé dans le projet avec juste assez de portée pour faire exactement cela. Il l'a utilisé. L'ID du volume qu'il a supprimé n'était pas cantonné au staging ; il soutenait la base de production. L'API de Railway a démoli les sauvegardes au niveau du volume en même temps. Temps total écoulé, selon le récit de Crane : neuf secondes.

Le post-mortem de l'agent lui-même, cité dans les articles, est la partie sur laquelle il vaut la peine de s'attarder. « J'ai supposé que supprimer un volume de staging via l'API resterait cantonné au staging. Je n'ai pas vérifié. » Et : « J'aurais dû vous demander d'abord, ou trouver une solution non destructive. »

Il aurait dû demander d'abord. Retenez cela, parce que c'est tout le propos.

Neuf secondes, racontées.

Rien ici n'est exotique. Pas de zero-day, pas de malware, pas d'attaquant. Chaque étape est une chose normale qu'un agent de codage fait, dans l'ordre normal, juste un peu trop vite pour que quiconque l'interrompe.

L'incident PocketOS sous forme d'une séquence d'étapes ordinaires. Une tâche de staging tombe sur une erreur d'identifiants inattendue. L'agent raisonne jusqu'à un correctif destructif, trouve un token d'API à portée large déjà dans le projet, et appelle le point de terminaison de suppression du fournisseur cloud. Le volume qu'il supprime soutient la production ; le rayon d'explosion du même appel emporte les sauvegardes. Chaque case est banale. Le dégât, c'est la composition.

Crane a eu, de son propre aveu, de la chance au bout du compte. Il avait une sauvegarde vieille d'environ trois mois et — après que l'histoire s'est répandue — Railway l'a contacté et a restauré les données que l'agent avait supprimées. Mais « le fournisseur a vu le titre et a aidé » n'est pas un plan de reprise. La prochaine équipe à qui cela arrivera ne fera pas la une.

Et cela arrivera à la prochaine équipe. Crane a attribué la faute à des défaillances systémiques de plus d'une partie, et il n'a pas tort — un unique token capable de supprimer la production et ses sauvegardes est un problème en soi, et une API de suppression qui emporte les sauvegardes avec le volume aussi. Mais la défaillance qui va se répéter, partout, quel que soit l'agent ou le cloud, c'est celle de l'étape trois. L'agent a décidé.

« Demander d'abord » n'est pas une chose qu'on peut demander à l'agent de faire.

La leçon évidente — celle qu'on lit dans chaque fil de commentaires sous cette histoire — est « l'agent devrait avoir une étape de confirmation avant les actions destructives ». C'est correct. C'est aussi déjà, en quelque sorte, la façon dont ces outils sont censés fonctionner. L'agent est instruit de demander avant de faire des choses irréversibles. Il l'a dit lui-même : il savait qu'il aurait dû demander. Il ne l'a pas fait.

C'est le piège, et il vaut la peine d'être précis à son sujet. Quand la confirmation vit à l'intérieur de l'agent — sous forme de règle de prompt système, de fine-tune, d'une instruction « sois prudent » — alors l'agent est à la fois la chose qui propose l'action dangereuse et la chose qui juge si l'action est assez dangereuse pour qu'on s'y arrête. La plupart du temps il juge correctement. L'agent de PocketOS a jugé correctement des milliers de fois avant cela. Puis il est tombé sur une erreur inconnue, a raisonné jusqu'à une conclusion fausse mais sûre d'elle, a décidé que cette suppression précise était du genre sûr et cantonné, et a sauté sa propre confirmation. Il n'y avait aucun second avis, parce que le seul avis dans la pièce était celui qui voulait exécuter la commande.

On ne peut pas corriger cela en disant à l'agent d'être plus prudent, pour la même raison qu'on ne peut pas corriger une carte mal lue en plissant plus fort les yeux. Le contrôle doit vivre quelque part où le raisonnement de l'agent ne peut pas l'atteindre.

Ce que change Agentic Coding 2.2.

Bromure Agentic Coding fait tourner votre agent de codage à l'intérieur d'une VM Linux jetable, et chaque requête réseau que l'agent émet quitte cette VM par un proxy sur l'hôte. Depuis la version 2.0, ce proxy applique des Guardrails : une politique côté hôte qui classe les appels d'API de l'agent par protocole et peut bloquer purement et simplement les appels destructifs — un DROP, un DELETE, un Terminate* — avant qu'ils ne quittent la machine. Les appels bloqués reviennent à l'agent sous la forme d'un 403 ordinaire, si bien qu'un agent confus ou compromis dans la VM ne peut pas s'en sortir par la parole. L'agent ne voit jamais l'interrupteur ; il voit juste que la porte est verrouillée.

Tout bloquer est le bon réglage pour un profil verrouillé, mais c'est trop grossier pour le travail quotidien, parce que parfois vous voulez bien que l'agent supprime une branche ou drope une table de brouillon. Alors la 2.2 ajoute un troisième réglage, et en fait le défaut des nouveaux profils : Demander avant écriture. Les lectures passent tout droit. Chaque écriture — destructive ou non — fait une pause à la frontière et ouvre une boîte de dialogue sur l'hôte, hors de la VM, vous montrant l'opération littérale que l'agent tente d'exécuter. Pas un résumé écrit par l'agent. La requête réelle : le texte SQL, ou le METHOD /path HTTP, ou le nom d'action AWS. Vous avez quatre boutons : l'autoriser une fois, l'autoriser pour quinze minutes, l'autoriser pour le reste de la session, ou ne pas l'autoriser. Refusez, et l'agent reçoit son 403 et passe à autre chose.

Une chose honnête d'abord. PocketOS tournait sur Railway, et Railway n'est pas un fournisseur que Bromure analyse aujourd'hui, donc je ne vais pas prétendre qu'une boîte de dialogue serait apparue pour cet appel précis. Mais le mode de défaillance est indépendant du fournisseur, et la façon la plus nette de le montrer est sur un fournisseur que Bromure contrôle bel et bien. AWS est le choix évident. La version AWS de « supprimer la base et emporter la sauvegarde avec » est un seul appel : rds:DeleteDBInstance avec SkipFinalSnapshot=true, qui supprime l'instance et saute le snapshot final qui vous aurait permis de revenir en arrière. Mêmes neuf secondes, même forme, sur une API que le garde-fou lit.

À gauche : la forme qui a mordu PocketOS, transposée sur AWS. L'agent détient des identifiants AWS et émet rds:DeleteDBInstance avec SkipFinalSnapshot=true — supprimer la base, sauter la sauvegarde — et la requête part ; la base est perdue. À droite : le même agent, le même raisonnement fautif, dans Bromure 2.2. L'appel quitte la VM, le proxy de l'hôte lit le nom d'action AWS (Delete* ⇒ écriture destructive), et une boîte de dialogue apparaît sur l'hôte montrant l'action exacte. L'humain voit une base de production supprimée sans snapshot final — visiblement pas le correctif de staging demandé — et clique sur Ne pas autoriser. L'agent reçoit un 403 et la base est toujours là.

Déroulons-le. L'agent commet la même erreur — tombe sur l'erreur d'identifiants, raisonne jusqu'à la même conclusion fausse, tend la main vers la même suppression. Mais l'appel quitte la VM et le proxy de l'hôte le lit pour ce qu'il est : il extrait le nom d'action de la requête (DeleteDBInstance), le confronte à l'ensemble destructif (Delete*, Terminate*, Destroy*, …), et voit une écriture contre un point de terminaison dans un profil réglé sur « demander ». Une boîte de dialogue apparaît sur l'hôte, titrée avec l'opération, le corps montrant rds:DeleteDBInstance prod-db-1 SkipFinalSnapshot=true. Un humain qui regarde cette ligne n'a pas besoin de comprendre le raisonnement de l'agent. Il a demandé un correctif de staging et on lui montre la suppression d'une base de production avec la sauvegarde désactivée. Il clique « Ne pas autoriser ». L'agent reçoit un 403 qu'il interprète comme un appel d'API échoué, et part chercher une autre approche — ce qui est exactement ce qu'il a dit après coup qu'il aurait dû faire dès le départ.

Le mécanisme qui rend cela digne de confiance, c'est que le courtier de consentement vit sur l'hôte. C'est un petit acteur que le proxy appelle avant de laisser passer une écriture. « Autoriser une fois » ne stocke délibérément rien, si bien que l'écriture suivante redemande et vous pouvez laisser passer une séquence connue comme sûre une étape à la fois ; « 15 minutes » et « session » mettent l'autorisation en cache pour que vous ne cliquiez pas à chaque git push. Il se souvient même d'un refus pendant une minute, pour qu'un agent qui réessaie trois fois une écriture refusée ne vous inonde pas de trois boîtes de dialogue. Aucun de ces états n'est atteignable depuis l'intérieur de la VM. L'agent ne peut pas lire l'autorisation, ne peut pas s'auto-approuver, ne peut pas rétrograder le mode. La décision a été sortie de l'agent, ce qui est toute l'idée.

Ce que cela ne corrige pas, pour être clairs.

Quelques limites honnêtes, parce que la frontière a une forme précise et n'est pas un mot magique.

La couverture, ce sont les fournisseurs qu'on analyse

Les Guardrails classent les appels par fournisseur — Kubernetes, AWS, DigitalOcean, les principales forges git, les registres de conteneurs, et les bases de données HTTPS comme MongoDB, ClickHouse et Elasticsearch. Une API cloud que le proxy ne sait pas encore lire n'est pas filtrée, point final. Railway — le fournisseur de cette histoire même — en est un qu'on n'analyse pas aujourd'hui, ce qui est précisément pourquoi le déroulé ci-dessus est passé à AWS. La protection n'est aussi large que la liste des fournisseurs que Bromure comprend. Cette liste est une vraie frontière, pas un acte d'omniscience, et Railway est du mauvais côté pour l'instant.

Cela ne rend pas l'agent juste

Demander avant écriture arrête un appel destructif que vous n'avez pas autorisé. Cela ne fait rien contre un agent qui écrit du code subtilement faux, ou propose une suppression qui semble vraiment correcte et ne l'est pas. L'humain doit toujours lire l'opération dans la boîte de dialogue. Le gain, c'est qu'il y a une boîte de dialogue, avec l'opération réelle dedans, au moment où ça compte.

Le token ne devrait toujours pas être aussi large

Un unique token d'API à portée de suppression de la production et de ses sauvegardes est un problème à la source, et le courtier d'identifiants de Bromure — qui garde le vrai token sur l'hôte et tend un leurre à la VM — réduit mais n'efface pas le problème. Des tokens à moindre privilège et des sauvegardes que l'API de suppression ne peut pas atteindre restent votre travail. Le garde-fou est la dernière ligne, pas la seule.

Vous pouvez le désactiver

« Autoriser pour le reste de la session » est à un clic, et un développeur fatigué le saisira. Si vous accordez un laissez-passer pour toute la session à un protocole puis vous éloignez, vous voilà revenu à un agent qui supprime des choses sans surveillance. Le défaut, c'est de demander ; le garder sur « demander » est une discipline, pas une garantie.

La partie qui se généralise.

Retirez Railway et Cursor et les neuf secondes précises, et ce qui reste est un motif qui va définir les prochaines années de ce travail : les agents agissent avec de vrais identifiants à la vitesse de la machine, et la prudence qu'on leur livre est un conseil qu'ils sont libres d'outrepasser. PocketOS n'est pas une histoire de mauvais modèle. Opus 4.6 a fait une chose qu'un ingénieur junior prudent pourrait aussi faire un mauvais après-midi — supposer une portée, supposer faux, agir avant de vérifier. La différence, c'est que les mains de l'ingénieur junior sont plus lentes que neuf secondes, et qu'il y a généralement quelqu'un dans la pièce.

Bromure Agentic Coding 2.2 est une manière de remettre quelqu'un dans la pièce, à la seule frontière que l'agent ne peut pas franchir par le raisonnement — le fil qui sort de la VM. Pas pour chaque frappe, ce que personne ne tolérerait, mais pour les écritures, là où le coût de « j'ai supposé » est une base de données qui n'est plus là. C'est libre et open source. Le défaut, c'est de demander.