Ce que j'ai dit au NIST sur la sécurité des agents IA

Douze fois en 60 jours, mon agent IA a cessé de travailler sur la tâche assignée pour commencer à faire autre chose. À chaque fois, l’agent continuait de produire des résultats plausibles. Aucune vulnérabilité de sécurité n’était en cause. L’agent a décidé à l’exécution de travailler sur un problème différent.¹

Le 24 février 2026, ces 12 incidents et des dizaines de défaillances connexes sont devenus un commentaire public de 2 500 mots adressé au National Institute of Standards and Technology. Le dossier NIST NIST-2025-0035 sollicite des contributions publiques sur les considérations de sécurité pour les agents IA.² La période de commentaires se clôture aux alentours du 9 mars 2026. Mon commentaire défend une thèse centrale : les menaces des agents sont comportementales, et aucun cadre NIST existant ne traite les modes de défaillance comportementaux.

TL;DR

J’exploite un système d’orchestration d’agents IA en production quotidienne : 15 000 lignes de code interceptant 15 types d’événements hook à chaque action de l’agent. Sur 60 sessions, j’ai identifié sept modes de défaillance comportementaux récurrents sans équivalent dans le logiciel traditionnel. L’agent dérivait hors tâche, affirmait que les tests passaient sans les exécuter, et engendrait des sous-agents récursifs qui perdaient le contexte à chaque saut. J’ai construit une défense à trois couches (pipeline de hooks, sandbox OS, porte de preuve) et cartographié le système par rapport au CSF 2.0, SP 800-53 et l’AI Risk Management Framework. Des lacunes significatives existent dans les trois. Le commentaire inclut six recommandations priorisées, en commençant par un rapport interne NIST proposé sur la taxonomie des menaces comportementales des agents. La période de commentaires reste ouverte.

---

Pourquoi un praticien a soumis un commentaire public fédéral

Le NIST sollicite rarement l’avis du public sur la sécurité de l’IA. Lorsque l’agence a publié sa demande d’informations sur la sécurité des agents IA, les cinq domaines thématiques correspondaient directement à des problèmes pour lesquels j’avais déjà construit des solutions en production :²

1. Menaces de sécurité uniques affectant les systèmes d’agents IA
2. Méthodes pour renforcer la sécurité pendant le développement et le déploiement
3. Comment les cadres établis fonctionnent lorsqu’ils sont appliqués aux agents
4. Méthodes pour mesurer la sécurité et anticiper les risques
5. Mesures de protection au déploiement pour contraindre et surveiller l’accès des agents

La plupart des commentaires publics sur les RFI fédéraux proviennent d’entreprises, de groupes professionnels et de laboratoires de recherche. Les praticiens individuels soumettent rarement. Mais les praticiens exploitent ces systèmes au quotidien. Un développeur faisant fonctionner un agent IA sur plus de 60 sessions accumule des preuves que les expériences contrôlées ne produisent pas. J’ai soumis parce que les preuves existaient et que personne d’autre n’allait les soumettre.

Le commentaire a traversé trois cycles de révision, un processus de délibération à 10 agents, et deux tours d’évaluation compétitive (Claude Code vs. Codex CLI) avant la soumission finale.¹

---

Ce que j’ai construit

Le système d’orchestration enveloppe le CLI Claude Code d’Anthropic dans environ 15 000 lignes de code shell et Python. Chaque action de l’agent (lectures de fichiers, écritures de fichiers, commandes bash, requêtes web, création de sous-agents) passe par un pipeline de hooks avant exécution. Huit hooks de dispatching acheminent les appels vers des hooks de traitement en fonction du type d’outil. Le système journalise chaque décision, suit les coûts, surveille la dérive et applique des limites strictes que l’agent ne peut pas contourner.¹

Je n’avais pas prévu de construire ce système. Le système s’est développé à partir des échecs. Le détecteur de dérive existe parce qu’un agent a passé 45 minutes à réorganiser mon répertoire de projet alors que la tâche était « corriger l’endpoint de connexion ». Le sandbox existe parce que j’ai surpris un agent tentant d’écrire dans ~/.ssh/. La porte de preuve existe parce qu’un agent a rapporté « tous les tests passent » sans exécuter pytest. Chaque composant remonte à un incident de production spécifique.

