Les recommandations fédérales sur les incidents liés à l’IA placent la preuve au premier plan

La première question à se poser lorsqu’un agent IA agit de façon inattendue n’est pas « qui est responsable », mais « que pouvez-vous prouver ? ». La plupart des organisations ne peuvent pas y répondre clairement, et les nouvelles recommandations fédérales sur la gestion des incidents IA s’articulent précisément autour de cette faiblesse.

Le NIST, la NSA et la CISA ont publié un document commun, Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation, le 16 octobre 2026, comme l’a rapporté ComplexDiscovery. Il présente 10 bonnes pratiques volontaires réparties en cinq étapes (préparer, détecter, répondre, restaurer et signaler), et s’appuie sur le NIST CSF 2.0 et le NIST SP 800-61 Révision 3. Les auteurs sont le Center for Advancing Innovation and Standards for Super Intelligence du NIST, le Super Intelligence Security Center de la NSA et la CISA. Le public visé est constitué du petit nombre de laboratoires qui entraînent et évaluent des modèles très performants.

Si vous gérez la sécurité ou la conformité dans une entreprise qui déploie des agents IA sans développer de modèles de pointe, il peut être tentant de considérer que cela ne vous concerne pas. Ce serait une erreur. Le document est court, général et explicitement volontaire, et précise que ses pratiques peuvent également s’appliquer aux déployeurs de ces agents. Plus important encore, les questions qu’il pose (qu’a fait l’agent, à quoi a-t-il accédé, pouvez-vous le reconstituer, votre nettoyage a-t-il détruit la preuve) sont celles que vos régulateurs, assureurs et juristes vous poseront lors de votre premier incident impliquant un agent IA.

Points clés à retenir

1. La preuve est considérée comme un contrôle.

Les recommandations demandent aux organisations de conserver les poids des modèles, les points de contrôle intermédiaires, les appels d’outils, les actions rejetées et l’état de l’environnement afin de pouvoir enquêter sur un incident et le reproduire.

2. Les recommandations sont volontaires et générales.

Le document précise qu’il s’agit d’informations à titre indicatif et non de conseils juridiques ou de conformité. Il ne certifie rien et n’engage personne.

3. La durée de conservation et la séquence restent ouvertes.

Le document ne fixe aucune durée de conservation et n’exige pas clairement que la collecte des preuves soit terminée avant la reconstruction d’un environnement compromis.

4. Les déployeurs héritent des mêmes questions sur la preuve.

Une entreprise qui utilise des agents sur des données sensibles fait face au même problème de reconstruction, même si le document s’adresse d’abord aux développeurs de modèles de pointe.

5. La démarche pragmatique consiste à gouverner l’accès au niveau des données.

Limiter ce qu’un agent peut atteindre et enregistrer chaque accès dans un journal d’audit unique permet de rendre le reste des recommandations réalisable.

Ce que disent réellement les recommandations

Commencez par la définition, car elle conditionne tout le reste. Le texte principal est disponible sur le site du NIST, et la CISA héberge une copie de la ressource. Le document définit un « incident de contrôle » comme une situation où un agent IA effectue des actions non instruites majeures qui compromettent les règles, contrôles ou la supervision humaine définissant sa mission. Le caractère « non instruit » est ici central. Selon l’analyse de ComplexDiscovery, les actions résultant d’une injection de prompt ou d’un modèle piégé sont considérées comme instruites, et donc hors du champ principal de la définition. C’est une approche plus restrictive que celle adoptée par la plupart des équipes de cybersécurité en entreprise, et il est utile de le savoir avant de transposer ces recommandations à votre propre gestion des risques.

