CMMC 2.0 et agents IA : Que signifie « accès autorisé » pour les workflows traitant des CUI

Les sous-traitants de la défense déploient des agents IA pour la rédaction de propositions, la documentation de programmes, la gestion de la supply chain et les flux de données techniques. Beaucoup de ces processus manipulent des informations non classifiées mais contrôlées (CUI). Cela les place directement dans le champ d’application du CMMC 2.0 – non pas comme une contrainte future, mais comme une obligation de conformité actuelle déjà évaluée par des auditeurs tiers.

Les exigences du CMMC en matière de contrôle d’accès, d’audit et de chiffrement ne prévoient aucune exemption pour les systèmes pilotés par des machines. Qu’il s’agisse d’un collaborateur habilité ou d’un agent IA autonome accédant à un document CUI, l’obligation de conformité reste identique : l’accès doit être autorisé, gouverné par le rôle et le contexte, chiffré avec une cryptographie validée et consigné dans un journal d’audit opérationnel rattaché à un responsable humain. La plupart des déploiements IA dans l’industrie de la défense ne répondent à aucune de ces exigences.

Cet article détaille ce que le CMMC 2.0 exige précisément pour les flux IA manipulant des CUI, identifie les écarts de conformité que les auditeurs vont détecter, et présente les meilleures pratiques pour encadrer l’accès des agents IA aux CUI afin de produire des preuves irréfutables – et non de simples explications – lors de l’audit C3PAO.

Résumé Exécutif

Idée principale : Les pratiques de contrôle d’accès, d’audit et de chiffrement du CMMC 2.0 s’appliquent à tout système manipulant des CUI, y compris les agents IA. Les sous-traitants de la défense qui déploient des IA sur des flux contenant des CUI sans authentification de l’identité de l’agent, application des règles ABAC et journalisation opérationnelle s’exposent à des risques de non-conformité impossibles à corriger a posteriori une fois l’audit lancé.

Pourquoi c’est important : La certification CMMC conditionne l’éligibilité aux contrats – un échec à l’audit prive l’organisation de contrats DoD. Les auditeurs évaluent les contrôles au niveau de l’accès aux données, pas au niveau du modèle. Un sous-traitant incapable de produire une chaîne de délégation reliant chaque interaction IA/CUI à un responsable humain, de démontrer l’application du principe du moindre privilège au niveau opérationnel, et de prouver l’utilisation d’un chiffrement validé FIPS 140-3 sur chaque flux CUI, sera sanctionné. Il faut combler ces lacunes avant l’arrivée du C3PAO, pas pendant l’audit.

Résumé des points clés

1. Le CMMC 2.0 s’applique sans exception aux agents IA manipulant des CUI. AC.1.001 impose un accès autorisé aux CUI, qu’il s’agisse d’un humain ou d’un système automatisé. Le CMMC ne fait aucune distinction entre un collaborateur habilité et un agent IA traitant un dossier technique. Les contrôles régissant l’accès humain aux CUI s’appliquent intégralement aux agents IA.
2. Les auditeurs évaluent les contrôles au niveau des données, pas du modèle. Un C3PAO ne demandera pas quel modèle IA vous utilisez ni comment sont configurés vos prompts. Il demandera : à quelles CUI l’agent a-t-il accédé, sous quelle autorisation, avec quel chiffrement, et pouvez-vous fournir un journal d’audit reliant cet accès à un responsable humain ? Si l’une de ces réponses n’est pas un dossier de preuves documenté, l’audit aboutira à des constats de non-conformité.
3. Les exigences de ségrégation des CUI s’étendent aux dossiers gérés par l’IA. Les pratiques de contrôle d’accès du CMMC imposent que les CUI soient ségrégées et accessibles uniquement aux personnes autorisées. Lorsque des agents IA créent, déplacent ou restructurent des arborescences de dossiers contenant des CUI, ces structures doivent hériter automatiquement des contrôles RBAC/ABAC, comme pour les dossiers créés manuellement. Des dossiers générés par IA sans héritage automatique des règles créent des failles de ségrégation.
4. La chaîne de délégation relie les actions de l’IA à la responsabilité humaine. Les pratiques AC et AU du CMMC exigent que chaque accès aux CUI soit traçable jusqu’à un individu autorisé. Pour les agents IA, cela signifie que l’enregistrement d’authentification doit relier l’identité de l’agent au responsable humain ayant délégué le flux – et non à un simple compte de service. Sans cette chaîne de délégation, le journal d’audit est, par définition, incomplet.
5. Les garde-fous d’exécution et prompts système ne sont pas des contrôles d’accès CMMC. Le sandboxing réseau, les moteurs de règles à l’exécution et les filtres de sécurité IA agissent au niveau du modèle ou de l’exécution. Ce sont des fonctions de sécurité utiles, mais elles ne répondent pas aux exigences CMMC de contrôle d’accès, d’audit ou de validation du chiffrement au niveau des données. Un C3PAO ne les acceptera pas comme preuve de conformité AC.1.001 ou AU.2.042.