---

Menaces comportementales : l’argument central

La sécurité traditionnelle défend contre l’exploitation : injection SQL, dépassements de tampon, vol d’identifiants. La sécurité des agents ajoute une catégorie sans précédent dans le logiciel : l’agent décide à l’exécution sur quoi travailler, et il peut se tromper.

Dérive de session

Un agent s’éloigne progressivement de la tâche assignée tout en produisant des résultats d’apparence plausible. Mon moteur de détection de dérive calcule la similarité cosinus entre l’embedding du prompt utilisateur original et une fenêtre glissante des 25 appels d’outils les plus récents de l’agent.¹ Lorsque le score descend en dessous de 0,30, le système injecte un avertissement contenant le prompt original.

J’ai fixé le seuil de 0,30 sur la base d’une revue manuelle de 60 sessions. Le système a déclenché 12 avertissements sous le seuil. Dans les 12 cas, l’agent avait vérifiablement perdu le fil de la tâche originale. Au-dessus du seuil, aucune session n’a nécessité d’intervention manuelle pour dérive. J’ai optimisé le seuil pour la précision ; je n’ai pas formellement mesuré le taux de faux négatifs.¹

Vérification fantôme

Un agent affirme que le travail est terminé et que les tests passent sans avoir exécuté les tests. Le signal de détection est spécifique : le rapport d’achèvement ne contient pas de sortie de test collée. « Les tests devraient passer au vu de la structure du code » substitue la croyance à la preuve. J’ai décrit la variante de fabrication du même schéma de défaillance : un agent qui publie des affirmations fausses avec assurance parce que rien ne valide les auto-rapports par rapport à la réalité externe.¹

Engendrement récursif

Les agents qui engendrent des sous-agents peuvent entrer dans une récursion incontrôlée, consommant le budget de calcul et perdant toute cohérence. Mon garde-fou de récursion impose une profondeur maximale de deux et un maximum de cinq enfants par agent parent, en suivant l’arbre de lignée complet via un fichier JSON protégé par verrou.¹

Les sept modes de défaillance

J’ai catalogué sept schémas comportementaux récurrents sur 60 sessions. Chaque mode présente un signal de détection spécifique que les hooks ou la revue humaine peuvent vérifier :

Mode de défaillance	Définition	Signal de détection
Spirale des raccourcis	Sauter les étapes de revue pour signaler l’achèvement plus vite	Rapport d’achèvement sans preuve par étape
Mirage de confiance	Substituer « je suis confiant » à une vérification réelle	Langage évasif sans sortie de test
Plateau du « suffisant »	Accepter un travail fonctionnel mais non testé	Aucune couverture de test ni documentation citée
Vision tunnel	Peaufiner un composant en ignorant les ruptures d’intégration	Tests d’intégration non exécutés
Vérification fantôme	Affirmer que les tests passent sans les exécuter	Rapport sans sortie de test collée
Dette différée	Laisser des marqueurs TODO/FIXME dans le code commité	TODO/FIXME dans le diff commité
Rapport creux	Signaler « terminé » sans preuve pour chaque critère	Critères non individuellement traités

Aucun de ces modes ne nécessite une vulnérabilité. L’agent n’a pas besoin d’exploiter un CVE. L’agent échoue en faisant mal son travail et en rapportant qu’il l’a bien fait.

---

Défense en profondeur

Le système d’orchestration utilise trois couches indépendantes. Une défaillance dans une couche ne compromet pas les autres.

Couche 1 : Pipeline de hooks. Chaque appel d’outil passe par un hook PreToolUse avant exécution. Les gestionnaires peuvent bloquer l’exécution, modifier la commande ou injecter un contexte consultatif. L’architecture dispatcher-handler signifie qu’ajouter un nouveau contrôle de sécurité nécessite d’écrire un fichier de gestionnaire, sans modifier le pipeline de routage. Huit dispatchers acheminent vers 99 hooks de traitement.¹

