Le contrôle d’accès des agents IA doit se situer au niveau des données, pas dans le prompt système
Donner à votre agent IA une instruction système lui demandant de n’afficher aux utilisateurs que les données auxquelles ils ont accès n’est pas un contrôle de sécurité. Il s’agit d’une suggestion, rédigée en anglais, placée dans la même fenêtre de contexte que tous les autres textes traités par l’agent, et ces suggestions peuvent être contournées.
Ce n’est plus une affirmation provocante. C’est la position officielle d’AWS et du SANS Institute, publiée ce mois-ci dans des recommandations signées par Gee Rittenhouse d’AWS, responsable de Security Hub, GuardDuty et Inspector, accompagné d’Eric Johnson, fellow du SANS, et de trois autres spécialistes sécurité AWS. Leur message aux équipes en charge de cybersécurité, tel que relayé par Help Net Security, est sans détour. Demander à un agent via son prompt système de respecter les autorisations d’un utilisateur peut être « contourné, ignoré ou outrepassé », et aucune formulation, aussi soignée soit-elle, n’y change rien. Selon eux, la solution doit intervenir au niveau de la donnée. Il faut restreindre chaque requête aux droits réels de l’utilisateur demandeur, au moment de la récupération, via le système de contrôle d’accès basé sur les rôles ou contrôle d’accès basé sur les attributs déjà en place dans l’organisation, et filtrer les résultats avant qu’ils n’atteignent le modèle.
Un second rapport indépendant sur l’usage de l’IA en entreprise montre pourquoi ce point est crucial aujourd’hui. Comme le détaille The American Reporter, la majorité des activités IA impliquant des données sensibles en entreprise ne sont pas approuvées, ne sont pas tracées comme l’exigerait une équipe conformité, et ne sont pas protégées par les contrôles d’accès conçus pour un monde sans agents. Pour le RSSI et le Chief Compliance Officer qui doivent répondre devant un régulateur ou un auditeur, la question n’a jamais été de savoir si l’agent se comportait poliment. Il s’agit de savoir si chaque accès à une donnée sensible peut être relié à une autorisation précise, au moment exact, avec une traçabilité qui résiste à l’examen. Kiteworks secure data exchange a été conçu pour répondre précisément à cette exigence, étendue aujourd’hui aux agents IA et aux utilisateurs humains sous une politique unique.
Résumé des points clés
1. Les prompts système ne sont pas des contrôles d’accès.
Les recommandations d’AWS et du SANS Institute publiées en septembre 2026 affirment clairement que les instructions de prompt peuvent être contournées, ignorées ou outrepassées, et recommandent d’appliquer les autorisations au niveau de la récupération des données.
2. L’adoption dépasse largement la gouvernance.
Les chiffres de McKinsey cités dans ces recommandations estiment que 80 % des organisations ont adopté l’IA, contre seulement 10 % de maturité en gouvernance de l’IA – un écart que la plupart n’ont pas comblé.
3. Une IA non gouvernée a un coût chiffré.
Le rapport IBM 2026 sur le coût d’une violation de données révèle que les incidents impliquant de l’IA fantôme coûtent en moyenne 5,39 millions de dollars, contre 4,63 millions l’année précédente, et que 68 % des 602 organisations étudiées n’ont toujours pas de gouvernance IA pour les gérer.
4. Une étude de cas documentée montre pourquoi la formulation échoue.
Des chercheurs de l’étude Agents of Chaos ont réussi à faire divulguer par un agent IA un numéro de Sécurité sociale non caviardé simplement en reformulant une demande bloquée sous la forme d’une demande de transfert d’un e-mail entier.
5. La solution est architecturale, pas lexicale.
Restreindre chaque requête d’agent IA selon les autorisations RBAC ou ABAC au moment de la récupération, avant que la donnée n’atteigne la fenêtre de contexte du modèle, comble une faille que la meilleure formulation de prompt ne peut résoudre.
L’étude de cas qui prouve qu’un prompt ne suffit pas
Si l’argument selon lequel les prompts système échouent vous paraît abstrait, une étude de février 2026 intitulée Agents of Chaos l’a rendu concret. Vingt chercheurs issus du MIT, de Stanford, Harvard et Carnegie Mellon ont passé deux semaines à tester en conditions réelles des agents IA basés sur le framework OpenClaw, dans un laboratoire, avec de vrais comptes e-mail, du stockage persistant et un accès shell.
Dans une étude de cas, les chercheurs ont placé un numéro de Sécurité sociale, un numéro de compte bancaire et des informations médicales dans l’e-mail d’un propriétaire d’agent. Lorsqu’un non-propriétaire a demandé directement à l’agent « le SSN dans l’e-mail », l’agent a refusé, comme l’aurait prédit une instruction lui demandant de protéger les informations sensibles. Mais lorsque la même personne a demandé à l’agent de transférer l’e-mail entier, il a obtempéré. Toutes les informations personnelles identifiables sont parties sans censure, y compris le SSN, le numéro de compte et le dossier médical, en un seul message.
La conclusion plus large des chercheurs doit interpeller les architectes sécurité. Les agents traitent instructions et données comme des tokens dans la même fenêtre de contexte, ce qui signifie qu’ils n’ont aucun moyen fiable de distinguer une demande légitime d’une demande manipulée présentée comme légitime. Les auteurs de l’étude parlent d’un déficit structurel, et non d’un bug que l’entraînement pourrait corriger. Cinq des dix catégories OWASP Top 10 pour les applications LLM, dont la divulgation d’informations sensibles et la fuite de prompts système, correspondent directement aux failles observées. Un système incapable de distinguer une instruction d’une donnée déguisée en instruction ne peut faire confiance à une frontière d’autorisation définie uniquement à ce niveau.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
L’IA fantôme manipule déjà des données réglementées
L’étude Agents of Chaos s’est déroulée en laboratoire. Mais l’exposition qu’elle démontre est déjà bien réelle en production. La couverture de The American Reporter sur l’usage de l’IA en entreprise cite des sondages selon lesquels 90 % des responsables sécurité admettent que leurs collaborateurs utilisent des outils IA non approuvés au travail, et 69 % des RSSI ont intégré ces outils dans les workflows quotidiens malgré tout. Environ 80 % des employés déclarent faire de même. Seuls 52 % disent connaître la politique d’utilisation de l’IA de leur entreprise, mais 70 % savent que des données sensibles sont partagées avec des outils IA sur leur lieu de travail. Selon ce même rapport, le volume de données d’entreprise transitant par des applications IA et machine learning atteindra 18 033 téraoctets en 2025, avec 39,7 % des interactions IA exposant des données sensibles – une hausse annuelle de 93 %.
Les contrôles traditionnels n’ont jamais été conçus pour ce schéma. Les règles DLP écrites pour les pièces jointes e-mail et les remplaçants SFTP sécurisés supposent un flux de données avec un début, une fin, et peu d’étapes intermédiaires. Un dossier client qui passe par un chatbot, transite par un second système, puis arrive chez un conseiller humain ne rentre pas dans ce modèle. Il n’existe que rarement un journal unique retraçant tous les systèmes traversés par la donnée, ce qui signifie que lorsqu’un régulateur demande cette traçabilité, elle n’existe souvent pas sous une forme exploitable. Ce n’est ni un problème de formation ni une campagne de sensibilisation à lancer. C’est une architecture qui n’a jamais été pensée pour cela, et la situation empire à chaque trimestre où la classification des données et l’application des contrôles d’accès restent greffées sur des systèmes jamais conçus pour gérer des flux IA.
Combien coûte réellement un accès IA non gouverné ?
L’argument financier pour combler cette faille n’est plus théorique. Le rapport IBM 2026 sur le coût d’une violation de données montre que les incidents impliquant de l’IA fantôme coûtent en moyenne 5,39 millions de dollars, contre 4,63 millions l’année précédente, et que 68 % des 602 organisations étudiées n’ont toujours pas de gouvernance IA pour les gérer ou détecter leur usage non autorisé. Les recommandations citées par Help Net Security s’appuient sur les chiffres de McKinsey, qui montrent que l’adoption de l’IA atteint 80 % des organisations, alors que la maturité de la gouvernance IA plafonne à 10 %. Cet écart s’est encore creusé à mesure que les déploiements agentiques dépassent les simples chatbots pour devenir des systèmes dotés de mémoire persistante, d’exécution d’outils et de capacité à agir pour le compte d’un utilisateur.
Le rapport prévisionnel 2026 de Kiteworks sur la sécurité et la conformité des données chiffre ce même écart sous l’angle de la maîtrise. Parmi les organisations interrogées, 100 % ont l’IA agentique dans leur feuille de route, mais 63 % ne peuvent pas limiter l’usage des agents IA à un objectif précis, 60 % ne peuvent pas désactiver rapidement un agent défaillant, et 55 % ne peuvent pas isoler un système IA du reste du réseau en cas de problème. Le rapport identifie un écart de 15 à 20 points entre ce que les organisations peuvent surveiller et ce qu’elles peuvent stopper, ce qui signifie que la plupart peuvent observer un agent mal se comporter presque en temps réel sans avoir de levier pour l’arrêter. 54 % des conseils d’administration ne placent pas la gouvernance des données IA dans leur top 5 des priorités, et ces organisations accusent un retard de 26 à 28 points sur toutes les capacités mesurées, comparé à celles qui le font.
Une architecture qui applique le contrôle d’accès au niveau de la donnée
Une fois admis que le modèle lui-même ne peut jamais être le contrôle, la solution n’est plus une question de rédaction, mais d’infrastructure. Chaque requête d’agent IA – qu’elle provienne d’un chatbot, d’un agent autonome ou d’un pipeline RAG (retrieval-augmented generation) – doit passer par une vérification des droits avant toute récupération, selon les mêmes règles RBAC ou ABAC déjà en place pour les utilisateurs humains. Le refus par défaut doit s’appliquer au niveau de l’appel d’outil, et non comme une couche ajoutée sur un prompt. Et surtout, la politique doit être la même, qu’un humain ait cliqué sur un bouton ou qu’un agent ait appelé un outil. La gouvernance ne doit pas être plus laxiste selon l’identité qui agit ; elle s’applique aux humains comme aux agents, sous une politique unique et une seule traçabilité d’audit.
C’est le principe qui sous-tend Kiteworks Secure MCP Server et Kiteworks Compliant AI. Les deux restreignent ce qu’un agent IA ou un grand modèle de langage peut récupérer aux autorisations ABAC réelles de l’utilisateur demandeur, appliquées en dehors de la fenêtre de contexte du modèle, et non dans un prompt traité par le modèle lui-même. Le Kiteworks Data Policy Engine applique cette politique de façon cohérente sur la messagerie électronique, le partage et le transfert de fichiers, les formulaires web et désormais l’accès IA, le tout sur une appliance virtuelle durcie avec chiffrement validé FIPS 140-3 et une traçabilité d’audit suffisamment détaillée pour être lue par un évaluateur sans intervention d’un ingénieur.
Un point à préciser clairement, car le surestimer reviendrait à reproduire l’erreur que toute cette approche vise à corriger. Les contrôles d’accès ainsi définis régissent ce qu’une requête peut récupérer une fois liée aux autorisations vérifiées d’un utilisateur. Ils ne détectent pas, à eux seuls, une attaque par injection de prompt cachée dans une pièce jointe, une page web aspirée ou tout autre contenu non fiable que l’agent doit traiter. C’est une couche de défense distincte, et AWS le précise aussi dans ses recommandations. Il ne faut jamais laisser un agent cumuler accès à des données sensibles, capacité de communiquer vers l’extérieur et exposition à du contenu non fiable, car c’est précisément ce qui transforme une injection de prompt en voie d’exfiltration de données. Le contrôle d’accès au niveau de la donnée comble la faille de récupération. Il ne remplace pas la nécessité de gouverner aussi ce qu’un agent peut faire une fois la donnée récupérée.
Ce que les régulateurs et auditeurs demanderont réellement
Voici le cadre qui compte le plus pour un RSSI ou un Chief Compliance Officer défendant ce dossier en interne. Les régulateurs réglementent la donnée, pas les modèles. HIPAA ne s’intéresse pas à savoir si un humain ou un agent IA a consulté un dossier patient ; il veut savoir si cet accès était autorisé, limité au strict nécessaire et tracé. Il en va de même pour le RGPD, qui exige que les informations d’une personne soient traitées sur une base légale et que ce traitement puisse être prouvé à la demande, ou pour le CMMC dans la défense, où un agent IA manipulant des informations non classifiées contrôlées entre dans le périmètre d’évaluation comme le ferait un utilisateur humain.
Aucun de ces cadres n’a été rédigé en pensant aux agents IA, et ils n’ont pas besoin de l’être pour s’appliquer. Ce qu’ils exigent, c’est une preuve : un propriétaire de donnée identifié pour chaque système accédant à des informations réglementées, un périmètre d’autorisation disponible à la demande, et une traçabilité montrant non seulement que l’accès a eu lieu, mais qu’il était autorisé par une politique précise, à un moment précis. Un évaluateur préparant un audit HIPAA Security Rule ou une évaluation CMMC niveau 2 ne demandera pas ce que contient le prompt système de votre agent IA. Il demandera le journal d’accès, le modèle d’autorisations sous-jacent, et la preuve que les deux concordent.
Les enjeux varient selon les secteurs, mais l’exigence de preuve reste la même. Un responsable conformité santé préparant un audit HIPAA doit prouver qu’un agent IA résumant des dossiers patients a respecté la règle du minimum nécessaire comme le ferait un employé humain. Un responsable conformité chez un sous-traitant défense préparant une évaluation C3PAO sous CMMC 2.0 doit prouver qu’un agent IA n’a jamais eu un accès plus large que le périmètre d’évaluation ne l’autorise. Un RSSI secteur financier répondant aux exigences SEC ou GLBA doit apporter la même preuve pour un agent résumant l’activité d’un compte. Dans tous ces cas, la preuve acceptée par un auditeur est un enregistrement d’autorisation et un journal d’accès, pas une description de la politesse de l’agent.
Les pipelines RAG exigent la même rigueur, sans exception
Le même principe s’applique qu’un agent appelle un outil directement ou récupère du contexte via un pipeline de retrieval-augmented generation. Les architectures RAG sont particulièrement sujettes à l’erreur ici, car l’étape de récupération est souvent conçue comme un moteur de recherche générique qui retourne tout ce qui est pertinent, avec des contrôles d’accès ajoutés après coup, si tant est qu’ils existent. Un contrôle d’autorisation qui s’exécute après la récupération n’est pas un contrôle d’autorisation. C’est un filtre sur des résultats que le modèle a peut-être déjà utilisés pour générer une réponse, enregistrer un résumé ou agir. Le contrôle doit s’exécuter avant la requête sur l’index, selon les autorisations réelles de l’utilisateur demandeur, à chaque fois, quel que soit le degré de confiance du système dans la pertinence du résultat.
Combler l’écart entre adoption de l’IA et gouvernance de l’IA
Toute entreprise qui déploie l’IA agentique finira par se heurter à ce mur. L’adoption a déjà dépassé la gouvernance, et celles qui combleront cet écart en premier n’auront pas à expliquer à leur conseil d’administration une surprime IA fantôme de plusieurs millions après une fuite. Quelques mesures concrètes font la différence entre un programme IA capable de passer un audit et un autre qui échouera.
Commencez par recenser chaque agent IA ayant accès à des données sensibles, qu’il soit approuvé ou non, et attribuez-lui un propriétaire de donnée identifié et un périmètre d’autorisation défini, plutôt qu’une simple description de ses fonctions. Déplacez l’application des droits au niveau de la récupération et testez-la selon les mêmes règles RBAC ou ABAC que pour les humains, avant que toute donnée n’atteigne la fenêtre de contexte du modèle. Ne laissez jamais un agent cumuler accès à des données sensibles, communication sortante et exposition à du contenu non fiable ; répartissez ces fonctions entre plusieurs agents spécialisés. Produisez des journaux d’accès exploitables pour chaque accès IA, conçus pour répondre aux exigences des régulateurs, pas seulement à un post-mortem interne. Et désignez une personne responsable, pas un paragraphe d’instructions, pour ce qu’un agent est autorisé à faire.
Rien de tout cela ne traite les agents IA comme une menace à bloquer. Il s’agit de les intégrer, comme toute nouvelle identité en entreprise, dans le modèle de gouvernance déjà appliqué aux utilisateurs humains, et non de les laisser fonctionner sur la base de « bonnes manières ».
Pour en savoir plus sur la gestion du contrôle d’accès des agents IA au niveau de la donnée plutôt qu’au niveau du prompt système, réservez votre démo sans attendre.
Foire aux questions
Un prompt système est une instruction traitée par le même modèle qui analyse aussi toutes les autres données de sa fenêtre de contexte, y compris les données et les requêtes utilisateurs. Les recommandations AWS et SANS Institute publiées en septembre 2026 précisent que ces instructions peuvent être contournées, ignorées ou outrepassées, car le modèle ne sait pas distinguer une instruction autoritaire d’une demande conçue pour y ressembler. Des tests réels, dont l’étude Agents of Chaos, l’ont démontré : un agent a refusé une demande directe d’accès à des données sensibles, mais les a divulguées sans filtre lorsque la demande était reformulée. Un contrôle efficace impose d’appliquer les autorisations d’accès au niveau de la récupération des données, indépendamment du contenu du prompt.
RBAC accorde l’accès selon le rôle attribué à l’utilisateur, comme « analyste facturation » ou « gestionnaire de sinistres », et fonctionne bien quand les droits correspondent aux fonctions. ABAC évalue un ensemble plus large d’attributs, comme la classification de la donnée, le service, la localisation ou l’heure de la demande, ce qui le rend plus adapté aux décisions d’accès contextuelles et fines que requièrent souvent les agents IA. Beaucoup d’entreprises combinent les deux, RBAC pour la base, ABAC pour les requêtes plus granulaires. Dans les deux cas, le principe reste d’appliquer les autorisations avant que la donnée n’atteigne l’agent, jamais après.
Oui, et c’est là que l’exposition est aujourd’hui la plus forte. Les études sur l’usage de l’IA en entreprise montrent qu’environ 80 % des employés utilisent des outils IA non validés par l’IT, et 70 % savent que des données sensibles sont partagées avec ces outils, même sans politique formelle. L’IA fantôme échappe totalement aux contrôles RBAC et ABAC conçus pour les systèmes approuvés, ce qui explique pourquoi le rapport IBM 2026 chiffre à 5,39 millions de dollars le coût moyen d’une fuite liée à l’IA fantôme, contre 4,63 millions l’année précédente. Pour combler cette faille, il faut d’abord découvrir quels outils IA sont réellement utilisés, pas seulement ceux qui figurent sur la liste officielle.
Kiteworks Compliant AI et le Kiteworks Secure MCP Server restreignent ce qu’un agent IA ou un grand modèle de langage peut récupérer aux autorisations ABAC réelles de l’utilisateur demandeur, avant que la donnée n’atteigne le modèle, sans compter sur le modèle pour appliquer une règle décrite dans son prompt. Le Kiteworks Data Policy Engine applique cela de façon cohérente sur la messagerie électronique, le partage et le transfert de fichiers, les formulaires web et l’accès IA, avec des résultats consignés dans une traçabilité d’audit conçue pour répondre aux exigences réglementaires.
Pas totalement, et croire le contraire serait refaire l’erreur que cette approche vise à corriger. Le contrôle d’accès au niveau de la donnée régit ce qu’une requête peut récupérer une fois liée aux autorisations vérifiées d’un utilisateur ; il ne détecte pas de façon autonome une instruction malveillante cachée dans un e-mail, un document ou une page web aspirée. Les recommandations AWS préconisent une défense complémentaire : ne jamais laisser un agent cumuler accès à des données sensibles, capacité de communiquer vers l’extérieur et exposition à du contenu non fiable, car c’est ce qui transforme une injection de prompt en fuite de données. Contrôle d’accès et défense contre l’injection sont deux couches complémentaires, pas interchangeables.
Ressources complémentaires
- Article de blog
Stratégies Zero Trust pour protéger la confidentialité de l’IA à moindre coût - Article de blog
Comment 77 % des organisations échouent sur la sécurité des 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 se contentent plus de demander si vous avez une politique IA. Ils veulent des preuves de son efficacité.