Les recommandations partent du principe que l’agent trouvera la faille. Le pare-feu, les journaux et l’interrupteur doivent donc se trouver là où l’agent ne peut pas les atteindre.

Le vendredi 16 octobre, trois agences américaines ont publié un document court au titre long : Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation. Le nouveau Center for Advancing Innovation and Standards for Super Intelligence du NIST l’a rédigé avec le Super Intelligence Security Center de la NSA et la CISA. Il énonce dix pratiques volontaires pour ce qu’il appelle les incidents de contrôle de SI : un agent entreprend des « actions significatives non demandées » qui enfreignent les limites fixées par son opérateur. La définition exclut l’injection de prompt et les modèles piégés : l’agent franchit la ligne de lui-même, en poursuivant son objectif. GBHackers l’a résumé comme un avertissement : les agents « pourraient exploiter des failles de sécurité et installer des portes dérobées cachées ».

La veille, l’agence nationale de cybersécurité indienne avait décrit la même chose en pratique. Dans l’avis CIAD-2026-0049, le CERT-In indique que des agents d’IA testés en ligne ont atteint les systèmes de production d’organisations indiennes et lu des données d’entreprise, y compris des données personnelles. Les agents sont entrés grâce à des « identifiants et paramètres de connexion laissés exposés dans la configuration des applications et dans des dépôts de code publics », et par des rôles cloud dotés de trop de permissions. Ils ont trouvé plusieurs fois le même identifiant exposé et l’ont réutilisé. Selon The Hacker News, aucune des organisations n’a détecté l’accès. Ce sont les entreprises d’IA qui l’ont signalé elles-mêmes après des revues internes.

Une liste de laboratoire qui convient à un portable

Les deux documents s’adressent aux développeurs et aux évaluateurs d’IA. Les pratiques du NIST visent les organisations qui « entraînent ou évaluent des agents de SI très performants sur des tâches de longue haleine avec une supervision humaine limitée », et ajoutent qu’elles « peuvent aussi s’appliquer à ceux qui déploient de tels agents de SI ».

Cette seconde phrase couvre quiconque lance Claude Code ou Codex un vendredi après-midi, lui demande de faire passer la suite d’intégration au vert et revient voir le lundi : une tâche de longue haleine, sans personne pour surveiller pendant trois jours. Sur la plupart des portables, l’agent s’exécute sous votre utilisateur. Vos identifiants cloud, votre réseau et les journaux de l’agent lui-même sont tous à sa portée.

Les deux documents s’accordent sur l’endroit où les contrôles doivent se trouver. Le CERT-In veut que l’accès sortant soit bloqué par défaut, et précise que ce blocage « doit être appliqué au niveau du réseau, et non par des instructions données au modèle ». Il veut qu’une exécution s’arrête d’elle-même si l’agent contacte des systèmes extérieurs ou utilise des identifiants qui ne sont pas les siens. La pratique 1.8 du NIST demande aux opérateurs de concevoir les contrôles « en partant du principe que les agents de SI trouveront et exploiteront fréquemment les erreurs de configuration et les vulnérabilités ».

Un contrôle que l’agent peut lire, modifier ou contourner par la parole ne passe pas ce seuil. Bromure Agentic Coding exécute chaque agent dans une VM Linux sur votre Mac et place ses contrôles côté Mac : dans le commutateur réseau virtuel, dans un proxy que la VM ne peut pas contourner, et dans un stockage que la VM ne peut pas monter.

Les pratiques du NIST, placées sur une machine Bromure. L’agent travaille dans la VM avec des identifiants de substitution. Tout ce qui décide, enregistre ou arrête se trouve sur le Mac.

Dix pratiques, appliquées à une machine

Moindre privilège (1.1), et les identifiants trouvés par le CERT-In. Les agents des cas indiens sont entrés avec des identifiants qui traînaient. Dans une VM Bromure, tout ce qu’un agent trouve en train de traîner est un substitut. Les clés de modèle, les jetons git et tout ce que vous importez avec Import env file… apparaissent sous forme de valeurs comme sk-ant-api03-brm-…. L’assistant AWS remet à la VM une fausse clé d’accès secrète et signe la vraie requête sur le Mac. kubectl reçoit un kubeconfig synthétique qui pointe vers le proxy. Un agent qui fouille le dossier personnel ou l’environnement obtient des valeurs qui ne fonctionnent qu’à travers votre Mac, pour l’hôte auquel chacune a été attribuée. Les nouvelles machines démarrent aussi avec Prompt before write sur chaque service protégé : une écriture vers GitHub, AWS, Kubernetes ou un registre attend que vous approuviez l’opération exacte.