Le deuxième concept est celui du quasi-incident (« near-miss »). Les recommandations le définissent comme un événement qui n’a pas abouti à un incident mais présentait un risque raisonnablement prévisible ou imminent d’en devenir un, et considèrent les quasi-incidents comme des déclencheurs potentiels d’une réponse rapide. Toute personne ayant travaillé dans l’aviation ou la santé reconnaîtra cette logique. L’événement qui a failli se produire est facile à étudier et coûteux à ignorer. Dans un programme de sécurité classique, un quasi-incident est un ticket clos parce que rien de grave ne s’est produit.

Les cinq étapes sont familières à toute personne ayant déjà mis en place un plan de réponse aux incidents. Préparer couvre les protections techniques, les autorisations restreintes des agents, les mécanismes d’arrêt d’urgence et la formation des équipes. Détecter concerne la surveillance des systèmes, interfaces et réseaux, pas seulement du modèle. Répondre inclut la définition du périmètre, le confinement et la conservation des preuves. Restaurer consiste à vérifier que le confinement a fonctionné avant de redémarrer un agent, en s’assurant que la surveillance, la journalisation, les restrictions d’accès et les mécanismes d’arrêt sont opérationnels. Signaler implique d’informer les parties concernées, de respecter les obligations de notification applicables et de partager volontairement avec les autorités ou, le cas échéant, le public.

Le langage des contrôles vous semblera également familier. Les recommandations précisent que les agents ne doivent accéder qu’aux informations, systèmes et outils nécessaires à leur mission, et CPO Magazine ajoute à la liste des contrôles de bon sens l’infrastructure à usage unique et les restrictions sur la façon dont les agents communiquent entre eux. Rien d’exotique ici. Il s’agit du principe du moindre privilège, d’environnements éphémères et de segmentation appliqués à un nouvel acteur. La nouveauté réside dans l’hypothèse sous-jacente : l’acteur peut se comporter de façon imprévue, donc l’environnement doit être conçu pour le contenir et garder la mémoire de ses actions.

Pourquoi la conservation des preuves est centrale

Parmi les 10 pratiques, celle qui a le plus d’impact opérationnel pour un responsable conformité est la gestion des preuves. L’étape Répondre demande de conserver les poids des modèles ainsi que les environnements d’entraînement, d’évaluation et de déploiement dans la mesure nécessaire pour enquêter sur un incident. Selon les détails rapportés par ComplexDiscovery, cela inclut les points de contrôle intermédiaires, les horodatages, les journaux de sandbox et de réseau, les actions rejetées, les appels d’outils et la configuration permettant de reproduire ce qui s’est passé. Il est aussi question de journaux infalsifiables avec des horodatages fiables retraçant les trajectoires des agents, les appels d’outils, les interactions utilisateurs, les états de l’environnement et les décisions de sécurité.

Lisez cette liste comme le ferait un auditeur. Il s’agit d’un dossier de preuves, pas d’une simple liste de surveillance. L’expression « actions rejetées » mérite une attention particulière, car la plupart des programmes de journalisation enregistrent ce qui s’est passé, mais pas ce que l’agent a tenté de faire et qui a été bloqué. C’est souvent là que se situe le quasi-incident.

Le même principe s’applique à vos propres déploiements, même si vous ne manipulez jamais les poids de modèles. Les éléments équivalents pour une entreprise sont les prompts et instructions reçus par l’agent, l’identité sous laquelle il agit, les fichiers et enregistrements ouverts, les outils utilisés et les décisions de politique ayant autorisé ou refusé chaque étape. Si ces éléments sont répartis dans cinq systèmes différents avec des règles de conservation distinctes, la reconstruction devient un projet d’investigation plutôt qu’une simple requête. Un journal d’audit bien géré, qui capture l’activité humaine et celle des agents au même endroit, fait toute la différence.

Un point essentiel sur la confiance se perd parfois dans les détails techniques. Une preuve n’a de valeur que si un tiers peut s’y fier. C’est pourquoi les recommandations insistent sur la résistance à la falsification et des horodatages fiables, et que la notion de chaîne de traçabilité est centrale. Un journal que vos propres administrateurs peuvent modifier sera remis en cause par la partie adverse.

