Pourquoi le chiffrement FIPS 140-3 est essentiel pour l’accès aux données par les agents IA
La plupart des organisations qui déploient des agents IA sur des données réglementées pensent avoir couvert le chiffrement. Les appels API utilisent TLS. Les données au repos sont protégées par AES-256. Le fournisseur d’hébergement du modèle affiche une page de sécurité mentionnant le chiffrement. La case est cochée.
Ce n’est pas le cas. Pas pour la conformité. CMMC SC.3.177 exige une cryptographie validée FIPS — pas une cryptographie forte, une cryptographie validée. Les amendements 2025 de la HIPAA Security Rule rendent le chiffrement de l’ePHI obligatoire et imposent l’utilisation de modules cryptographiques validés. FedRAMP Moderate exige un chiffrement validé FIPS 140 sur l’ensemble du processus. L’exigence n’est pas « utiliser AES-256 ». Il s’agit d’« utiliser un module cryptographique validé par le NIST pour implémenter correctement AES-256 ». Ce sont deux choses différentes, et c’est dans cet écart que les déploiements d’agents IA échouent actuellement.
Cet article explique ce que signifie réellement la validation FIPS 140-3, comment les flux de données des agents IA créent des failles de chiffrement dans des environnements pourtant conformes, et pourquoi le chiffrement validé à chaque étape de la chaîne de l’agent constitue le troisième pilier fondamental de la gouvernance — après l’identité authentifiée et la politique ABAC — dont les déploiements IA réglementés ont besoin.
Résumé Exécutif
À retenir : La validation FIPS 140-3 n’est pas un indicateur de la robustesse du chiffrement. Il s’agit d’une certification attestant qu’un module cryptographique spécifique — bibliothèque logicielle, matériel ou composant firmware — a été testé par un laboratoire accrédité et validé par le NIST pour implémenter correctement les algorithmes cryptographiques approuvés dans des conditions d’exploitation définies. Un flux de données d’agent IA utilisant un AES-256 non validé n’est pas conforme FIPS. Un flux de données d’agent IA utilisant des modules validés FIPS 140-3 à chaque étape de transit et de stockage l’est.
Pourquoi c’est important : Les pipelines d’inférence des agents IA introduisent de multiples points de transit et de stockage de données que la plupart des organisations n’ont pas évalués pour la validation FIPS : passerelles API, environnements d’hébergement de modèles, bases de données vectorielles, caches temporaires d’inférence, canaux de livraison des résultats. Chacun représente une faille potentielle de chiffrement. Pour les sous-traitants de la défense, cette faille constitue une non-conformité CMMC SC.3.177. Pour les organismes de santé, il s’agit d’un manquement à la HIPAA Security Rule. Pour les sous-traitants fédéraux, c’est un échec de conformité FISMA et FedRAMP. L’évaluation requise est simple — mais la plupart des organisations ne l’ont pas réalisée pour leur infrastructure IA.
Points Clés
- La validation FIPS 140-3 certifie un module, pas un algorithme. La question n’est pas « ce système utilise-t-il AES-256 ? » mais « le module cryptographique qui implémente AES-256 dans ce système figure-t-il sur la liste du NIST CMVP ? » Les implémentations non validées d’algorithmes approuvés ne satisfont pas aux exigences FIPS.
- Les pipelines d’inférence IA comportent plusieurs points de transit et de stockage, chacun nécessitant une évaluation indépendante. La connexion TLS entre l’application et la passerelle API. La connexion entre la passerelle et l’hébergeur du modèle. La mémoire de travail temporaire du modèle. La base de données vectorielle. Le cache de sortie. Confirmer la validation FIPS au niveau de l’application ne garantit rien pour les composants en aval.
- L’infrastructure IA cloud multi-locataire fournit rarement par défaut une documentation de validation FIPS. Les plateformes IA commerciales généralistes ne sont pas conçues pour répondre aux exigences fédérales de validation cryptographique. Les organisations qui déploient ces plateformes sur des flux de données réglementés doivent spécifiquement demander les certificats de validation FIPS des modules — et beaucoup constateront qu’ils n’existent pas.
- FIPS 140-3 remplace FIPS 140-2 pour les nouvelles validations. Le NIST a fait évoluer le programme vers FIPS 140-3 en septembre 2021. Les organisations et fournisseurs qui ne mentionnent que FIPS 140-2 doivent vérifier si leurs modules ont été revalidés selon la norme actuelle. Les nouveaux achats doivent exiger explicitement la validation FIPS 140-3.
- Le chiffrement validé est la couche qui rend le reste de la gouvernance pérenne. L’identité authentifiée et l’application des politiques ABAC empêchent les accès non autorisés. Le chiffrement validé garantit que, même si les données transitent par un chemin imprévu, elles restent illisibles. Les trois contrôles sont complémentaires — chacun couvre un mode de défaillance différent. Le chiffrement sans contrôle d’accès laisse les données lisibles à toute personne ayant accès. Le contrôle d’accès sans chiffrement validé laisse les données lisibles en transit à quiconque les intercepte.
Ce que signifie réellement la validation FIPS 140-3
La norme américaine Federal Information Processing Standard 140-3 définit les exigences de sécurité pour les modules cryptographiques utilisés afin de protéger les informations sensibles. Elle est administrée par le NIST via le Cryptographic Module Validation Program (CMVP). Un module obtient la validation après avoir été testé par un laboratoire tiers accrédité selon les critères de la norme, le NIST délivrant le certificat final de validation.
La validation couvre quatre niveaux de sécurité, du niveau 1 (exigences de base, implémentations logicielles acceptées) au niveau 4 (sécurité physique maximale, dispositifs inviolables et réactifs). Pour la plupart des applications d’entreprise réglementées — santé, services financiers, défense — la validation FIPS 140-3 niveau 1 est requise. L’essentiel est que tout niveau de validation FIPS impose que le module ait effectivement été testé et certifié — et pas seulement qu’il utilise des algorithmes approuvés.
Ce que la validation certifie : le module implémente correctement l’algorithme approuvé. Les fonctions de gestion des clés sont correctement mises en œuvre. Les auto-tests du module fonctionnent comme spécifié. La documentation de sécurité du module est exacte et complète. Ce que la validation ne certifie pas : que le système utilisant le module est sécurisé par ailleurs. Un module cryptographique validé FIPS dans un système mal sécurisé reste un système mal sécurisé — mais il satisfait à l’exigence de chiffrement imposée par CMMC, HIPAA, FedRAMP et NIST 800-171.
FIPS 140-2 vs. FIPS 140-3
Le NIST a officiellement fait évoluer le CMVP vers FIPS 140-3 en septembre 2021, et les validations FIPS 140-2 ne seront plus acceptées pour les nouvelles soumissions après septembre 2026. Les organisations doivent savoir que de nombreuses certifications fournisseurs existantes font encore référence à FIPS 140-2. Pour les achats et évaluations de conformité actuels, FIPS 140-3 est la norme applicable — et la distinction est importante lors de l’évaluation des fournisseurs d’infrastructures IA dont la documentation de sécurité peut mentionner l’ancienne norme.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
Où les pipelines d’agents IA créent des failles de chiffrement
Un flux de données d’agent IA dans un environnement réglementé implique plus de points de transit et de stockage que la plupart des évaluations de conformité ne l’ont envisagé. Chacun représente une faille potentielle de validation FIPS — pas forcément parce que le chiffrement est absent, mais parce que le module cryptographique utilisé n’est peut-être pas validé.
| Composant du pipeline | Données à risque | Faille de validation courante |
|---|---|---|
| Application vers passerelle API | Données réglementées dans la requête de l’agent | L’implémentation TLS peut utiliser une version OpenSSL standard, sans module validé FIPS |
| Passerelle API vers hébergeur du modèle | Contexte du prompt incluant des données réglementées récupérées pour l’inférence | Le transit interne du fournisseur cloud est souvent hors du périmètre de chiffrement validé |
| Environnement d’inférence du modèle | Données réglementées dans la fenêtre de contexte de travail pendant l’inférence | La mémoire GPU et le runtime d’inférence n’ont généralement aucun statut de validation FIPS |
| Base de données vectorielle (RAG) | Représentations embarquées de données réglementées utilisées pour la recherche | Le chiffrement des bases vectorielles utilise souvent des bibliothèques non validées |
| Cache temporaire de sortie | Résultat de l’agent contenant ou dérivé de données réglementées | Le stockage du cache est fréquemment non chiffré ou utilise un chiffrement non validé |
| Canal de livraison des résultats | Résultat final de l’agent vers le système ou l’utilisateur destinataire | La livraison peut utiliser TLS standard sans validation confirmée du module FIPS |
Conséquence pratique : une organisation disposant d’un chiffrement validé FIPS 140-3 au niveau de son application — via un module validé pour son stockage principal et ses communications — peut avoir une posture de chiffrement totalement non validée sur le pipeline d’inférence IA ajouté par-dessus. Le statut de validation FIPS du stockage principal ne dit rien sur celui de la passerelle API, de l’hébergeur du modèle, de la base vectorielle et du cache de sortie utilisés par l’agent IA.
Le problème du cloud multi-locataire
Les plateformes IA commerciales généralistes — principales API LLM, services d’orchestration IA, fournisseurs de bases vectorielles — sont conçues pour une adoption large en entreprise, pas pour la conformité fédérale en matière de validation cryptographique. Leur documentation de sécurité peut mentionner le chiffrement, référencer des algorithmes standard du secteur et inclure diverses certifications. Ce qu’elle ne fournit généralement pas, ce sont les certificats de validation NIST CMVP pour les modules cryptographiques spécifiques utilisés dans les composants traitant des données réglementées lors de l’inférence IA.
Il s’agit d’une faille structurelle : le marché IA commercial n’a pas été conçu pour répondre aux exigences FIPS 140-3, et la plupart des fournisseurs ne maintiennent pas de modules validés CMVP comme fonctionnalité standard de leurs plateformes. Les sous-traitants de la défense et agences fédérales ont traité ce point pour les systèmes principaux en exigeant des services cloud FedRAMP et des variantes produits spécifiques au gouvernement. Peu ont étendu cette évaluation à la couche d’inférence IA qu’ils déploient désormais sur ces mêmes systèmes.
Comment évaluer et combler les failles de chiffrement dans les déploiements d’agents IA
1. Cartographier chaque frontière de chiffrement dans le flux de données de l’agent
Commencez par dresser une cartographie complète de chaque point où des données réglementées transitent ou sont stockées dans le pipeline de l’agent IA : de la source de données à la couche d’orchestration de l’agent, passerelle API, environnement d’hébergement du modèle, bases de données de recherche, traitement des résultats et livraison finale. Pour chaque point, identifiez le module cryptographique assurant le chiffrement. Il ne s’agit pas d’identifier l’algorithme, mais bien la bibliothèque logicielle ou le module matériel qui l’implémente.
2. Vérifier le statut de validation CMVP pour chaque module
Recoupez chaque module cryptographique identifié avec la liste des modules validés NIST CMVP, disponible sur csrc.nist.gov. Un module absent de la liste — ou dont la validation a expiré — n’est pas conforme FIPS, quel que soit l’algorithme implémenté. Pour l’infrastructure fournie par un tiers, demandez directement le numéro de certificat CMVP. Un fournisseur incapable de fournir ce numéro pour le module traitant vos données réglementées n’offre pas de chiffrement validé FIPS pour ce composant.
3. Documenter les failles et les plans de remédiation
Pour chaque composant du pipeline où le chiffrement validé est absent ou non confirmé, documentez la faille, les données réglementées à risque et l’exigence de conformité applicable. Cette documentation a deux objectifs : elle définit la feuille de route de remédiation, et elle prouve aux auditeurs que l’organisation a mené l’évaluation des risques requise et prévoit de combler les failles identifiées. Les organisations soumises à une évaluation CMMC doivent disposer de cette documentation — c’est une demande de preuve prévisible.
4. Exiger la validation FIPS 140-3 dans les contrats fournisseurs IA
Ajoutez des exigences de validation FIPS 140-3 dans les contrats fournisseurs IA pour tout prestataire dont l’infrastructure traite des données réglementées. Précisez la validation pour chaque composant traitant ces données, pas seulement pour la couche de stockage principale. Exigez également que les fournisseurs notifient l’organisation lors de toute mise à jour, remplacement ou changement de statut de validation des modules validés — les certificats CMVP sont spécifiques à une version et une mise à jour logicielle peut invalider une certification antérieure.
Comment Kiteworks propose un chiffrement validé FIPS 140-3 pour l’accès aux données agents IA
Le Réseau de données privé Kiteworks repose sur un chiffrement validé FIPS 140-3 niveau 1 pour toutes les données en transit et au repos. Cette validation couvre l’ensemble du flux de données par lequel transitent les interactions réglementées des agents IA — pas seulement la couche de stockage principale, mais chaque composant de l’architecture de gouvernance traitant des données réglementées.
Quand un agent IA accède à des données réglementées via Kiteworks, chaque opération de transit et de stockage utilise des modules cryptographiques validés. Le même chiffrement validé qui protège l’accès utilisateur humain aux données réglementées protège automatiquement l’accès agent IA — car la couche de gouvernance s’intercale entre l’agent et la donnée, et chaque interaction passe par cette couche. Il n’y a pas d’évaluation de chiffrement spécifique à l’IA à réaliser ; la validation FIPS s’étend à l’accès agent IA par conception.
Pour les sous-traitants de la défense, cela signifie que SC.3.177 est respecté pour les interactions CUI agents IA, avec documentation des certificats CMVP à fournir directement aux auditeurs C3PAO. Pour les organismes de santé, les exigences de chiffrement obligatoires des amendements 2025 de la HIPAA Security Rule sont respectées pour l’accès PHI agents IA. Pour les sous-traitants fédéraux, l’autorisation FedRAMP Moderate couvrant la plateforme Kiteworks s’étend aux workflows agents IA opérant via celle-ci.
Le chiffrement validé n’est pas le contrôle de gouvernance IA le plus visible — il agit en coulisses à chaque interaction de données. Mais c’est la couche qui garantit que l’identité authentifiée et l’application des politiques ABAC ne sont pas contournées par des données lisibles en transit. Les trois contrôles — identité, politique, chiffrement validé — forment la pile de gouvernance rendant chaque interaction agent IA/données réglementées défendable. Découvrez-en plus sur Kiteworks Compliant AI ou réservez votre démo.
Questions fréquentes
CMMC SC.3.177 exige une cryptographie validée FIPS — c’est-à-dire des modules cryptographiques figurant sur la liste des modules validés NIST CMVP. Utiliser AES-256 via une implémentation non validée ne répond pas à cette exigence. Un auditeur C3PAO demandera les numéros de certificats CMVP, pas la description de l’algorithme. Si votre fournisseur d’infrastructure IA ne peut pas fournir ces certificats pour les composants traitant le CUI, vous avez une non-conformité SC.3.177, quelle que soit la robustesse du chiffrement.
Les amendements 2025 imposent que l’ePHI soit chiffré en transit et au repos à l’aide de modules cryptographiques validés — et pas seulement d’algorithmes robustes. Pour les déploiements d’agents IA, cela signifie que chaque composant du pipeline d’inférence traitant des PHI — passerelles API, hébergeurs de modèles, bases vectorielles, caches de sortie — doit utiliser un chiffrement validé FIPS. L’exigence HIPAA Security Rule s’applique à l’ensemble du flux de données, pas seulement au système de stockage principal.
Demandez le numéro de certificat NIST CMVP pour chaque module cryptographique utilisé par le fournisseur dans les composants traitant vos données réglementées. Vérifiez ensuite ce numéro sur la liste des modules validés NIST CMVP sur csrc.nist.gov. Un fournisseur qui décrit son chiffrement comme « conforme FIPS » ou « AES-256 » sans fournir de numéro de certificat CMVP n’a pas prouvé la validation FIPS 140-3. Le numéro de certificat est la seule preuve vérifiable du statut de validation.
Pas automatiquement. L’autorisation FedRAMP couvre le périmètre du service autorisé. Les composants d’inférence IA — couche d’orchestration, passerelles API, hébergement de modèles, bases vectorielles — que vous avez ajoutés sur une plateforme autorisée FedRAMP ne sont pas inclus dans ce périmètre sauf mention explicite. Chaque composant ajouté nécessite sa propre évaluation de validation FIPS. L’autorisation FedRAMP de la plateforme sous-jacente constitue une base solide mais ne remplace pas la validation des composants IA ajoutés.
Les trois contrôles couvrent différents modes de défaillance. L’identité authentifiée et la chaîne de délégation empêchent les accès non autorisés en s’assurant que seuls les agents autorisés accèdent aux données réglementées. L’application des politiques ABAC garantit que même les agents autorisés n’accèdent qu’aux données nécessaires à leur tâche. Le chiffrement validé assure que les données interceptées en transit — par un attaquant réseau ou un composant non autorisé du pipeline d’inférence — restent illisibles. Chaque couche comble une faille que les autres ne couvrent pas. Ensemble, elles forment une pile de gouvernance où la défaillance d’une couche ne compromet pas l’ensemble.
Ressources complémentaires
- Article de blog
Stratégies Zero‑Trust pour une protection abordable de la vie privée IA - Article de blog
Pourquoi 77 % des organisations échouent sur la sécurité des données IA - eBook
AI Governance Gap : 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 concrètes.