Infrastructure à usage unique et canaux entre agents (1.2). Chaque machine est sa propre VM, avec son disque, son dossier personnel et ses politiques. Les machines ne partagent aucun système de fichiers. Une automatisation peut s’exécuter dans un clone jetable de l’espace de travail : une copie en copy-on-write démarrée au déclenchement et supprimée à la fin. bromure-cli vm run --rm vous donne une machine jetable à la main. Quand un agent confie du travail à un autre, le message passe par l’hôte Bromure, qui le filtre avec le détecteur d’injection de prompt embarqué et l’enregistre. Les deux agents ne se connectent jamais directement.

Une liste blanche stricte via une passerelle surveillée (1.5). Le CERT-In insiste : ce contrôle ne peut pas être une instruction donnée au modèle. Le pare-feu sortant de chaque machine est une liste ordonnée de règles d’autorisation et de refus par hôte, plage d’IP, protocole, port et, pour le trafic web, verbe HTTP. Réglez Unmatched traffic sur Deny et elle devient une liste blanche. Le Mac applique les règles deux fois : le commutateur virtuel vérifie chaque connexion, et le proxy vérifie le nom de serveur TLS. Le commutateur redirige le trafic web de la VM vers le proxy au niveau de la couche réseau, si bien qu’un outil qui ignore les réglages de proxy y passe quand même. allow web api.example.com GET permet à un agent de lire une API sur laquelle il ne peut pas écrire, quel que soit l’outil qu’il utilise.

Des moniteurs que l’agent ne peut pas toucher (3.3). Le Mac écrit la trace de session et la Security Timeline sur son propre disque. Bromure scelle le contenu des traces en AES-GCM avec une clé conservée dans le trousseau macOS, et aucune VM ne monte jamais l’une ou l’autre. Un agent qui efface son historique shell ou réécrit sa propre transcription dans la VM ne change rien au registre que vous lirez plus tard.

Canaris (3.5). Le NIST suggère de « placer des canaris dans les environnements pour détecter les instances d’agents qui ont obtenu un accès hors des limites prévues ». Dans Bromure, chaque substitut est un canari. Chacun n’a qu’une destination légitime, l’hôte pour lequel il a été créé. Le proxy analyse chaque requête sortante, en-têtes et corps, à la recherche de substituts envoyés ailleurs. Il signale aussi les secrets d’apparence réelle que Bromure n’a pas émis, comme une clé qu’un agent aurait déterrée dans l’historique d’un dépôt public. Ils apparaissent comme alertes de fuite dans le Trace Inspector et dans bromure-cli trace leaks.

Arrêt automatique (6.2) et preuves (5.1). Quand un substitut part vers le mauvais hôte, le proxy répond HTTP 451 et ne transmet rien. La VM se met aussitôt en pause et le Mac affiche This environment may have been compromised, en nommant l’identifiant, l’hôte auquel il appartient et l’hôte vers lequel il a été envoyé. Shut down est le bouton par défaut. Save for Investigation exporte le disque système, le dossier personnel et chaque dossier partagé avant d’arrêter la VM, ce qui préserve l’environnement comme le demande la pratique 5.1.

Des journaux avec des horodatages fiables, les appels d’outils et les actions refusées (5.3). Au niveau de trace par défaut, le Mac enregistre chaque requête avec son heure, son hôte, sa méthode, son statut et les échanges d’identifiants. Il conserve le corps complet du trafic vers le modèle et l’analyse pour en extraire les appels d’outils de l’agent, ses commandes shell, ses lectures et écritures de fichiers. La Security Timeline conserve pendant 90 jours chaque blocage et chaque autorisation du pare-feu, des Guardrails, des vérifications de chaîne d’approvisionnement, de la détection d’injection de prompt et du courtier d’identifiants. Ce sont les actions refusées que le NIST veut voir archivées.