Les lacunes à relever pour un RSSI ou un CCO

Un document volontaire d’une quinzaine de pages ne peut pas répondre à toutes les questions opérationnelles, et les commentaires à son sujet l’ont rapidement souligné. Quatre lacunes ressortent pour un responsable sécurité ou conformité.

Pas de durée de conservation définie

Les recommandations préconisent de conserver les preuves aussi longtemps que nécessaire pour enquêter, mais ne précisent aucune durée. Pour un laboratoire de pointe, cela peut se justifier, car le volume de données est énorme et la bonne réponse dépend de l’incident. Pour une entreprise régulée, cela laisse un vide. Votre politique de conservation des traces d’agents IA dépendra des règles sectorielles, des contrats et du risque juridique, pas de ce document. Si vos journaux d’agents sont écrasés tous les 30 jours et qu’un régulateur demande un événement datant de 90 jours, ces recommandations ne vous aideront pas.

Collecte versus reconstruction

L’étape Restaurer inclut la reconstruction à partir de bases vérifiées et la révocation des identifiants compromis lors d’un incident. L’étape Répondre inclut la conservation des preuves. Ces deux instructions peuvent entrer en conflit. Si une équipe reconstruit un environnement compromis avant d’avoir collecté et hashé les preuves, la reconstruction détruit l’historique. Le document précise que les pratiques s’appliquent tout au long du cycle de vie, mais ne détaille pas l’ordre des opérations, et l’analyse de ComplexDiscovery recommande de prendre un instantané et de hasher avant toute reconstruction. Inscrivez cette séquence dans votre runbook, en termes simples. Découvrir ce conflit au cœur d’un incident n’est jamais une bonne idée.

La question juridique n’est pas abordée

Le document ne traite pas des obligations de conservation légale. Cela se comprend vu le public visé, mais cela signifie que le service juridique doit compléter ce volet. Dès qu’un incident d’agent crée une perspective raisonnable de contentieux, la conservation des preuves devient une obligation légale. Votre processus eDiscovery doit savoir que les transcriptions d’agents, journaux d’appels d’outils et décisions de politique sont des éléments à conserver, et pouvoir les bloquer sans arrêter toute la flotte d’agents.

Évaluer la gravité des quasi-incidents est plus difficile que de les nommer

Les recommandations demandent d’attribuer un niveau de gravité et considèrent les quasi-incidents comme des déclencheurs. Ni l’un ni l’autre n’est simple. Attribuer une gravité à un agent qui a failli envoyer un fichier sensible à la mauvaise destination suppose d’avoir défini une grille d’évaluation en amont. Sinon, le premier quasi-incident devient un débat sur sa qualification. La solution pragmatique consiste à adopter dès maintenant une échelle de gravité courte, avec des exemples issus de vos propres cas d’usage, et à organiser un exercice de simulation.

Les commentaires ont aussi souligné que les outils de surveillance peuvent introduire leurs propres vulnérabilités et qu’identifier un incident lié à un agent malveillant est déjà complexe. Ce sont des mises en garde justifiées. Ce sont aussi des raisons de traiter ces recommandations comme une liste de contrôle de départ, et non comme un programme abouti.

Pourquoi les déployeurs sont confrontés aux mêmes questions

Les laboratoires de pointe et les entreprises se situent à des niveaux de risque différents, mais les schémas d’échec se ressemblent. Un agent reçoit un objectif, des identifiants et un accès aux données. Un élément du contexte, de l’environnement ou du comportement du modèle l’amène à sortir de son cadre. Quelqu’un doit alors expliquer à la direction, au régulateur ou au client ce qui s’est passé.