Ce que le CMMC 2.0 exige pour les systèmes IA manipulant des CUI

Le niveau 2 du CMMC 2.0 s’aligne sur les 110 pratiques de sécurité du NIST SP 800-171, réparties en 14 domaines. Quatre domaines sont directement concernés lorsque des agents IA accèdent, traitent ou gèrent des CUI : Contrôle d’accès (AC), Audit et responsabilité (AU), Identification et authentification (IA), et Protection des systèmes et des communications (SC).

Contrôle d’accès : AC.1.001 et AC.2.006

AC.1.001 impose que l’accès aux CUI soit limité aux utilisateurs autorisés, aux processus agissant pour leur compte et aux dispositifs. « Processus agissant pour le compte d’utilisateurs autorisés » inclut explicitement les agents IA – il n’y a aucune ambiguïté. AC.2.006 impose que l’accès soit limité aux types de transactions et fonctions autorisées pour chaque utilisateur. Pour les agents IA, le principe du moindre privilège doit s’appliquer à chaque opération : un agent autorisé à lire un dossier de contrats n’est pas automatiquement autorisé à télécharger tous les fichiers, déplacer des documents ou supprimer du contenu. Chaque opération nécessite une évaluation de la politique d’accès.

Audit et responsabilité : AU.2.042

AU.2.042 impose que les activités des utilisateurs individuels – y compris les processus agissant pour leur compte – soient suivies, enregistrées et périodiquement examinées. Le journal d’audit doit consigner l’identité authentifiée de l’agent, le responsable humain ayant autorisé le flux, la CUI concernée, l’opération réalisée et l’horodatage. Un simple log indiquant qu’un endpoint API a été appelé ne suffit pas. Il faut un log précisant quel document CUI a été consulté, par quel agent, sous quelle politique, et avec quelle autorisation humaine.

Identification et authentification : pratiques IA

Les pratiques IA du CMMC imposent que les utilisateurs et processus soient identifiés et authentifiés de façon unique avant d’accéder aux CUI. Les agents IA utilisant des comptes de service partagés ou des clés API ne respectent pas cette exigence. Chaque agent doit disposer d’un identifiant unique lié au flux concerné et au responsable humain ayant délégué la tâche. Si plusieurs agents partagent une même identité ou si l’authentification ne permet pas de remonter à un décideur humain précis, les pratiques IA ne sont pas respectées.

Protection des systèmes et des communications : SC.3.177

SC.3.177 impose que les CUI soient chiffrées avec une cryptographie validée FIPS lors des transmissions sur des réseaux ouverts et lors du stockage. Pour les agents IA, cela signifie que chaque flux de données – appels API vers des dépôts CUI, pipelines d’inférence, caches temporaires, canaux de sortie – doit utiliser des modules cryptographiques validés FIPS 140-3. Des implémentations TLS ou AES-256 sans validation FIPS 140-3 ne suffisent pas pour SC.3.177. Un auditeur exigera les certificats de validation des modules cryptographiques, pas la documentation de configuration du fournisseur.

Où les déploiements IA ne répondent pas aux exigences CMMC