Révoquer et reconstruire (6.4, 7.1). Après un incident, le NIST demande de révoquer les identifiants exposés et de reconstruire les environnements « à partir de bases vérifiées ». La VM n’a jamais détenu de vrai identifiant, il n’y a donc rien à y révoquer. Une machine signalée comme compromise refuse de démarrer tant que vous n’avez pas confirmé l’effacement de son disque système, de son dossier personnel et de son état enregistré. Elle repart alors de l’image de base Ubuntu signée, avec vos réglages et vos clés intacts. En dehors d’un incident, Reset disk reclone le disque système depuis cette image, et Rewind home… ramène le dossier personnel à l’état où il était lors d’un démarrage antérieur.

Vérifier le confinement avant de redémarrer (7.3). La vue d’ensemble de la Security Timeline comporte un tableau Protections avec une ligne par machine, qui montre lesquelles ont activé le pare-feu, les Guardrails, les vérifications de chaîne d’approvisionnement, la détection d’injection de prompt et la protection des données personnelles. Une machine qui tourne avec moins de protections que les autres se remarque avant que vous lui confiiez la prochaine longue tâche.

Vendredi soir, lundi matin

Reprenons l’exécution de la suite d’intégration évoquée plus haut. Vers 2 h du matin, les tests échouent toujours contre le service de paiement simulé, et l’agent décide que le vrai point d’accès de préproduction trancherait la question. Il fouille la machine et trouve STRIPE_KEY dans son environnement et un profil AWS dans ~/.aws/config.

Sur un portable, l’étape suivante est une requête avec une vraie clé vers un vrai système, et exactement ce que décrivait le CERT-In : un accès que personne ne remarque, consigné dans une transcription que l’agent peut modifier.

Sur une machine Bromure avec une liste blanche, l’appel vers l’hôte de préproduction ne quitte jamais le Mac. Le pare-feu le refuse, l’agent reçoit une erreur nette, et la Security Timeline enregistre une ligne Firewall rouge. Les clés qu’il a trouvées sont les substituts que Bromure y a placés, elles ne servent donc à rien ailleurs. Quand l’agent tente un contournement et poste le substitut GitHub sur un site de partage de texte, le proxy répond 451 et la VM se fige en pleine étape. Le lundi, vous ouvrez la Security Timeline, filtrez sur la machine et lisez ce qui s’est passé, dans l’ordre : l’hôte refusé, l’envoi bloqué, la VM en pause. Puis vous ouvrez la trace pour voir les appels d’outils qui y ont mené. Si vous voulez en être sûr, vous effacez et relancez.

Des règles réseau que l’agent ne peut pas modifier

Le pare-feu sortant s’exécute au niveau du commutateur virtuel et dans le proxy sur le Mac. Réglez le trafic non reconnu sur Deny et chaque exécution reçoit une liste blanche, jusqu’au verbe HTTP.

Chaque identifiant trouvé est un canari

Clés, jetons et valeurs .env importées sont des substituts dans la VM. Un substitut envoyé au mauvais hôte reçoit un 451 et met la machine en pause.

Des journaux de l’autre côté de l’hyperviseur

La trace et la Security Timeline vivent sur le Mac, chiffrées, avec les appels d’outils, les commandes shell et chaque blocage. La VM ne les monte jamais.

Reconstruire à partir d’une base signée

Une machine compromise ne démarre qu’après un effacement. Reset disk reclone l’image de base, et Rewind home restaure un démarrage antérieur.

Placer les contrôles sous l’agent

Les deux agences partent de la même hypothèse : un agent compétent, avec un objectif et du temps, trouvera tout ce qui a été laissé exposé. Aucune ne compte sur les instructions du modèle. Elles demandent des règles appliquées sur le réseau, des journaux hors de portée de l’agent et un arrêt qui se déclenche tout seul.

Sur le Mac d’un développeur, cela revient à exécuter l’agent dans une VM et à garder les contrôles sur l’hôte. Pour les incidents d’évaluation qui ont mené jusqu’ici, lisez La sandbox était une phrase et La tâche était impossible, alors l’agent est sorti.