NIST 800-171, CUI et IA : Ce qui manque à votre plan de sécurité système

Des milliers d’organisations traitent des informations non classifiées contrôlées (CUI) dans le cadre de contrats gouvernementaux sans être engagées dans le processus de certification CMMC. Les sous-traitants fédéraux, universités de recherche, agences d’État, fournisseurs technologiques et cabinets de services professionnels qui reçoivent des CUI selon la clause DFARS 252.204-7012 doivent mettre en œuvre les 110 pratiques de sécurité du NIST SP 800-171 et documenter cette mise en œuvre dans un plan de sécurité du système (SSP). La plupart l’ont fait pour l’accès des utilisateurs humains aux CUI. Presque aucune ne l’a fait pour l’accès des agents IA.

Ce manque n’est pas théorique. Les agents IA sont déployés dans des organisations soumises au DFARS pour la rédaction de propositions, la documentation technique, l’administration des contrats et la gestion de la supply chain — autant d’activités qui impliquent régulièrement des CUI. Ces déploiements ne sont pas couverts par les SSP existants. Ils ne sont pas pris en compte dans les évaluations des risques. Ils ne sont pas abordés dans les règles de contrôle des accès. Et ils ne produisent pas les journaux d’audit exigés par les pratiques d’audit et de responsabilité du NIST 800-171 pour les événements d’accès aux CUI.

Cet article se distingue de celui consacré au CMMC dans cette série, qui porte sur le processus d’évaluation C3PAO pour les sous-traitants du secteur de la défense visant la certification. Ici, nous nous adressons à un public plus large : toutes les organisations qui gèrent des CUI dans le cadre de contrats DFARS mais ne sont pas engagées dans la démarche de certification CMMC — et dont les obligations de conformité NIST 800-171 s’appliquent à l’accès des agents IA aux CUI, indépendamment du statut de certification.

Résumé Exécutif

Idée principale : Les 110 pratiques de sécurité du NIST 800-171 s’appliquent à tout système qui traite, stocke ou transmet des CUI — y compris les agents IA. Les organisations qui ont mis en œuvre les contrôles 800-171 pour l’accès des utilisateurs humains aux CUI, mais ne les ont pas étendus aux workflows des agents IA, présentent un écart de conformité significatif dans leur plan de sécurité du système. Cet écart constitue une non-conformité contractuelle DFARS, une exposition potentielle à la loi False Claims Act, et une vulnérabilité dans leur posture de cybersécurité que les adversaires ciblant la supply chain gouvernementale savent exploiter.

Pourquoi c’est important : La clause DFARS 252.204-7012 impose aux sous-traitants de répercuter la conformité NIST 800-171 sur leurs propres sous-traitants et prestataires qui traitent des CUI pour leur compte. Les fournisseurs IA dont l’infrastructure traite des CUI — même de façon transitoire lors d’une inférence de modèle — font partie de cette chaîne de sous-traitance. Une organisation incapable de démontrer des contrôles d’accès et des pistes d’audit conformes au NIST 800-171 pour l’accès des agents IA aux CUI n’est pas conforme aux termes de son contrat DFARS — que l’évaluation CMMC soit en cours ou non.

Résumé des Points Clés