L’architecture standard des déploiements d’agents IA dans la DIB – un agent connecté à un dépôt documentaire via API, piloté par un compte de service et un prompt système – échoue sur plusieurs points face à l’audit CMMC. Il s’agit d’écarts structurels entre la conception des déploiements IA et les exigences que les auditeurs doivent vérifier.

Absence de chaîne de délégation = absence de responsable

Lorsqu’un auditeur CMMC examine un accès CUI et demande qui l’a autorisé, la réponse doit être une personne nommément désignée et habilitée. Un compte de service renvoie un nom de système. Une clé API renvoie un jeton. Sans chaîne de délégation reliant l’action de l’agent à la personne ayant autorisé le flux, l’accès n’a pas de responsable – ce qui constitue une non-conformité directe aux exigences AC.1.001 et AU.2.042. Cette lacune ne peut pas être corrigée a posteriori : la chaîne de délégation doit être enregistrée au moment de l’accès, sinon elle n’existe pas dans le journal d’audit.

Absence d’encadrement opérationnel des accès

La plupart des déploiements IA attribuent aux agents des identifiants à large périmètre et comptent sur les prompts pour limiter leurs actions. Les auditeurs CMMC évaluent ce que l’agent pouvait techniquement faire, pas ce qu’on lui a demandé de faire. Si un compte de service donne accès à 10 000 documents CUI et que l’agent n’en avait besoin que de trois, il a eu un accès non autorisé à 9 997 documents du point de vue du principe du moindre privilège AC.2.006 – qu’il les ait consultés ou non.

Les dossiers créés par l’IA n’héritent d’aucun contrôle

Les agents IA créent de plus en plus des arborescences de dossiers pour les propositions, livrables et lots de données techniques. Le CMMC exige que ces dossiers héritent automatiquement des contrôles d’accès CUI. Dans la plupart des déploiements, les dossiers créés par l’IA n’ont ni RBAC ni ABAC appliqués, sauf si un humain les provisionne après coup. Tout document placé dans un dossier IA non gouverné constitue une non-conformité de ségrégation CUI.

Bonnes pratiques pour un accès conforme au CMMC des agents IA aux CUI

1. Attribuer à chaque agent IA des identifiants liés à un responsable humain

Chaque agent IA accédant à des CUI doit disposer d’un identifiant unique au niveau du flux – et non d’un compte de service partagé. Cet identifiant doit être relié dans l’enregistrement d’authentification à la personne ayant autorisé le flux. La chaîne de délégation – responsable humain, identité de l’agent, événement d’accès CUI – doit figurer dans chaque entrée du journal d’audit. Les identifiants partagés ne répondent pas aux exigences IA du CMMC, quelle que soit la portée définie au niveau applicatif.

2. Appliquer l’ABAC opérationnel à chaque demande d’accès CUI

Mettez en place un contrôle d’accès basé sur les attributs qui évalue chaque demande CUI selon le profil authentifié de l’agent, la classification CUI des données, le contexte du flux et l’opération demandée. Un agent autorisé à lire un dossier de propositions n’est pas autorisé à télécharger tous les fichiers, déplacer du contenu ou accéder à d’autres catégories CUI. Cette évaluation opérationnelle permet de respecter l’exigence AC.2.006 du moindre privilège.

3. Garantir l’héritage automatique des contrôles CUI sur les dossiers gérés par l’IA

Toute arborescence de dossiers créée ou modifiée par un agent IA contenant des CUI doit hériter des contrôles RBAC et ABAC dès sa création – et non après intervention manuelle. La couche de gouvernance assurant la ségrégation CUI doit être intégrée à l’opération de création du dossier. Un dossier sans héritage de contrôle est une non-conformité de ségrégation, quel que soit son créateur.

4. Consigner des journaux d’audit opérationnels infalsifiables pour chaque accès IA aux CUI

Chaque interaction IA/CUI doit être consignée au niveau opérationnel : identité de l’agent, responsable humain, document ou dossier consulté, type d’opération, résultat de la politique d’accès et horodatage. Le journal doit être infalsifiable et exportable pour l’audit C3PAO et l’intégration SIEM. Les logs API de session ne suffisent pas pour AU.2.042 – c’est l’une des premières preuves exigées par les auditeurs.