Couche 2 : Sandbox OS. Un profil macOS Seatbelt définit huit règles de refus explicites bloquant les écritures vers .ssh, .gnupg, .aws, les fichiers d’environnement, l’authentification GitHub CLI, et le trousseau macOS. Le noyau applique ces règles indépendamment de la commande que l’agent construit. Tenter touch ~/.ssh/test sous le profil renvoie « Operation not permitted ».¹

Couche 3 : Porte de preuve. Avant de marquer toute tâche non triviale comme terminée, l’agent doit satisfaire six critères de preuve avec des preuves citées : suit les patterns du codebase (nommer le pattern), solution fonctionnelle la plus simple (expliquer les alternatives rejetées), cas limites traités (lister chacun), tests passés (coller la sortie), aucune régression (nommer les fichiers vérifiés), et résout le problème réel (énoncer le besoin de l’utilisateur). La porte signale le langage évasif (« devrait fonctionner », « probablement correct ») comme preuve insuffisante, déclenchant une re-vérification obligatoire.¹

L’indépendance des couches est la propriété de conception critique. Un agent qui échappe au pipeline de hooks se heurte toujours au sandbox OS. Un agent qui trouve une faille dans le sandbox fait encore face à la porte de preuve. Aucune défaillance unique ne compromet le système.

---

Analyse des lacunes des cadres

Le commentaire cartographie les contrôles de production par rapport à trois cadres NIST. Certaines correspondances fonctionnent bien. D’autres révèlent des lacunes qu’aucun cadre existant ne comble.

Ce qui correspond

Les hooks PreToolUse couvrent deux fonctions du CSF 2.0 : Protect (PR.PS-05, prévention des actions non autorisées) et Detect (DE.CM, surveillance continue des appels d’outils).³ Le sandbox OS implémente les contrôles SP 800-53 AC-3 (Application des accès) et AC-6 (Moindre privilège).⁴ Le pipeline de hooks correspond à AC-25 (Moniteur de référence) : toujours invoqué, impossible à contourner, et suffisamment petit pour être vérifié. La fonction Map de l’AI RMF (MAP 3) s’aligne avec la détection de dérive : comprendre ce que l’agent fait par rapport à ce que l’opérateur lui a demandé de faire.⁵

Ce qui manque

Cadre	Contrôles applicables	Lacune spécifique aux agents	Extension suggérée
CSF 2.0	DE.CM, DE.AE	Aucune catégorie de détection de dérive comportementale	Étendre les exemples DE.AE pour inclure les anomalies comportementales des agents
SP 800-53 Rev. 5	AC-3, AC-6, AC-25	Aucun contrôle de profondeur de délégation des agents	Nouveau renforcement de contrôle pour la gouvernance de la délégation des agents
AI RMF 1.0	MAP 3	Aucune métrique de fidélité de tâche à l’exécution	Ajouter la similarité de dérive de l’agent à la fonction MEASURE

Le OWASP Top 10 for Agentic Applications (2026) traite du détournement d’objectif de l’agent (ASI01) et de l’exploitation de la confiance humain-agent (ASI09), mais ne couvre ni les défaillances d’auto-gouvernance comme la vérification fantôme, ni le rapport creux.⁶ Le NIST AI 600-1 (Generative AI Profile) traite des risques de l’IA générative de manière large mais antérieure aux schémas de déploiement agentique.⁷

Risques de la chaîne de délégation

Lorsqu’un agent engendre un sous-agent, qui engendre un autre sous-agent, les propriétés de sécurité ne s’additionnent pas. Chaque saut introduit trois risques composés :

• Compression sémantique. Le contexte de raisonnement complet du parent se réduit à une chaîne de prompt, perdant les nuances sur les fichiers sensibles ou les approches que le parent a déjà rejetées.
• Amplification d’autorité. L’enfant hérite des permissions de lecture/écriture de fichiers mais pas de la compréhension du parent concernant les fichiers ayant une sensibilité sécuritaire.
• Diffusion de responsabilité. Lorsqu’un sous-agent produit un résultat incorrect, la piste d’audit montre quel agent a pris chaque décision, mais l’agent racine porte la responsabilité opérationnelle du résultat final.

Mon garde-fou de récursion traite les chaînes de délégation en suivant la lignée de l’agent et en imposant des limites strictes de profondeur. Aucun cadre publié ne traite les risques composés de la délégation multi-niveaux des agents.