1. Les obligations de conformité NIST 800-171 découlent des contrats DFARS, pas de la certification CMMC. Toute organisation opérant sous la clause DFARS 252.204-7012 doit mettre en œuvre les 110 pratiques du NIST 800-171 pour les systèmes qui traitent des CUI. Cette obligation existe indépendamment de la CMMC. Les organisations qui gèrent des CUI mais ne sont pas encore engagées dans la démarche de certification CMMC ne sont pas exemptées du 800-171 — elles attestent simplement elles-mêmes de leur conformité au lieu de passer par une évaluation tierce.
2. Tout agent IA manipulant des CUI est un composant du système qui doit figurer dans le SSP. Le plan de sécurité du système doit décrire tous les systèmes et composants qui traitent, stockent ou transmettent des CUI, ainsi que les contrôles de sécurité qui les protègent. Un SSP qui détaille les contrôles pour les postes de travail, serveurs et systèmes de messagerie mais ne mentionne pas les agents IA accédant aux dépôts de CUI est un SSP incomplet — et un SSP incomplet constitue en soi un constat de non-conformité 800-171.
3. La révision 3 du NIST 800-171 a renforcé les exigences d’accès et d’audit auxquelles les déploiements IA doivent répondre. La révision 2024 du NIST 800-171 a introduit des exigences accrues en matière de granularité des contrôles d’accès, de détail des journaux d’audit et de gestion des risques liés à la supply chain. Ces évolutions rendent les architectures IA existantes — qui offrent généralement une authentification au niveau de la session et des logs au niveau de l’infrastructure — encore moins adaptées à la conformité 800-171 qu’elles ne l’étaient sous la révision 2.
4. L’obligation de répercussion DFARS étend les exigences NIST 800-171 aux fournisseurs IA. Selon la clause DFARS 252.204-7012, les sous-traitants doivent répercuter les exigences de conformité 800-171 sur les sous-traitants et prestataires qui traitent des CUI pour leur compte. Un fournisseur IA dont l’infrastructure traite des CUI lors d’une inférence de modèle est un sous-traitant ou prestataire concerné. Le sous-traitant principal ne peut pas se contenter des attestations générales de sécurité du fournisseur — ce dernier doit satisfaire aux exigences 800-171 pour la gestion des CUI, et le sous-traitant principal doit le documenter dans son programme de gestion des risques fournisseurs.
5. L’exposition à la False Claims Act est un risque majeur pour les organisations dont l’auto-évaluation NIST 800-171 est inexacte. Le Department of Justice a engagé des poursuites sur la base de la False Claims Act contre des sous-traitants gouvernementaux ayant soumis des auto-évaluations NIST 800-171 inexactes. Une organisation qui atteste de sa conformité au 800-171 tout en utilisant des agents IA sur des CUI sans les contrôles d’accès et pistes d’audit requis soumet potentiellement une certification erronée — avec un risque FCA qui s’étend aux dirigeants individuels.

NIST 800-171 et le SSP : Ce que les Déploiements IA Doivent Couvrir

Le NIST 800-171 organise ses 110 pratiques de sécurité en 14 familles de contrôles. Trois sont directement concernées lorsque des agents IA accèdent à des CUI : Contrôle d’accès (3.1), Audit et responsabilité (3.3), et Identification et authentification (3.5). Une quatrième — Gestion de la configuration (3.4) — devient pertinente lorsque des composants agents IA font partie du périmètre du système. Chacune de ces familles comporte des pratiques spécifiques que le SSP doit traiter, et auxquelles les déploiements d’agents IA doivent répondre pour que l’organisation soit conforme à ses obligations DFARS.

Contrôle d’accès (3.1) : Accès autorisé et principe du minimum nécessaire

La pratique 3.1.1 impose de limiter l’accès aux CUI aux utilisateurs autorisés, aux processus agissant pour leur compte, et aux dispositifs. La pratique 3.1.2 impose de limiter l’accès aux types de transactions et fonctions que les utilisateurs autorisés sont habilités à exécuter. Pour les agents IA, ces deux pratiques établissent les mêmes exigences que les contrôles CMMC AC.1.001 et AC.2.006 : l’accès doit être authentifié, attribué à un individu autorisé, et limité au strict nécessaire pour la tâche. Un agent IA fonctionnant via un compte de service partagé avec un accès large aux dépôts de CUI ne satisfait à aucune de ces pratiques.

La pratique 3.1.3 impose de contrôler le flux des CUI conformément aux autorisations approuvées. Pour les agents IA, cela signifie que la couche de gouvernance doit empêcher les données contrôlées de circuler vers des destinations non autorisées — API externes, systèmes non couverts par le DFARS, ou infrastructures hors du périmètre CUI autorisé. Les prompts système ne peuvent pas garantir ce contrôle des flux ; seule une politique ABAC au niveau des données permet d’empêcher techniquement tout flux non autorisé de CUI, quel que soit l’instruction donnée au modèle.