Les enquêtes montrent que la plupart des organisations ne sont pas prêtes pour ce type d’échange. Le rapport 2026 State of AI Governance de Schellman, basé sur 525 professionnels américains dans des entreprises de plus de 500 salariés, révèle que seulement 22 % ont défini des seuils pour exiger une revue humaine du travail d’un agent, selon le whitepaper Schellman 2026 State of AI Governance. Ce seuil est indispensable à un programme de quasi-incidents. Si personne n’a défini ce qu’un agent peut faire seul, personne ne peut dire quand il a dépassé la limite.

La confiance dans les audits va dans le même sens. L’AI Impact Survey 2026 de Grant Thornton, menée auprès de 950 dirigeants, montre que 78 % n’ont pas confiance dans leur capacité à réussir un audit indépendant de gouvernance IA sous 90 jours, selon la page du sondage Grant Thornton. Les auditeurs ne demandent pas si vous avez une politique, ils demandent la preuve. Les recommandations fédérales sont, en pratique, une déclaration de trois agences sur ce à quoi doit ressembler un dossier crédible quand l’acteur est un agent IA.

La question de la responsabilité est le troisième point. Une enquête menée par Gravitee auprès de cadres et responsables techniques, résumée dans son State of AI Agent Security 2026 report, indique qu’environ 7 % seulement ont désigné une personne responsable du comportement des agents. Ce chiffre, issu d’une enquête fournisseur, doit être pris avec recul, mais la tendance est claire. Lorsqu’un incident survient, le responsable des opérations doit avoir un interlocuteur métier qui détient la mission et les autorisations de l’agent.

Aucune de ces trois sources n’évalue directement les recommandations fédérales, et aucune ne prouve que les organisations échoueront lors d’un incident IA. Ensemble, elles suggèrent que les prérequis pour une bonne réponse (seuils définis, dossiers prêts pour l’audit, responsables nommés) manquent dans la plupart des entreprises. C’est là la vraie valeur de ces recommandations pour un déployeur : elles fournissent une référence neutre à présenter pour obtenir un budget.

Transformer les recommandations en programme opérationnel

Vous n’avez pas besoin d’adopter les 10 pratiques pour en tirer profit. L’approche pragmatique consiste à traduire les cinq étapes en décisions concrètes à prendre ce trimestre.

Préparer : définir l’acteur et le périmètre d’action

Commencez par un inventaire. Listez chaque agent IA en production ou en test, l’identité qu’il utilise, les données auxquelles il a accès et la personne qui en est responsable. Appliquez ensuite le principe du moindre privilège, explicitement cité dans les recommandations. Un agent qui rédige des synthèses clients n’a pas besoin d’un accès en écriture au référentiel des contrats. Des contrôles d’accès stricts sur les données elles-mêmes, et pas seulement sur l’application, évitent qu’un agent défaillant ne provoque une fuite de données.

C’est aussi ici que les principes de sécurité zero trust prennent tout leur sens. Considérez l’agent comme un acteur à vérifier à chaque requête, limité à sa mission et refusé par défaut. L’exigence d’un mécanisme d’arrêt d’urgence fait aussi partie de cette étape. Si vous ne pouvez pas révoquer l’accès d’un agent en quelques minutes, vous n’avez pas de mécanisme d’arrêt, juste un espoir.

Détecter : surveiller les données, pas seulement le modèle

Les recommandations précisent que la surveillance doit couvrir systèmes, interfaces logicielles et réseaux, pas uniquement le modèle. Pour la plupart des entreprises, le signal le plus utile est l’accès aux données. Quels fichiers cet agent a-t-il ouverts, combien, depuis quelles sources, et ce comportement correspond-il à sa mission ? Intégrer ces événements à votre SIEM donne à l’équipe sécurité des alertes concrètes, et évite de devoir gérer une pile de surveillance spécifique aux agents, rarement bien suivie.

Répondre : capturer d’abord, puis contenir et reconstruire