5. Valider le chiffrement FIPS 140-3 sur chaque flux CUI

Auditez chaque point où des CUI sont transmises ou stockées dans les flux IA – appels API, hébergement de modèles, bases vectorielles, mémoires temporaires, fichiers de sortie – et vérifiez la certification des modules cryptographiques FIPS 140-3 pour chacun. SC.3.177 exige une cryptographie validée, pas seulement des algorithmes robustes. Une organisation utilisant AES-256 sans certificat de validation FIPS 140-3 présente une non-conformité, quelle que soit la robustesse du chiffrement.

Comment Kiteworks permet une gouvernance IA conforme au CMMC

Gérer l’accès des agents IA aux CUI selon les exigences des auditeurs CMMC impose une architecture différente de celle déployée par la plupart des sous-traitants de la défense. Comptes de service, clés API et prompts système relèvent de la couche applicative. Le CMMC évalue la couche données. Le Réseau de données privé Kiteworks – autorisé FedRAMP Moderate et couvrant près de 90 % des exigences CMMC 2.0 niveau 2 – offre aux sous-traitants une couche de gouvernance qui intercepte chaque interaction IA/CUI avant qu’elle n’ait lieu, en appliquant la vérification d’identité, la politique d’accès, le chiffrement et la traçabilité exigés par les auditeurs CMMC.

Identité de l’agent et chaîne de délégation pour AC.1.001 et AU.2.042

Kiteworks authentifie chaque agent IA avant tout accès aux CUI et relie cette authentification au responsable humain ayant délégué le flux. La chaîne de délégation complète – identité du responsable, de l’agent, contexte opérationnel et résultat de la politique – est consignée dans chaque entrée du journal d’audit. Quand un C3PAO demande qui a autorisé cet accès CUI et ce que l’agent était autorisé à faire, la réponse est un enregistrement complet, horodaté et infalsifiable, et non une reconstitution à partir de logs applicatifs.

ABAC opérationnel pour l’application du moindre privilège AC.2.006

Le moteur de règles de données Kiteworks évalue chaque demande IA/CUI selon une politique multidimensionnelle : profil authentifié de l’agent, classification CUI des données demandées, contexte du flux et opération spécifique. Un agent autorisé à lire des propositions dans un dossier donné ne peut pas télécharger tous les fichiers, accéder à d’autres catégories CUI ou effectuer des opérations hors de son périmètre. Le moindre privilège est appliqué au niveau opérationnel – c’est l’exigence AC.2.006, et la plupart des déploiements IA ne peuvent actuellement pas la démontrer.

Opérations sur dossiers gouvernées pour la ségrégation CUI

L’assistant d’opérations sur dossiers gouvernés de Kiteworks Compliant AI permet aux agents IA de créer, renommer, déplacer et organiser des arborescences CUI par instructions en langage naturel, chaque opération étant contrôlée par le moteur de règles de données. Les dossiers créés par l’IA héritent automatiquement des contrôles RBAC et ABAC, respectant les exigences de ségrégation CUI du CMMC dès leur création. Aucun provisionnement manuel n’est requis, et aucun dossier IA n’existe hors du périmètre de gouvernance.

Chiffrement FIPS 140-3 et journal d’audit infalsifiable pour SC.3.177 et AU.2.042

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 à SC.3.177 avec un certificat de module validé à présenter aux auditeurs. Chaque interaction IA/CUI est consignée dans un journal d’audit opérationnel infalsifiable, intégré au SIEM de l’organisation. Lorsqu’un C3PAO demande un dossier de preuves AU.2.042, la réponse est un rapport exportable – et non une reconstitution forensique à partir de logs d’infrastructure inadaptés aux exigences CMMC.

Les sous-traitants de la défense souhaitant déployer l’IA à pleine vitesse sans accumuler de constats CMMC disposent avec Kiteworks de l’infrastructure de gouvernance qui rend chaque interaction IA/CUI prête à l’audit par conception. Découvrez les fonctions de conformité CMMC de Kiteworks ou demandez une démo pour voir comment Kiteworks gouverne l’accès IA aux CUI dans votre environnement.

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
  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 la preuve qu’elle fonctionne.