Introduction : pourquoi le NIST lance l’alerte maintenant
Les 7–8 janvier 2026, le NIST (National Institute of Standards and Technology) a publié une Request for Information (RFI) pour recueillir des retours publics sur la sécurisation des agents IA (agentic AI); c’est-à-dire des systèmes IA capables d’agir sur des environnements externes (faire des actions qui changent un état : écrire, modifier, exécuter, acheter, publier, configurer…).
L’objectif est de structurer un cadre de bonnes pratiques avant que l’adoption ne devienne massive… et que les incidents se multiplient.
Le document précise aussi une échéance de commentaires au 9 mars 2026.
-> On passe d’une IA “qui conseille” à une IA “qui agit”, et la cybersécurité doit suivre.
C’est quoi un agent IA ?
Un agent IA, est un système qui peut :
● planifier une suite d’actions (raisonnement / orchestration),
● appeler des outils (API, scripts, navigateurs, ERP, cloud, Jira, CRM…),
● exécuter des actions parfois de façon semi-autonome.
Exemples concrets en entreprise :
● un agent qui lit des emails et crée des tickets + déclenche une procédure,
● un agent qui corrige du code et pousse une PR,
● un agent “browser” qui se connecte à des sites et effectue une opération,
● un agent qui administre des accès (création de comptes, permissions, rotations de clés…).
C’est précisément ce type de systèmes “à capacité d’action” que le NIST vise : ceux qui peuvent provoquer des changements persistants hors du système IA.
L’agent devient un “nouvel utilisateur à privilèges”
En cybersécurité, on sait déjà qu’un compte à privilèges + faible visibilité = risque majeur.
Les agents IA combinent souvent :
● accès à des données sensibles (documents, code, clients, RH),
● jetons/API keys et intégrations SaaS,
● capacité d’exécution (scripts, actions cloud),
● vitesse et automatisation (ils font beaucoup, très vite).
Et on voit déjà une réalité de terrain : l’usage GenAI en entreprise explose, souvent en mode non contrôlé (“shadow AI”). Par exemple, Netskope indique (rapport 2026) :
● 47% des utilisateurs GenAI passent par des apps personnelles,
● en moyenne 223 incidents / mois de violations de politiques data,
● et une volumétrie moyenne de 18 000 prompts / mois par organisation (avec des extrêmes bien plus hauts).
Même sans agent autonome, la fuite de données est déjà mesurable : Harmonic Security observe 4,37% des prompts contenant des données sensibles et 22% des fichiers uploadés (sur un échantillon massif Q2 2025).
-> Imaginez maintenant le même scénario avec un agent IA qui, au-delà d’analyser, dispose de capacités d’action : il peut écrire, exécuter, envoyer ou déployer automatiquement, ce qui transforme une simple exposition de données en risque opérationnel immédiat.
Ce que le NIST veut obtenir via la consultation (RFI)
Le NIST (via son centre CAISI) veut que l’écosystème partage :
● les menaces principales (hijacking, backdoors, poisoning…),
● des contrôles techniques concrets,
● des méthodes d’évaluation / assurance (comment tester, mesurer, auditer),
● des recommandations de déploiement (garde-fous, surveillance, gouvernance),
● et les priorités de recherche (ce qui manque encore).
Ce point est clé : le NIST ne cherche pas une opinion vague, mais des retours opérables (cas d’usage, “ce qui marche / ce qui casse”, métriques, patterns d’architecture).
|La logique de la consultation NIST rejoint un besoin clé : formaliser l’évaluation des risques IA et les plans de traitement associés, compétences adressées dans la formation Lead AI Risk Manager.
Les risques des IA agentiques : le modèle de menace
1) Prompt injection (directe et indirecte)
C’est aujourd’hui un risque majeur reconnu dans les référentiels GenAI : l’OWASP place Prompt Injection en tête des risques LLM (LLM01).
Dans un système agentique, l’injection devient critique parce que l’agent peut :
● lire une instruction cachée (dans un email, PDF, page web…),
● l’interpréter comme prioritaire,
● et agir (exfiltrer, modifier, déclencher une action).
Côté recherche, plusieurs travaux récents montrent la diversité des attaques et défenses pour des workflows d’agents LLM (survey / taxonomies / mitigations).
2) Sur-autonomisation de l’agent : droits d’accès trop étendus
Un agent qui a “le droit de tout faire” devient un super-compte. C’est un risque explicitement discuté dans des guides de sécurité GenAI (OWASP) et dans les débats actuels autour des architectures d’agents.
3) Compromission de la chaîne d’approvisionnement des outils (connecteurs, plugins, API)
Dès lors qu’un agent IA s’appuie sur des outils externes (plugins, API, connecteurs, scripts, serveurs MCP, etc.), il hérite mécaniquement des risques de chaîne d’approvisionnement. Une vulnérabilité ou une manipulation sur un seul maillon peut suffire à détourner le comportement de l’agent.
Les scénarios typiques incluent notamment :
● outil ou connecteur compromis (bibliothèque, plugin ou service tiers altéré),
● spécification/description d’outil falsifiée (paramètres, fonctions ou “prompts” d’outil orientés),
● détournement d’action (appel API modifié, commande rejouée, cible changée),
● exfiltration de données via un connecteur (transfert non maîtrisé vers un service tiers).
4) Exfiltration discrète de données
Même sans “piratage”, l’agent peut exposer :
● secrets (API keys),
● données perso (RH, clients),
● code source,
● documents stratégiques.
Les rapports Harmonic Security et Netskope montrent que l’exposition de données via les outils GenAI est déjà mesurable et récurrente dans les organisations, ce qui confirme un risque opérationnel à grande échelle.
5) Observabilité et responsabilité
Quand un agent agit, il faut pouvoir répondre à :
● qui a décidé ?
● quoi a été lu ?
● quelles actions ont été tentées ?
● quelles validations humaines ont eu lieu ?
● quelles preuves pour un audit / incident response ?
Pourquoi on parle d’un futur “ISO-like” ?
Quand le NIST consulte et structure, on observe souvent le même effet :
1. publication d’un cadre,
2. adoption par les grandes organisations,
3. exigences contractuelles,
4. audits, checklists, mapping vers d’autres référentiels.
Ici, le terrain est déjà prêt :
● NIST AI RMF (gestion des risques IA)
● initiatives NIST autour d’un profil cyber pour l’IA (Cyber AI Profile, draft)
● référentiels sécurité GenAI comme OWASP Top 10 LLM
● base de connaissance offensive MITRE ATLAS pour mapper tactiques/techniques.
-> Résultat attendu côté entreprises : des exigences “normalisées” de type contrôles + preuves + audits pour tout agent IA en production.
|Pour structurer cette gouvernance, les organisations s’appuient de plus en plus sur ISO/IEC 42001, la norme dédiée au management de l’IA : en mise en œuvre (Lead Implementer) comme en évaluation et audit (Lead Auditor)
Exemple d’architecture de contrôle : filtrage des actions et limitation des sources
Google a publié une approche défensive pour des agents dans le navigateur : un mécanisme de contrôle d’alignement (“Alignment Critic”) + des restrictions de sources (“Agent Origin Sets”) pour limiter ce que l’agent peut lire/écrire selon les origines pertinentes à la tâche.
Même si ce n’est pas “la solution universelle”, ça illustre une tendance :
✅ séparer le modèle “planificateur” d’un système de contrôle,
✅ réduire l’exposition aux contenus non fiables,
✅ forcer des validations et une traçabilité.
FAQ — Sécurité des agents IA (agentic AI)
1) C’est quoi un “agent IA” exactement ?
Un agent IA est un système qui ne se contente pas de répondre : il peut planifier une tâche et agir via des outils (API, navigateur, scripts, SaaS), donc déclencher des actions réelles (créer/modifier/supprimer, envoyer, déployer, configurer).
2) Pourquoi le NIST a ouvert une consultation en janvier 2026 ?
Parce que l’agentic AI arrive vite en entreprise, et le NIST veut éviter un déploiement “à l’aveugle” : il collecte des retours sur les risques, les contrôles et la mesure (évaluation, audit, assurance) pour bâtir un cadre pratique.
3) Pourquoi la “prompt injection” devient plus dangereuse avec un agent ?
Avec un agent, une instruction piégée (dans un email, un PDF, une page web…) peut pousser l’IA à exécuter une action : exfiltrer des données, changer une config, envoyer un message, ouvrir un accès. C’est un risque central identifié dans les référentiels de sécurité LLM.
4) Quels sont les risques principaux spécifiques aux agents ?
● Trop de droits (excessive agency) : l’agent a des permissions trop larges.
● Abus d’outils / supply chain : connecteurs, plugins, API, outils compromis ou détournés.
● Fuite de données : prompts, fichiers, secrets, PII.
● Manque de traçabilité : impossible de prouver “qui a fait quoi”, donc compliqué pour l’audit.
5) Comment auditer un agent IA (preuves attendues) ?
Un audit crédible cherche des preuves : inventaire agent/modèle/outils, politique d’usage, matrice d’accès, logs exploitables, procédures d’escalade, cas de tests (prompt injection/tool abuse), et un processus de revue périodique (droits, modèles, connecteurs).
6) Est-ce qu’il existe déjà des approches défensives “concrètes” ?
Oui : par exemple des mécanismes de contrôle séparés du modèle (type “critic/gating”) et des restrictions sur les contenus/“origines” qu’un agent peut exploiter en navigation, pour réduire le risque d’injection et d’actions non prévues.
Conclusion
La consultation NIST est un signal : les agents IA vont devenir un objet de gouvernance cybersécurité à part entière. Dès maintenant, les organisations qui veulent adopter l’agentic AI “proprement” devraient :
● traiter tout agent comme un compte à privilèges,
● imposer least privilege + validations + logs,
● tester les scénarios prompt injection / tool abuse comme on testait SQLi/XSS au début du web,
● préparer des preuves auditables (inventaire, contrôles, monitoring, revues).
Et pour ceux qui font de la conformité (NIS2, ISO 27001, ISO 42001), ce sujet va vite devenir un chapitre obligatoire : contrôles + traçabilité + gestion des risques IA.