Audit et responsabilité (3.3) : Ce que le journal doit contenir

La pratique 3.3.1 impose de créer et conserver des journaux d’audit système pour permettre la surveillance, l’analyse, l’investigation et le reporting des activités système illicites ou non autorisées. La pratique 3.3.2 impose de garantir l’identification des utilisateurs responsables des actions de leurs processus — y compris ceux agissant pour leur compte. Pour les agents IA, la 3.3.2 impose une chaîne de délégation : le journal d’audit doit enregistrer non seulement qu’un agent a réalisé une action, mais aussi l’identité de l’humain qui l’a autorisée et en est responsable.

Les logs d’infrastructure standard et les logs d’inférence IA enregistrent généralement l’action système réalisée, mais pas la personne responsable au sens de la 3.3.2. Une organisation dont la piste d’audit des agents IA ne consigne que les appels API d’un compte de service, sans relier ces appels à l’opérateur humain ayant délégué le workflow, ne peut satisfaire la pratique 3.3.2 pour ces accès CUI.

Identification et authentification (3.5) : Identification unique requise

La pratique 3.5.1 impose que les utilisateurs et dispositifs — et, de façon critique, les processus dont les agents IA — soient identifiés et authentifiés avant d’accéder aux systèmes de l’organisation et aux CUI. La pratique 3.5.2 impose d’authentifier les identités avant d’autoriser l’accès. Pour les agents IA, l’identification unique signifie que chaque agent doit disposer d’un identifiant distinct et vérifiable — et non d’un compte de service partagé dont l’identité est indifférenciée entre plusieurs agents, workflows ou événements d’accès.

Gestion des risques liés à la supply chain (3.16) : La dimension fournisseur IA

La révision 3 du NIST 800-171 a introduit des exigences explicites de gestion des risques supply chain dans la famille de pratiques 3.16. La pratique 3.16.1 impose d’établir et maintenir un plan de gestion des risques supply chain. Pour les organisations déployant des agents IA sur des CUI, la relation fournisseur IA est un risque supply chain à évaluer et documenter : comment le fournisseur protège-t-il les CUI lors de l’inférence de modèle, quelles sont ses obligations de notification d’incident, et respecte-t-il les exigences 800-171 pour les CUI traitées pour le compte du sous-traitant principal ?

L’écart SSP : Ce que la plupart des organisations oublient

Un SSP conforme au NIST 800-171 doit décrire le périmètre du système, tous les composants inclus, et les contrôles de sécurité protégeant les CUI sur l’ensemble des composants. Pour la majorité des organisations ayant déployé des agents IA, le SSP reflète une architecture antérieure à l’IA — et les composants agents IA sont totalement absents de la description du périmètre système.

Agents IA hors du périmètre défini du système

Si l’infrastructure agent IA n’est pas incluse dans la description du périmètre système, aucune des pratiques 800-171 ne s’y applique dans la posture de conformité documentée. Un auditeur qui compare le SSP aux opérations réelles identifiera les agents IA accédant aux CUI comme des composants hors périmètre — ce qui signifie que le score d’auto-évaluation ne les prend pas en compte, et que la certification DFARS de l’organisation est inexacte. Tout système traitant des CUI doit être inclus dans le périmètre ; tout système IA accédant à des CUI est un système traitant des CUI.

Évaluations des risques antérieures aux déploiements IA

La pratique 3.11.1 impose une évaluation périodique des risques liés aux opérations de l’organisation et au fonctionnement des systèmes CUI. La plupart des évaluations actuelles des organisations sont antérieures à leurs déploiements IA. Une évaluation qui ne prend pas en compte les agents IA désormais en accès aux CUI — leurs vulnérabilités, dépendances fournisseurs, périmètre d’accès et contrôles de gouvernance — n’est pas une évaluation des risques à jour au regard du 800-171.

Lacunes dans le plan d’action et de jalons (POA&M)

