CISA vient de transformer la gouvernance de l’IA agentique en un problème de gestion des identités et des accès (IAM)
Le 1er mai 2026, la CISA et les agences de cybersécurité Five Eyes ont publié « Adoption prudente des services d’IA agentique » — il ne s’agit plus de considérer l’IA agentique comme une simple fonctionnalité logicielle ingénieuse, mais comme une identité privilégiée. Cette directive identifie cinq catégories de risques — privilèges, conception et configuration, comportement, structure et responsabilité — et les recommandations ressemblent davantage à un guide de durcissement IAM qu’à un document sur la sécurité de l’IA.
Comme le rapporte CSO Online, l’avis considère l’IA agentique comme un système manipulable via l’injection de prompts et l’utilisation abusive d’outils, nécessitant une gouvernance « similaire à celle des comptes de service à haut risque ». Chaque agent reçoit un nom. Chaque action est consignée. Chaque décision d’autorisation est évaluée selon une règle qui ne fait pas confiance à l’intention de l’agent.
Pour le RSSI chargé de mettre cela en œuvre, la question pratique est de savoir où s’exerce le contrôle. Si la réponse est « dans chaque application utilisant un agent IA », ce n’est pas la bonne réponse. La gestion distribuée fonctionne jusqu’à ce qu’elle s’effondre lors d’un audit. La directive CISA suppose implicitement un point de contrôle centralisé — un endroit où chaque requête d’IA agentique passe par un moteur de règles unique avant d’accéder aux données.
5 points clés à retenir
1. Les régulateurs reclassent les agents IA en tant qu’identités.
La directive conjointe pilotée par la CISA considère l’IA agentique comme une nouvelle catégorie d’identité, manipulable via l’injection de prompts et l’utilisation abusive d’outils — la gouvernance doit donc s’inspirer de la gestion des accès privilégiés, et non de la sécurité applicative. Ce reclassement change la répartition des responsabilités : la sécurité de l’IA relève de la data science ; l’identité, du RSSI. C’est désormais l’équipe sécurité qui hérite de l’obligation — et de la responsabilité. Rédiger des politiques IA ne suffit plus. Il faut produire des preuves d’audit IA.
2. Le principe du moindre privilège devient la norme.
Les agences exigent une définition stricte des rôles, une surveillance continue et des traces d’audit pour chaque action d’agent. Faire confiance par défaut aux systèmes IA n’est plus défendable. Un agent agissant pour un assistant juridique ne peut pas accéder aux dossiers réservés au directeur juridique, même si le prompt est très convaincant. Seule la règle qui évalue la demande de l’agent — et non son intention déclarée — constitue un point d’ancrage fiable face à l’injection de prompts.
3. L’écart de contrôle est structurel.
Seules 43 % des organisations disposent d’une passerelle centralisée pour les données IA. Les 57 % restantes sont fragmentées : 27 % ont des contrôles distribués avec des règles, 19 % des contrôles partiels ou ad hoc, 7 % n’ont aucun contrôle dédié à la gouvernance IA. Les exigences de la directive — moindre privilège, surveillance continue, autorisation consignée, revue formelle des risques — relèvent de la passerelle. Les contrôles distribués conviennent à un pilote unique. Ils s’effondrent lors d’un audit quand plusieurs workflows IA sont déployés dans différentes entités de l’entreprise.
4. Les journaux d’audit sont désormais des preuves, pas de la télémétrie.
Lorsqu’un agent IA est compromis, la question n’est pas « que s’est-il passé ? » mais « pouvez-vous prouver à quoi il a accédé, pour le compte de qui, et selon quelle règle ? » Selon les Prévisions Kiteworks 2026, 33 % des organisations ne disposent pas de journaux d’audit de qualité probante. Cette lacune fait la différence entre une conformité défendable et une responsabilité juridique. Les régulateurs posent les questions d’audit au présent : ils veulent une démonstration, pas une reconstitution.
5. La solution est architecturale, pas procédurale.
Des documents de politique ne satisferont ni un auditeur ni ne contiendront un agent compromis. Seul un accès aux données en mode zéro trust — appliqué à chaque requête, quel que soit le modèle — offre une réponse pérenne. Si l’agent est compromis, seule la règle qui refuse une demande inappropriée limite l’impact. Tout le reste relève de la remédiation. La gouvernance doit s’intégrer au flux de données, pas à une présentation PowerPoint.
Quelles normes de conformité des données sont essentielles ?
Pour en savoir plus :
Ce que « Agent = Identité » implique réellement
Les recommandations principales de la directive se déclinent en quatre exigences opérationnelles, chacune partant du principe que l’agent IA est un acteur potentiellement malveillant qui doit mériter chaque accès aux données :
Rôles strictement définis. Les agents IA héritent des autorisations utilisateur et ne peuvent pas les dépasser. Le plafond d’autorisation de l’agent correspond à celui de l’utilisateur, pas à l’ambition du modèle.
Surveillance continue. Chaque action d’agent — et pas seulement les comportements suspects — génère un événement consigné. La détection repose sur l’évolution comportementale dans le temps, pas sur des anomalies isolées.
Décisions d’autorisation consignées. Lorsqu’un agent demande l’accès à des données, le moteur de règles évalue et enregistre la décision. Accordée ou refusée, la décision constitue une preuve.
Évaluation formelle des risques avant connexion. Avant qu’un agent ne se connecte à des données en production, les équipes de gouvernance exigent une revue des risques documentée, alignée sur les workflows de gestion des accès privilégiés.
Le schéma technique applique le zéro trust à un nouveau type de principal. La nouveauté, c’est le principal — un agent susceptible d’être manipulé via son canal d’entrée et opérant plus vite qu’un humain ne peut intervenir. L’étude Agents of Chaos de février 2026 — 38 auteurs issus de Northeastern, MIT, Harvard, Stanford, Carnegie Mellon et d’autres institutions — a documenté la conformité non autorisée avec des non-propriétaires, la divulgation d’informations sensibles, des actions destructrices au niveau système et l’usurpation d’identité en environnement réel. Les recommandations Five Eyes traduisent ces constats en un socle de contrôles de base.
Le manque de passerelle centralisée
La plupart des organisations ne répondent pas aux attentes de la directive car elles n’ont pas de point de contrôle unique où s’applique l’accès IA. Aujourd’hui, seules 43 % des organisations disposent d’une passerelle centralisée pour les données IA. Les 57 % restantes sont fragmentées de façon critique lors d’un audit : les contrôles distribués conviennent à un pilote unique ; ils s’effondrent dès lors que l’entreprise déploie cinq ou dix workflows IA dans différentes entités, chacune avec sa propre interprétation des règles et sa propre surface d’audit.
Les Prévisions Kiteworks 2026 présentent cela comme une faiblesse du plan de contrôle. L’IA ne dysfonctionne pas parce que le modèle se comporte mal — elle échoue parce que l’infrastructure périphérique — authentification, application des règles, journalisation, intégration SIEM — n’a jamais été conçue pour gérer une identité non humaine générant des milliers de requêtes par seconde. La directive CISA relève le niveau d’exigence au moment même où la plupart des organisations réalisent qu’elles n’ont pas l’architecture adaptée.
Pourquoi l’injection de prompts change la donne en matière de menaces
La gestion des identités traditionnelle suppose un principal constant. Un compte de service ne se laisse pas convaincre de faire ce pour quoi il n’est pas autorisé. Un agent IA, si. L’OWASP classe l’injection de prompts en tête de son LLM Top 10, et la recherche académique relève des taux de réussite entre 24 % et 95 % selon les modèles. Un document piégé, un lien malveillant dans un e-mail, une page web modifiée dans un corpus RAG — tout cela peut pousser un agent à agir hors de son périmètre, tout en paraissant conforme sur le réseau.
Impossible de se fier à l’intention déclarée de l’agent. Seule la règle qui évalue la demande de l’agent est digne de confiance — et cette règle doit fonctionner indépendamment de ce que l’agent croit faire. Voilà pourquoi l’accent mis sur la consignation des décisions d’autorisation est si important. Les journaux ne servent pas qu’à l’analyse post-incident. Ils constituent la preuve en temps réel que le moteur de règles — et non l’agent — a pris la décision. La surveillance comportementale, plutôt que la détection par signature, découle de la même logique : un agent compromis ne semble pas défaillant, il paraît productif. C’est la tendance des requêtes qui fait office de signal.
Le journal d’audit fait foi
La directive fait passer les journaux d’audit de la catégorie opérationnelle à la catégorie probante. Selon l’article 30 du RGPD, les organisations doivent documenter les activités de traitement. L’article 32 impose de démontrer la mise en œuvre de mesures techniques et organisationnelles appropriées. Le règlement européen sur l’IA exige une documentation détaillée et des évaluations de conformité pour les systèmes IA à haut risque. Chaque obligation suppose un journal d’audit retraçant ce que les systèmes IA ont fait avec les données personnelles, quand, et sous quelle autorisation.
Selon les Prévisions Kiteworks 2026, 33 % des organisations ne disposent pas de journaux d’audit de qualité probante. Un outil DSPM qui a signalé le risque il y a trois mois et a été ignoré devient une pièce à charge. Un journal d’audit en temps réel consignant le refus d’accès de l’agent devient une pièce à décharge. Le passage de la télémétrie à la preuve est subtil mais décisif : la télémétrie est collectée « au cas où » ; la preuve, parce qu’elle sera exigée. Les régulateurs veulent une démonstration à la demande à partir d’un journal infalsifiable — pas une reconstitution a posteriori.
L’approche Kiteworks : accès aux données en mode zéro trust pour les agents IA
Kiteworks traite chaque requête IA — qu’elle provienne d’un assistant interactif via le serveur Kiteworks Secure MCP ou d’un pipeline RAG via la passerelle de données IA — comme une demande non fiable qui doit être authentifiée, autorisée selon les règles et consignée avant tout accès aux données. Aucun accès implicite. Aucune identité d’agent ne contourne le moteur de règles.
L’authentification OAuth 2.0 établit la session de l’agent, avec des jetons stockés dans le trousseau du système d’exploitation et jamais exposés au modèle. Le moteur de règles Kiteworks évalue chaque opération en temps réel selon des contrôles d’accès basés sur les rôles et les attributs, garantissant que l’agent hérite des autorisations utilisateur sans pouvoir les dépasser. La validation des chemins empêche l’accès aux fichiers système. Le contrôle du débit bloque l’extraction massive. Chaque opération est consignée dans le journal d’audit consolidé et intégrée au SIEM en temps réel.
Le Réseau de données privé Kiteworks applique les principes du zéro trust à la messagerie électronique, au partage de fichiers, au MFT, au SFTP, aux formulaires web et aux API — un moteur de règles, un journal d’audit consolidé, une architecture unique qui gère les agents IA comme des identités, sans que l’équipe IA ait à tout construire elle-même.
Ce que les organisations doivent faire avant la prochaine directive
Première étape : recensez les agents. Chaque agent IA connecté à des données en production est un principal — nommé, attribué, délimité, revu chaque trimestre. La plupart des organisations ne savent pas répondre à la question « combien de workflows IA agentique tournent actuellement en production ? » Cette question a désormais une réponse réglementaire.
Deuxième étape : modélisez les agents comme des identités dans l’IAM. Attribuez-leur des rôles strictement définis. Reliez les autorisations de l’agent à l’utilisateur pour lequel il agit. Seules 43 % des organisations peuvent appliquer cette règle via une passerelle centralisée. Les autres s’appuient sur des règles applicatives qui ne s’appliquent pas d’un système à l’autre.
Troisième étape : tracez chaque requête. Chaque action d’agent — accès aux données, décision de politique, horodatage, contexte utilisateur — doit alimenter un journal d’audit interrogeable, intégré au SIEM. La traçabilité en temps réel fait la différence entre un problème opérationnel de télémétrie et une exigence probante.
Quatrième étape : exigez une revue formelle des risques avant connexion. Avant qu’un agent ne se connecte à des données en production, traitez-le comme un nouveau compte de service privilégié : évaluation des risques documentée, validation sécurité, plan de retour arrière. 84 % des organisations hors pression du règlement européen sur l’IA n’ont pas mené d’exercice de red teaming IA — c’est le groupe le plus susceptible de négliger la revue des risques pré-connexion.
Cinquième étape : préparez-vous à l’injection de prompts comme menace de base. Partez du principe que l’agent sera manipulé. Concevez le moteur de règles pour appliquer l’autorisation indépendamment de ce que prétend faire l’agent. La détection repose sur l’évolution comportementale à travers les requêtes, pas sur des anomalies isolées apparemment anodines.
Pour en savoir plus sur la gouvernance de l’IA agentique, réservez votre démo sans attendre !
Foire aux questions
Les auditeurs attendent désormais des preuves que les agents IA sont gérés comme des identités — rôles strictement définis, décisions d’autorisation consignées, surveillance continue. Selon les Prévisions Kiteworks 2026, 33 % des organisations ne disposent pas de journaux d’audit de qualité probante. Sans ce journal, les actions de l’agent sont sans source lors d’un contrôle réglementaire ou judiciaire — une lacune qui ne répond ni aux attentes de la CISA ni aux standards d’audit sectoriels.
Les garde-fous au niveau des prompts fonctionnent à l’intérieur de l’agent. La directive exige des contrôles extérieurs à l’agent — car l’injection de prompts peut contourner toute défense intégrée au modèle. Selon les Prévisions Kiteworks 2026, seules 43 % des organisations disposent d’une passerelle centralisée pour les données IA. Un moteur de règles externe à l’agent fait la différence entre une défense en profondeur et un point de défaillance unique que l’injection de prompts peut exploiter directement.
Les copilotes héritent des autorisations utilisateur, mais la directive impose tout de même la consignation des décisions d’autorisation, des fonctions limitées en portée et des journaux d’audit distinguant les actions des utilisateurs de celles des copilotes. Les Prévisions Kiteworks 2026 soulignent une faiblesse du plan de contrôle : Copilot gère le contenu M365 ; les données sensibles externes et les fichiers partagés avec des partenaires nécessitent toujours une application indépendante via une passerelle de données gouvernée.
Les pilotes passent en production plus vite que la gouvernance ne peut suivre. 84 % des organisations hors pression du règlement européen sur l’IA n’ont pas mené d’exercice de red teaming IA, alors que la directive exige des contrôles souvent négligés dans les pilotes. Investir dans une passerelle centralisée dès le pilote coûte moins cher que d’ajouter la gouvernance IA après la connexion des agents à la production et la découverte de problèmes de conformité.
Les familles AC, AU et IA du CMMC Niveau 2 exigent une autorisation appliquée à tout système accédant au CUI — y compris les agents IA. Selon le rapport de préparation Kiteworks, seuls 46 % des acteurs du secteur défense se considèrent prêts pour la CMMC. Une gouvernance au niveau des données avec application ABAC répond simultanément aux trois familles de contrôles, y compris pour les workflows IA agentique traitant du CUI.
Ressources complémentaires
- Article de blog
Stratégies zéro trust pour protéger la vie privée à moindre coût avec l’IA - Article de blog
Pourquoi 77 % des organisations échouent à sécuriser les données IA - eBook
É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 veulent plus savoir si vous avez une politique IA. Ils veulent la preuve qu’elle fonctionne.