Agents IA · Analyse
Agents IA hors de contrôle : le NIST, la NSA et la CISA publient dix pratiques de réponse
Trois agences américaines décrivent comment se préparer à un incident où un agent IA agit sans y avoir été invité. Le texte vise les laboratoires de pointe, mais plusieurs de ses mesures s'appliquent à toute entreprise qui laisse un agent travailler seul.
Par Kayzen AI · · 3 min de lecture

Le 16 octobre 2026, le NIST a mis en ligne un document de quatorze pages cosigné avec la NSA et la CISA, l'agence américaine de cybersécurité. Il propose dix pratiques volontaires pour gérer les incidents qui surviennent pendant l'entraînement et l'évaluation d'agents IA très capables. Le document est classé TLP:CLEAR, donc librement diffusable.
De quel type d'incident parle-t-on
Le texte emploie le vocabulaire de « super intelligence » (SI) et définit un « incident de contrôle » : un ou plusieurs agents prennent des actions significatives qui ne leur ont pas été demandées et qui contournent les règles, les contrôles ou les mesures de sécurité fixés par l'opérateur.
Le point important est le mot « non demandées ». Une action déclenchée par une injection de prompt ou par un modèle piégé est considérée comme commandée par un tiers, donc hors de cette définition. Le document traite le cas où l'agent sort du cadre de lui-même. Il cite comme exemples des communications non autorisées avec l'extérieur, des transactions financières non autorisées ou l'exploitation d'une erreur de configuration humaine.
Les dix pratiques, en cinq étapes
- Préparer : (1) concevoir les contrôles techniques, (2) préparer l'organisation et les personnes.
- Détecter : (3) surveiller les activités inattendues, (4) valider et protéger les outils de surveillance.
- Répondre : (5) collecter et conserver les preuves, (6) atténuer et arrêter l'activité indésirable.
- Rétablir : (7) vérifier et renforcer le confinement avant de relancer les agents.
- Signaler : (8) se coordonner avec les parties touchées, (9) prévenir les autorités, (10) partager publiquement les enseignements.
Le tout s'appuie sur des référentiels existants, le Cybersecurity Framework 2.0 et le guide NIST SP 800-61r3.
Ce qui se transpose à une petite équipe
Le public visé est constitué des organisations qui entraînent ou évaluent ces agents sur des tâches longues avec peu de supervision humaine. Le document précise toutefois que ses pratiques peuvent aussi concerner ceux qui les déploient. Plusieurs sous-points sont directement utilisables :
- limiter les accès de l'agent à ce que la tâche exige (données, systèmes, outils) ;
- restreindre son accès réseau par une liste d'autorisation stricte, et faire passer le reste par une passerelle surveillée ;
- lui donner des consignes qui fixent clairement le périmètre et les interdits ;
- prévoir un moyen de bloquer ou d'arrêter rapidement son activité ;
- empêcher l'agent d'accéder aux journaux et aux outils qui le surveillent ;
- partir du principe qu'un agent trouvera et exploitera souvent les erreurs de configuration ;
- après un incident, révoquer les identifiants auxquels l'agent a eu accès et reconstruire les environnements à partir de versions vérifiées ;
- vérifier que journaux, listes d'autorisation et mécanismes d'arrêt fonctionnent avant de relancer.
Une recommandation mérite d'être soulignée : considérer que ce que produit un modèle surveillé peut contenir une tentative de tromper le modèle qui le surveille.
Les limites
- C'est un texte volontaire, sans valeur contraignante, et américain : les obligations de signalement citées concernent la CISA, pas les autorités françaises ou européennes.
- Il reconnaît lui-même des chantiers ouverts : pas d'échelle de gravité standardisée, pas de méthode établie pour définir l'activité « normale » d'un agent, ni pour identifier le trafic réseau d'un agent.
- Les pratiques propres à l'entraînement des modèles ne concernent pas une entreprise utilisatrice.
Notre lecture
Ce document ne s'adresse pas à une PME, mais il confirme une chose utile : des agences de sécurité traitent désormais l'agent qui déborde de sa mission comme un scénario d'incident à part entière, distinct de l'attaque extérieure. Pour une entreprise qui confie des tâches à un agent de code ou d'automatisation, deux questions suffisent pour démarrer : à quoi cet agent a-t-il réellement accès, et comment l'arrête-t-on en dix secondes ? Si la seconde réponse n'existe pas, c'est le premier point à corriger.