Dès qu’une organisation identifie des écarts de conformité 800-171 liés aux déploiements IA, ces écarts doivent être consignés dans un POA&M avec des échéances de remédiation. Identifier l’écart sans le documenter constitue en soi un problème de conformité : le 800-171 impose un suivi systématique des déficiences de contrôle de sécurité, pas seulement leur identification.

Bonnes pratiques pour un accès agent IA conforme au NIST 800-171 aux CUI

1. Intégrer les composants agents IA dans le plan de sécurité du système

Mettez à jour le SSP pour inclure tous les agents IA et leurs composants d’infrastructure dans la description du périmètre système. Pour chaque composant IA — couche d’orchestration, hébergement du modèle, base de données vectorielle, passerelle API — documentez les contrôles de sécurité en place, les CUI traitées et le statut de mise en œuvre des pratiques. Ce n’est pas optionnel : un SSP qui ne reflète pas les déploiements IA actuels est inexact, et un SSP inexact constitue un constat de non-conformité 800-171. Cette mise à jour doit précéder tout déploiement IA supplémentaire sur des CUI.

2. Mettre en œuvre une identité agent authentifiée avec préservation de la chaîne de délégation

Chaque agent IA accédant à des CUI doit opérer avec un identifiant unique au niveau du workflow, lié à l’opérateur humain responsable de ce workflow selon la pratique 3.3.2. Ce justificatif d’identité doit être distinct pour chaque agent et chaque workflow — les comptes de service partagés ne satisfont pas aux pratiques 3.5.1 ni 3.3.2. La chaîne de délégation (opérateur humain → identité agent → événement d’accès CUI) doit être consignée dans chaque entrée de journal d’audit, assurant l’attribution de responsabilité exigée par le 800-171.

3. Appliquer un contrôle d’accès CUI au niveau opérationnel via ABAC

Mettez en œuvre une politique ABAC qui évalue chaque demande d’accès CUI d’un agent IA selon le profil authentifié de l’agent, la classification CUI des données demandées, le contexte du workflow et l’opération spécifique. Cela répond aux pratiques 3.1.1 (accès autorisé) et 3.1.2 (périmètre minimum nécessaire) au niveau opérationnel. Un agent autorisé à lire un dossier de contrat ne peut pas télécharger tous les fichiers, ni accéder à des dépôts CUI adjacents, ni effectuer des opérations hors de son périmètre autorisé — avec une application au niveau des données, et non du modèle.

4. Générer des journaux d’audit au niveau opérationnel avec attribution de responsabilité humaine

Toute interaction agent IA/CUI doit être enregistrée dans un journal infalsifiable répondant aux pratiques 3.3.1 et 3.3.2 : identité de l’agent, opérateur humain responsable de l’action, CUI concernée, opération réalisée, et horodatage. Ces journaux doivent permettre la surveillance et l’investigation des accès non autorisés, et être conservés selon la politique de gestion documentaire de l’organisation. Les logs d’infrastructure standard et d’inférence ne suffisent pas à répondre aux exigences d’audit 800-171 sans détail complet au niveau opérationnel et attribution humaine.

5. Évaluer et documenter la gestion des CUI par les fournisseurs IA dans le programme de gestion des risques supply chain

Pour chaque fournisseur IA dont l’infrastructure traite des CUI pour le compte de l’organisation, réalisez une évaluation de gestion des risques fournisseurs spécifique au DFARS : évaluez si le fournisseur répond aux exigences 800-171 pour la gestion des CUI, documentez cette évaluation, et répercutez contractuellement les exigences 800-171. Mettez à jour le plan de gestion des risques supply chain selon la pratique 3.16.1 pour refléter les relations fournisseurs IA. Actualisez le POA&M avec tout écart identifié. Un fournisseur IA traitant des CUI sans conformité 800-171 documentée constitue une défaillance de répercussion DFARS qui impacte la conformité du sous-traitant principal.

Comment Kiteworks permet la gouvernance des agents IA conforme au NIST 800-171