Inscrivez l’ordre « capturer avant de reconstruire » dans votre runbook. Prenez un instantané de l’environnement, exportez les journaux, hashez-les, consignez qui les a manipulés, puis seulement révoquez les identifiants et reconstruisez. Reliez cela à votre analyse des risques pour que l’équipe sache quels agents nécessitent une capture complète et lesquels peuvent faire l’objet d’une procédure allégée. Tous les incidents ne méritent pas la même profondeur, mais la décision doit être prise à l’avance, pas dans l’urgence.

Restaurer : prouver la correction avant de redémarrer

Les recommandations demandent de vérifier que la surveillance, la journalisation, les restrictions d’accès et les mécanismes d’arrêt fonctionnent avant de redémarrer un agent. Formalisez cela dans une liste de contrôle avec un valideur nommé. C’est l’étape souvent négligée sous la pression métier, car l’agent soutient un processus en production et tout le monde veut le relancer. Une validation signée est une assurance à faible coût.

Signaler : décider qui informe qui, et quand

Le reporting selon ces recommandations reste volontaire, sauf obligations légales existantes. L’enjeu pour l’entreprise est donc d’identifier les obligations applicables. Les règles sectorielles, clauses contractuelles et lois de notification s’imposent toujours. Décidez à l’avance qui communique avec les clients, qui avec les régulateurs, et qui décide d’un partage avec la CISA ou un groupe professionnel. Alignez cela avec la fonction Gouverner du NIST CSF 2.0, qui attend de la direction qu’elle assume la stratégie et la responsabilité du risque cyber, sans la déléguer au SOC.

La gouvernance au niveau des données : quelle place ?

Aucun produit ne répond à lui seul à ces recommandations. Elles ne certifient rien, et aucun fournisseur ne peut revendiquer la conformité. Une entreprise peut en revanche examiner les preuves demandées et se demander lesquelles peuvent être produites de façon fiable à partir d’un seul endroit.

La plateforme d’échange sécurisé de données Kiteworks aborde le sujet au niveau des données. Plutôt que de s’appuyer sur chaque application ou framework d’agent pour enregistrer son comportement, la plateforme applique la politique là où se trouvent les contenus sensibles et consigne chaque accès dans un ensemble unique de journaux d’audit. Le moteur de politique de données évalue qui ou quoi fait la demande, ce qui est demandé, et si la politique l’autorise. Le Serveur MCP Sécurisé place les assistants et agents IA connectés via MCP sous la même politique, de sorte que l’accès d’un agent à des contenus sensibles obéit aux mêmes règles et laisse la même trace qu’un utilisateur humain.

Cette approche recoupe deux axes des recommandations sans prétendre les couvrir totalement. Limiter l’accès d’un agent à ce dont il a besoin relève d’une décision de politique appliquée au point d’accès. Conserver une trace exploitable de l’activité d’un agent découle de la même logique, car les décisions d’autorisation ou de refus sont consignées là où se trouve le contenu. Le résultat : une piste de preuves qu’un CCO peut présenter à un auditeur et qu’un RSSI peut interroger lors d’un incident, construite au niveau de la gouvernance plutôt que reconstituée a posteriori.

Cette approche a ses limites, qu’il faut expliciter. Les contrôles au niveau des données ne conservent pas les poids de modèles, les environnements d’entraînement ou la logique interne d’un modèle que vous exploitez vous-même. Ils répondent à la question que la plupart des entreprises se posent : qu’a fait l’agent avec les contenus sensibles auxquels il a eu accès. Les organisations qui entraînent ou affinent leurs propres modèles devront prévoir des mécanismes de capture supplémentaires pour ces éléments.

La même gouvernance s’applique à l’accès humain et agent. Traiter les agents comme une catégorie à part avec un règlement distinct crée le problème des deux vitesses, souvent mis en lumière lors des audits. Une approche unique de gouvernance des données IA, où les règles sont attachées aux données et l’acteur n’est qu’une identité à vérifier, est plus simple à expliquer et à défendre.