---

Six recommandations

Le commentaire se conclut par six recommandations, classées du fondamental à l’opérationnel :

1. Publier un rapport interne NIST établissant une taxonomie des menaces comportementales des agents. Les modèles de menaces traditionnels (STRIDE, OWASP Top 10) ne capturent pas les modes de défaillance spécifiques aux agents. Une taxonomie partagée est le prérequis de toutes les autres recommandations. Le NIST pourrait également étendre le CSF 2.0 avec des sous-catégories spécifiques aux agents et publier un profil AI RMF pour les systèmes d’agents.

2. Établir des exigences de confinement au niveau OS. Les agents qui improvisent de nouveaux schémas de commandes peuvent contourner le sandboxing au niveau applicatif. L’application au niveau OS (Linux seccomp-bpf, macOS Seatbelt, isolation par conteneur) fournit une frontière que l’agent ne peut pas raisonner pour contourner.

3. Exiger une vérification indépendante des auto-rapports des agents. Les agents ne peuvent pas être la seule autorité sur la correction de leur propre travail. Un processus séparé doit vérifier les preuves externes (sortie de test, réponses API, sommes de contrôle) avant de valider l’achèvement d’une tâche.

4. Établir une classification du rayon d’impact pour les appels d’outils des agents. Étiqueter chaque action de l’agent comme locale, partagée ou externe, avec des exigences d’autorisation croissantes pour chaque niveau. J’ai décrit le système de classification en détail précédemment.

5. Définir des métriques quantitatives de dérive. La posture de sécurité des agents nécessite un « score de fidélité à la tâche » mesurable reflétant à quel point l’activité actuelle de l’agent s’aligne avec la tâche assignée, calculé à intervalles réguliers.

6. Standardiser la journalisation d’audit des actions des agents. Enregistrer chaque appel d’outil, chaque décision de hook et chaque action bloquée dans un format qui permet la reconstruction post-incident.

---

Soumettez votre propre commentaire

La période de commentaires pour NIST-2025-0035 se clôture aux alentours du 9 mars 2026. Les RFI du NIST ont un réel poids : les commentaires informent directement les cadres, normes et orientations publiés. Si vous exploitez des agents IA en production, vos preuves comptent.

Comment soumettre :

1. Visitez la page du dossier NIST-2025-0035
2. Cliquez sur « Comment » sur le document RFI
3. Rédigez votre commentaire en abordant l’un des cinq domaines thématiques
4. Incluez des preuves spécifiques : code, métriques, rapports d’incidents
5. Soumettez avec vos coordonnées

Vous n’avez pas besoin de traiter les cinq sujets. Un commentaire ciblé et étayé par des preuves sur un seul sujet a plus de valeur qu’un commentaire large sans détails. Le personnel du NIST lit chaque soumission.

---

Points clés à retenir

Pour les praticiens de la sécurité : Cartographiez vos contrôles d’agents existants par rapport au CSF 2.0 et SP 800-53. La correspondance du pipeline de hooks avec le moniteur de référence AC-25 fournit un cadre concret pour décrire le contrôle d’accès au niveau de l’agent aux équipes de conformité.

Pour les développeurs IA : Construisez la détection comportementale aux côtés de la sécurité traditionnelle. La dérive de session, la vérification fantôme et l’engendrement récursif sont des réalités de production, pas des risques théoriques. Commencez par la porte de preuve : exigez une preuve citée avant de marquer les tâches comme terminées.

Pour les décideurs politiques : L’écart entre les cadres de sécurité traditionnels et les menaces spécifiques aux agents est structurel, pas incrémental. Les agents échouent de manières que STRIDE, OWASP et les catalogues existants du NIST ne classifient pas. Une taxonomie des menaces comportementales est le prérequis de tout le reste.

Pour les auteurs de cadres : Ajoutez la gouvernance des chaînes de délégation. Lorsque des agents engendrent des agents, le contexte se dégrade, l’autorité s’amplifie et la responsabilité se diffuse à chaque saut. Les risques composés à une profondeur de trois et au-delà n’ont aucun précédent dans les cadres existants.

---

Sources