Rendre l’accès agent IA aux CUI conforme au NIST 800-171 implique de mettre à jour simultanément trois éléments : le SSP pour inclure les composants IA dans le périmètre, les contrôles techniques pour gouverner l’accès agent IA aux CUI au niveau des données, et l’évaluation fournisseur pour confirmer que la plateforme de gouvernance IA elle-même répond aux exigences 800-171 pour la gestion des CUI. Le Réseau de données privé Kiteworks couvre ces trois aspects : il fournit l’infrastructure technique de gouvernance pour l’accès agent IA aux CUI, sert de composant système documentable dans le SSP avec des fonctions de conformité NIST 800-171, et soutient l’évaluation fournisseur exigée par la répercussion DFARS.

Identité authentifiée et chaîne de délégation pour les pratiques 3.5.1 et 3.3.2

Kiteworks authentifie chaque agent IA avant tout accès aux CUI, via un justificatif unique par workflow lié à l’opérateur humain responsable. La chaîne de délégation complète est consignée dans chaque entrée de journal d’audit. Cela répond à l’exigence d’identification unique de la pratique 3.5.1 et à l’attribution de responsabilité humaine de la pratique 3.3.2 — fournissant la documentation requise tant pour les déclarations de mise en œuvre des pratiques dans le SSP que pour les audits de conformité DFARS.

ABAC au niveau opérationnel pour les pratiques 3.1.1, 3.1.2 et 3.1.3

Le moteur de politique de données Kiteworks évalue chaque demande d’accès CUI d’un agent IA selon une politique multidimensionnelle : profil agent authentifié, classification CUI, contexte du workflow et opération spécifique. L’accès minimum nécessaire est appliqué au niveau opérationnel, et le flux CUI est contrôlé vers les seules destinations autorisées. Ces mécanismes répondent aux pratiques 3.1.1, 3.1.2 et 3.1.3 au niveau des données, indépendamment du comportement du modèle — ce qui en fait des mises en œuvre défendables en audit et documentables dans le SSP.

Piste d’audit infalsifiable pour les pratiques 3.3.1 et 3.3.2

Toute interaction agent IA/CUI est enregistrée dans un journal d’audit infalsifiable, au niveau opérationnel, alimentant directement le SIEM de l’organisation. Le journal consigne l’identité de l’agent, l’opérateur humain, les données CUI consultées, le type d’opération, le résultat de l’évaluation de la politique et l’horodatage — répondant aux pratiques 3.3.1 et 3.3.2 avec le niveau de détail opérationnel et l’attribution humaine exigés par le 800-171. Lorsqu’un audit de conformité DFARS exige une preuve des contrôles d’accès CUI, la réponse est un dossier de preuves exportable, et non une enquête sur des logs d’infrastructure dispersés.

Chiffrement FIPS 140-3 et opérations CUI gouvernées sur les fichiers

Toutes les CUI accédées via Kiteworks sont protégées par un chiffrement validé FIPS 140-3 niveau 1 en transit et au repos, répondant aux exigences de chiffrement du NIST 800-171. Les fonctions de gestion de dossiers et de fichiers gouvernés de Kiteworks Compliant AI permettent aux agents IA d’organiser et gérer les dépôts CUI, chaque opération étant contrôlée par le moteur de politique de données — satisfaisant aux exigences RBAC et de ségrégation des CUI sans provisionnement manuel, et fournissant des mises en œuvre documentables dans le SSP pour les pratiques de gestion de la configuration de la famille 3.4.

Pour les organisations qui gèrent des CUI dans le cadre de contrats DFARS et doivent intégrer les déploiements d’agents IA dans la conformité NIST 800-171, Kiteworks fournit l’infrastructure technique de gouvernance et les mises en œuvre documentables dans le SSP qui comblent l’écart entre la posture de conformité pré-IA et la réalité opérationnelle de l’accès agentique aux CUI. Découvrez-en plus sur les fonctions de conformité NIST 800-171 de Kiteworks ou demandez une démo.

Ressources complémentaires

• Article de blog
  Stratégies Zero Trust pour une protection abordable de la confidentialité IA
• Article de blog
  Comment 77 % des organisations échouent sur la sécurité des données IA
• eBook
  Le fossé de la 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 de son efficacité.