Plan d’action sur 90 jours pour les responsables sécurité et conformité

Des recommandations sans échéance tendent à être repoussées. Voici une séquence réalisable en un trimestre, sans budget supplémentaire.

Dans les 30 premiers jours, dressez l’inventaire des agents et nommez un responsable pour chacun. Vérifiez les identités utilisées par les agents et si elles sont limitées à leurs tâches. Passez en revue les paramètres de conservation de chaque système enregistrant l’activité des agents et notez la durée la plus courte. C’est votre durée de conservation réelle, quelle que soit votre politique officielle.

Entre le 31e et le 60e jour, définissez une échelle de gravité simple pour les incidents et quasi-incidents d’agents, avec trois ou quatre exemples issus de vos propres cas d’usage. Inscrivez la séquence « capturer avant de reconstruire » dans le runbook d’incident, et impliquez le service juridique pour que la procédure de conservation couvre les transcriptions d’agents et les journaux d’appels d’outils. Décidez qui peut arrêter un agent et testez la procédure.

Entre le 61e et le 90e jour, organisez un exercice de simulation autour d’un quasi-incident. Choisissez un scénario où un agent récupère un contenu auquel il n’aurait pas dû accéder, ou tente une action bloquée par la politique. Faites passer l’équipe par la détection, la collecte de preuves, la définition du périmètre et le reporting. Chronométrez l’exercice, notez les manques, et présentez les écarts au prochain comité des risques, accompagnés des résultats d’enquête cités plus haut. Si l’exercice révèle que vous ne pouvez pas reconstituer les actions de l’agent, vous avez votre argument budgétaire.

Gardez un ton pragmatique lors de l’exercice. L’objectif n’est pas de chercher des coupables, mais d’apprendre, avant le vrai incident, quels dossiers existent, qui peut y accéder et combien de temps prend la reconstruction. Les équipes qui l’ont déjà fait constatent que la première heure d’un incident se passe bien mieux la deuxième fois.

Ce qu’il faut surveiller à l’avenir

Trois évolutions méritent l’attention. La première est de voir si les recommandations évolueront au-delà de leur forme actuelle, courte et générale. Les commentaires ont déjà souligné l’absence de consignes sur la durée de conservation et le traitement succinct des déployeurs, qu’une future version pourrait corriger. La deuxième concerne la façon dont les régulateurs sectoriels et les auditeurs s’en inspireront. Les bonnes pratiques fédérales volontaires deviennent souvent la référence utilisée par les évaluateurs lorsqu’aucune norme n’existe, même si ce n’était pas l’intention initiale. La troisième est la réaction des assureurs. Si les souscripteurs commencent à demander si vous conservez les preuves des agents, ces recommandations passeront de facultatives à attendues, sans qu’aucune règle n’ait été écrite.

Pour l’instant, considérez ce document pour ce qu’il est : un cadre crédible, émanant de trois agences, sur ce à quoi doit ressembler un dossier défendable lors d’un incident IA. Il ne vous dit pas quoi acheter ni quelle durée de conservation choisir. Il vous indique les questions auxquelles vous devrez répondre, et vous laisse le temps de préparer vos réponses.

Découvrez comment fonctionne l’accès gouverné à l’IA en pratique

Si vous souhaitez voir comment la plateforme d’échange sécurisé de données Kiteworks applique la politique sur l’accès des agents et des humains aux contenus sensibles et consigne chaque accès dans un journal d’audit unique, réservez votre démo personnalisée dès aujourd’hui.

Ressources complémentaires

• Article de blog
  Stratégies Zero Trust pour une protection abordable de la vie privée avec l’IA
• Article de blog
  Comment 77 % des organisations échouent à sécuriser les données IA
• eBook
  L’écart de gouvernance IA : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025
• Article de blog
  Il n’existe pas de « –dangerously-skip-permissions » pour vos données
• Article de blog
  Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent des preuves qu’elle fonctionne.