Agentic AI Security : le contexte, nouvelle surface d’attaque
Des agents autonomes basés sur l’IA interviennent déjà dans votre environnement de sécurité – et, dans de nombreux cas, ils agissent à partir de mauvaises données. Ce n’est pas un risque hypothétique enfoui dans un modèle de menace. C’est une réalité opérationnelle que des chercheurs en sécurité documentent dans des systèmes en production, où des agents IA chargés de la remédiation autonome aggravent les incidents, contournent les contrôles et manipulent des objets de données auxquels ils n’auraient jamais dû accéder. Le mode d’échec est d’une simplicité trompeuse : fournissez à un agent IA un contexte incomplet ou erroné, et il prendra de mauvaises décisions – à la vitesse de la machine, sans intervention humaine pour corriger l’erreur.
Une analyse de SecurityWeek publiée le 24 juin 2026 examine précisément ce problème – ce que les chercheurs appellent désormais le « manque de contexte » dans les déploiements d’IA agentique. L’article s’appuie sur des entretiens avec des experts et architectes sécurité confrontés à des applications SOC autonomes où des agents IA exécutent des actions de remédiation sans vérifier correctement les données sur lesquelles ils interviennent. On découvre ainsi une technologie déployée plus vite que ne progresse sa maturité décisionnelle.
Tout cela est bien réel. Le rapport annuel Kiteworks 2026 sur les risques liés à la sécurité et à la conformité des données révèle que la gouvernance de l’IA figure parmi les principales préoccupations des responsables sécurité et conformité cette année, et l’analyse de SecurityWeek explique pourquoi. Quand des agents IA opèrent sans couche de gouvernance pour contrôler leur accès aux données, chaque contenu sensible auquel ils accèdent devient un point de défaillance potentiel. Le contexte dans lequel travaille un agent IA n’est pas qu’une donnée technique – il constitue en réalité le périmètre de sécurité. Pour la plupart des organisations aujourd’hui, ce périmètre reste sans protection.
Comprendre pourquoi cela se produit – et quelles architectures permettent de combler ce manque – est la question la plus urgente en matière de sécurité de l’IA d’entreprise aujourd’hui.
Résumé des points clés
1. Le contexte est la nouvelle surface d’attaque.
Dans les systèmes d’IA agentique, les données auxquelles un agent peut accéder et agir définissent la limite de ce qui peut mal tourner. Les chercheurs documentent des cas où des lacunes de contexte ont conduit des systèmes autonomes à aggraver des incidents, contourner des contrôles ou agir sur de mauvais objets de données.
2. La maturité décisionnelle de l’IA n’a pas suivi le rythme des déploiements.
Les organisations déploient des agents IA autonomes – notamment dans les environnements SOC – à une vitesse qui dépasse les cadres de gouvernance nécessaires pour garantir leur fonctionnement sûr et prévisible.
3. Les mauvaises décisions se prennent à la vitesse de la machine.
Le danger de l’IA agentique ne réside pas seulement dans la possibilité d’une mauvaise décision ; il tient au fait que ces erreurs se produisent avant qu’un humain puisse intervenir. Chaque action autonome prise sur un mauvais contexte accroît le risque.
4. Un accès non contrôlé aux données par l’IA est un risque opérationnel, pas théorique.
Tous les échecs documentés remontent à un agent IA intervenant sur des données auxquelles il n’aurait pas dû accéder – ou sur une mauvaise version de données, faute de couche de gouvernance pour contrôler ce qui entre dans le flux de travail de l’IA.
5. Les garde-fous architecturaux doivent précéder le déploiement des agents IA.
Définir ce que l’agent IA peut voir et manipuler – avant toute prise de décision – constitue l’exigence technique essentielle pour garantir la sécurité de l’IA agentique dans les environnements réglementés et sensibles.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le vérifier ?
Pour en savoir plus :
Que signifie « contexte » dans les systèmes d’IA agentique ?
Dans un système logiciel traditionnel, le périmètre d’action d’une application est défini à la conception – logique codée, autorisations fixes, entrées de données explicites. Les systèmes d’IA agentique fonctionnent différemment. Ils observent dynamiquement le contexte, analysent ce qu’ils trouvent et décident de la suite sans instruction humaine explicite à chaque étape. Cette adaptabilité fait leur valeur. Mais elle devient dangereuse si le contexte de départ est erroné.
Voyons ce que cela implique dans une application SOC autonome. Un agent IA doit trier les alertes de sécurité et, si certaines conditions sont réunies, lancer la remédiation. Ce modèle de déploiement est pertinent – le tri prend du temps, et la rapidité compte en gestion d’incident. Mais sur quelles données l’agent se base-t-il ? Quelle version du fichier de configuration ? Quel journal d’activité utilisateur ? Quel enregistrement d’un endpoint ? Si l’une de ces entrées est obsolète, incomplète ou mal aiguillée, la « bonne » décision de l’agent, basée sur ce qu’il voit, peut s’avérer catastrophique dans la réalité.
L’article de SecurityWeek relate des cas concrets où ce mode d’échec s’est matérialisé : des agents ont transformé des événements mineurs en incidents majeurs faute de contexte indiquant qu’il s’agissait d’un faux positif connu ; d’autres ont agi sur de mauvais objets de données à cause d’incohérences de nommage entre référentiels ; certains ont contourné des contrôles humains parce que leur fenêtre de contexte montrait une revue terminée qui n’avait en réalité jamais eu lieu. À chaque fois, l’agent faisait ce pour quoi il avait été conçu. Le problème venait des données.
C’est pourquoi la gouvernance des données est devenue un enjeu fondamental de la sécurité de l’IA – et non un simple critère de conformité. La couche de gouvernance qui contrôle quelles données alimentent le contexte de l’agent IA constitue, en pratique, le contrôle de sécurité qui évite ces défaillances. Sans elle, le risque s’accroît à chaque action autonome. La classification des données – étiqueter le contenu selon sa sensibilité avant toute entrée dans un flux IA – est le prérequis pour rendre la gouvernance du contexte applicable : un moteur de règles ne peut restreindre ce qu’il n’a pas catégorisé.
Le problème de la vitesse de déploiement
Il existe une tension structurelle au cœur de l’adoption de l’IA agentique. Les arguments en faveur des agents IA autonomes – réduction du temps moyen de détection, remédiation plus rapide, moindre épuisement des analystes – sont suffisamment convaincants pour que les organisations les déploient rapidement. Mais l’infrastructure de gouvernance nécessaire à leur fonctionnement sécurisé prend du temps à construire. Quand la vitesse de déploiement dépasse la maturité de la gouvernance, on comble le vide par des suppositions : les données reçues par l’agent sont censées être exactes, complètes et adaptées à la décision à prendre.
Les experts en protection des données IA alertent sur ce décalage depuis des années. L’analyse de SecurityWeek confirme que l’alerte n’est plus théorique, mais opérationnelle. Le SOC autonome n’est plus un simple concept – il fonctionne en production dans des organisations qui n’ont pas encore répondu à la question fondamentale : quelle couche de gouvernance contrôle ce que l’agent peut voir ? Le Shadow AI – outils IA non gouvernés déployés par des collaborateurs ou équipes hors du périmètre officiel – aggrave ce problème en créant des accès aux données IA que la politique d’entreprise ne surveille ni ne contrôle.
Les plateformes SOAR ont été confrontées à une version de ce problème pendant des années : automatisation trop large, sur de mauvaises données, sans points de contrôle humains pour éviter les erreurs en cascade. L’IA agentique élève considérablement les enjeux, car la prise de décision est plus complexe, l’autonomie plus grande et la vitesse plus élevée.
Pourquoi les contrôles d’accès aux données sont la solution centrale
Si le contexte est la surface d’attaque, alors contrôler les données auxquelles un agent IA peut accéder devient l’architecture défensive principale. Les contrôles d’accès et les autorisations basées sur les rôles régissent l’accès des utilisateurs humains depuis des décennies. Appliquer ces principes aux agents IA nécessite une couche dédiée capable de distinguer les données qu’un agent doit voir de celles auxquelles il ne doit pas accéder – et d’imposer cette limite avant toute action. Le contrôle d’accès basé sur les attributs (ABAC) – où la décision d’accès évalue la sensibilité du contenu, le rôle de l’agent et le contexte du flux de travail en même temps – est plus précis que le simple contrôle basé sur les rôles, et mieux adapté à la nature dynamique et multi-étapes des workflows IA agentiques.
C’est précisément ce que propose Kiteworks Compliant AI. Cette solution s’intercale entre les référentiels de données de l’entreprise et les agents IA, applique les règles sur les données accessibles à chaque agent, filtre le contenu sensible avant son entrée dans un flux IA, et garantit que le « contexte » reçu par l’agent est à la fois exact et conforme aux politiques. Elle transforme le « on suppose que les données sont fiables » en « on vérifie avant que l’agent ne les voie ».
Les chercheurs de SecurityWeek sont clairs sur ce point : il s’agit d’une exigence architecturale, pas d’une solution de monitoring. On ne peut pas corriger a posteriori une mauvaise décision prise à la vitesse de la machine. Il faut empêcher la mauvaise décision en contrôlant ce que l’agent sait avant qu’il n’agisse.
Les cadres de gouvernance des données IA qui appliquent ce principe diffèrent des architectures d’accès traditionnelles. Il ne s’agit plus seulement de restreindre qui peut ouvrir un fichier – il s’agit de définir quel contexte est autorisé pour un agent donné, dans un workflow donné, à un moment donné. Cela exige des moteurs de règles qui comprennent le contenu, pas seulement l’identité ; qui appliquent les règles de classification en temps réel ; et qui conservent des journaux d’audit de chaque objet de données consulté par un agent – pour savoir exactement ce que l’agent a vu en cas d’incident. Alimenter ces journaux en temps réel dans un SIEM donne aux équipes sécurité la capacité de détecter les accès anormaux d’agents avant qu’une mauvaise décision ne provoque une défaillance opérationnelle majeure.
Le problème des données sensibles dans les workflows agentiques
Le mode d’échec s’aggrave quand les données concernées sont sensibles. Un agent IA qui manipule des fichiers de production contenant des identifiants, des dossiers médicaux ou des informations personnelles identifiables ne risque pas seulement de prendre une mauvaise décision – il risque de le faire sur des données exposant à des conséquences juridiques, réglementaires et réputationnelles. Une fuite de données provoquée par un agent autonome agissant sur le mauvais objet de données entraîne les mêmes obligations de notification, sanctions réglementaires et conséquences réputationnelles qu’une fuite humaine – avec la difficulté supplémentaire que la chaîne de décision de l’agent est parfois plus difficile à reconstituer que celle d’un acteur humain.
L’analyse de SecurityWeek se concentre sur les environnements SOC, mais le même mode d’échec s’applique partout où un système IA agentique traite du contenu sensible : un agent IA qui relit des documents juridiques, un système automatisé qui traite des dossiers financiers, un assistant de codage IA ayant accès à des dépôts de code source contenant de la propriété intellectuelle. À chaque fois, la question reste la même : le contenu reçu par l’agent est-il adapté au workflow qu’il exécute ?
Les contrôles DLP étaient historiquement appliqués au périmètre – pour intercepter les données sensibles avant leur sortie de l’organisation. L’IA agentique impose une nouvelle exigence : des contrôles qui opèrent à l’intérieur du flux de données, régulant ce qui entre dans un workflow IA avant que l’agent ne le traite. Les professionnels interrogés dans l’article de SecurityWeek parlent d’un problème de gouvernance « content-as-context » – et sa résolution exige une architecture différente du DLP périmétrique traditionnel. La minimisation des données appliquée à la frontière entre la donnée et l’agent – ne transmettre que les champs et enregistrements strictement nécessaires à la mission de l’agent – réduit l’impact de toute lacune de contexte.
Le modèle d’échange sécurisé des données répond à cette problématique en considérant que tout contenu transitant dans les workflows IA est soumis aux mêmes contrôles de gouvernance que tout autre échange de données sensibles. Cela implique chiffrement en transit et au repos, contrôles d’accès imposés par des règles, et journalisation – non seulement pour la conformité, mais aussi parce que les principes de zero trust architecture s’appliquent aux agents IA comme aux utilisateurs humains.
Construire la gouvernance avant de déployer les agents
La leçon pratique de l’analyse SecurityWeek est claire : il faut bâtir l’infrastructure de gouvernance avant de déployer les agents – et non après. Ce séquençage va à l’encontre de la pression visant à gagner en efficacité grâce à l’IA, mais les professionnels cités dans l’article sont formels : déployer des agents dans des environnements de données non contrôlés et ajouter la gouvernance ensuite, c’est accepter les conséquences des mauvaises décisions entre-temps.
Concrètement : inventorier les référentiels de données auxquels l’agent aura accès, classifier ces données, définir les sous-ensembles réellement nécessaires à la mission de l’agent, mettre en place des contrôles qui imposent ces limites, et instaurer une journalisation permettant de prouver ce à quoi l’agent a accédé et quand. Ce n’est pas une simple liste de tâches – c’est une décision d’architecture qui façonne tout le système agentique. Les organisations soumises à des cadres de conformité réglementaire – HIPAA, CMMC, RGPD – doivent considérer la gouvernance de l’accès aux données des agents IA comme une extension des mêmes contrôles qui régissent l’accès des utilisateurs humains : l’obligation réglementaire ne fait pas de distinction entre un humain et un agent qui traite des données réglementées.
Les cadres Compliant AI traitent chaque workflow IA comme un échange de données gouverné, avec les mêmes exigences de traçabilité pour le contenu passant par un agent IA que pour celui partagé entre humains. Le Secure MCP Server de Kiteworks étend ce modèle de gouvernance à l’utilisation d’outils par les agents IA – garantissant que lorsqu’un agent IA sollicite un outil ou service externe, cette interaction est soumise aux mêmes règles que l’accès principal aux données.
Les principes du zero trust generative AI permettent d’obtenir des systèmes plus faciles à auditer en cas d’incident – et plus aptes à prévenir les erreurs en amont. Le principe est simple : ne jamais supposer que les données reçues par l’agent sont adaptées ; toujours vérifier, toujours appliquer les règles, toujours journaliser. Appliqué systématiquement à chaque objet de données dans chaque workflow IA, ce modèle comble le manque de contexte documenté aujourd’hui dans les environnements de production.
Le Réseau de données privé Kiteworks réunit ces contrôles : un environnement gouverné pour l’accès des agents IA aux données, appliquant des règles de niveau entreprise, du filtrage de contenu et de l’audit à chaque objet de données entrant dans un workflow IA. Le tableau de bord RSSI offre une visibilité en temps réel sur tous les accès de données médiés par l’IA, donnant aux équipes sécurité la surface de détection nécessaire pour repérer les comportements anormaux d’agents avant qu’ils n’aient des conséquences opérationnelles. Pour les organisations qui déploient des agents SOC autonomes, des assistants de codage ou des systèmes de relecture documentaire, cela constitue la base architecturale que l’article de SecurityWeek identifie comme manquante dans la plupart des déploiements actuels.
Pour en savoir plus sur la gouvernance de l’accès aux données des agents IA dans les environnements réglementés, réservez votre démo sans attendre !
Foire aux questions
Le manque de contexte désigne l’écart entre ce qu’un agent IA croit vrai de son environnement – selon les données reçues – et la réalité. Quand le contexte d’un agent est incomplet, obsolète ou issu de mauvais objets de données, il prend des décisions cohérentes en interne mais erronées sur le plan opérationnel. Les chercheurs en sécurité ont documenté ce mode d’échec dans des déploiements SOC autonomes, où des agents ont exécuté des actions de remédiation sur la base de données de configuration obsolètes ou agi sur le mauvais système à cause d’incohérences de nommage entre référentiels. Gouverner les données qui entrent dans le contexte de l’agent avant toute action est la solution architecturale. Kiteworks Compliant AI applique ces politiques de gouvernance du contenu à la frontière entre la donnée et l’agent. La classification des données est le contrôle fondamental qui rend cette application possible : un moteur de règles ne peut restreindre un contenu qu’il n’a pas catégorisé. Découvrez-en plus sur les cadres de gouvernance des données IA conçus pour traiter ce problème à la racine.
Le zero trust architecture s’applique aux agents IA selon le même principe que pour les utilisateurs humains : ne jamais faire confiance, toujours vérifier. Concrètement, un agent IA ne reçoit aucun accès implicite à un référentiel de données selon son rôle ou son origine – il doit satisfaire aux règles pour chaque objet de données demandé, dans chaque contexte où il opère. Cela marque une rupture avec de nombreux déploiements actuels, où les agents bénéficient d’un accès large aux données en supposant qu’ils en feront bon usage. Les cadres de protection des données zero trust étendent ce principe au contenu : chaque objet entrant dans un workflow IA est classifié, filtré et journalisé avant d’être accessible à l’agent. Les politiques ABAC, qui évaluent la sensibilité du contenu, le rôle de l’agent et le contexte du workflow à chaque requête, constituent la mise en œuvre technique du zero trust au niveau des données IA.
Les applications SOC autonomes opèrent dans des environnements où la rapidité est un atout – l’objectif étant de réduire les temps de détection et de réponse. Cette exigence pousse à déployer des agents avec un accès large aux données et peu de vérifications préalables, en supposant que toute friction dans le workflow de l’agent ralentit la réponse. Mais cet avantage disparaît dès qu’un agent exécute une mauvaise action de remédiation, car réparer les conséquences d’une mauvaise décision automatisée prend bien plus de temps que l’action initiale. Les journaux d’audit retraçant chaque objet de données consulté par un agent sont essentiels pour reconstituer ce qui s’est passé. Les contrôles d’accès limitant le périmètre de l’agent avant déploiement empêchent la mauvaise action en amont. Un plan de réponse aux incidents documenté, couvrant explicitement les scénarios de défaillance d’agents autonomes – avec procédures de retour arrière et seuils d’escalade humaine – complète ces contrôles architecturaux.
L’infrastructure de gouvernance doit précéder le déploiement des agents, et non l’inverse. La séquence concrète : inventorier les référentiels de données accessibles à l’agent, classifier ces données, définir le sous-ensemble minimal nécessaire à sa mission, mettre en place des contrôles imposés par des règles pour limiter l’accès à ce sous-ensemble, et instaurer une journalisation avant la mise en production de l’agent. Les organisations qui déploient d’abord et ajoutent la gouvernance ensuite s’exposent au risque de mauvaises décisions durant la période entre déploiement et mise en place de la gouvernance – une période qui, à la vitesse de la machine, peut causer d’importants dégâts. Kiteworks Compliant AI fournit l’infrastructure de gouvernance qui rend ce séquençage possible. Les organisations soumises à des obligations de conformité réglementaire doivent également documenter les limites d’accès aux données des agents IA dans leurs dossiers d’évaluation des risques – les régulateurs interprètent de plus en plus les exigences de protection des données comme s’appliquant aussi au traitement automatisé par l’IA, et cette documentation sert de preuve en cas d’audit ou d’enquête sur une fuite de données. Consultez le rapport annuel Kiteworks 2026 sur les risques liés à la sécurité et à la conformité des données pour voir comment les organisations priorisent la gouvernance IA dans tous les secteurs.
Les exigences de journalisation pour l’accès aux données par les agents IA doivent être équivalentes à celles appliquées aux utilisateurs humains dans les environnements réglementés : un enregistrement complet, infalsifiable, de chaque objet de données consulté par l’agent, du moment d’accès, de l’action entreprise et de la règle ayant autorisé cet accès. Ce niveau de journalisation a deux objectifs : permettre l’investigation en cas d’incident – pour reconstituer exactement ce que l’agent a vu avant une action problématique – et fournir la traçabilité exigée par des cadres comme le RGPD ou HIPAA, de plus en plus interprétés comme s’appliquant aussi au traitement automatisé des données personnelles et sensibles. Les cadres Compliant AI intègrent cette infrastructure d’audit dans la couche d’accès aux données IA, de sorte que le journal existe par conception et non a posteriori. L’intégration de ces journaux à une plateforme SIEM donne aux équipes sécurité la capacité de détecter en temps réel les accès anormaux d’agents avant qu’ils ne dégénèrent en incident à déclarer.
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 des preuves de son efficacité.