Les agents IA transforment l’accès en entreprise en risque de données interne

Google News a mis en avant un avertissement plus inquiétant concernant les agents IA : la plus grande menace pour les données d’entreprise pourrait déjà disposer d’identifiants valides et d’un accès approuvé.

L’article de Dark Reading ne décrit pas une violation isolée. Il révèle un renversement plus large en matière de sécurité. Les entreprises donnent aux agents un accès interne afin qu’ils automatisent des tâches utiles. Ce même accès permet à des erreurs, des instructions hostiles ou des autorisations excessives de faire circuler des informations sensibles entre des systèmes de confiance.

Les défenses traditionnelles visent à maintenir les intrus hors du réseau. Les agents IA compliquent ce modèle, car ils opèrent souvent au sein d’applications approuvées, avec des identités légitimes et des outils autorisés. Le conflit central oppose désormais la productivité au contrôle, plutôt que les défenseurs à un attaquant externe évident.

Les lecteurs de Google News qui découvrent cette histoire devraient la considérer comme un avertissement sur la gouvernance des accès. Un agent n’a pas besoin de contourner le périmètre lorsqu’une entreprise l’a déjà connecté aux e-mails, aux documents, aux bases de données, aux navigateurs et aux API externes.

Ce que le titre de Google News signale réellement

Les agents IA transforment des erreurs d’accès ordinaires en chaînes d’actions automatisées capables de traverser plusieurs systèmes d’entreprise.

Un agent IA est un logiciel qui utilise un modèle pour planifier des tâches, sélectionner des outils et agir avec une intervention humaine limitée. Contrairement à un chatbot, il ne se contente pas de renvoyer du texte. Il peut récupérer des dossiers, envoyer des messages, modifier des fichiers, appeler des API ou déclencher des workflows.

Cette distinction modifie le problème de sécurité. Un chatbot peut révéler des informations placées dans son contexte. Un agent peut rechercher davantage d’informations, les combiner, les transformer et les déplacer ailleurs.

La préoccupation sous-jacente du titre de Google News n’est pas que les agents contiennent tous les secrets d’une entreprise. Les informations d’entreprise restent généralement dans des référentiels tels que le stockage cloud, les systèmes clients, les plateformes de code et les outils de collaboration.

Le risque provient des connexions entre ces référentiels et l’agent. Le reportage de Dark Reading sur la responsabilité partagée souligne que les entreprises restent responsables de la protection des données et des utilisateurs connectés aux services agentiques.

Cette responsabilité devient plus difficile à gérer lorsqu’un agent hérite des accès de l’utilisateur tandis qu’un autre utilise un compte de service générique. Les deux architectures peuvent créer des voies d’exposition inattendues.

Un agent limité au périmètre d’un utilisateur peut rechercher tout ce à quoi un employé a accès, y compris des dossiers partagés oubliés. Une identité de service peut détenir des privilèges plus étendus que ceux dont un utilisateur individuel a besoin.

L’agent peut également assembler des faits qui paraissent inoffensifs lorsqu’ils sont examinés séparément. Une liste de clients, une feuille de route interne et un annuaire des employés peuvent devenir hautement sensibles après agrégation.

Il s’agit d’un renversement important. La recherche d’entreprise aidait autrefois les employés à retrouver des documents qu’ils étaient déjà autorisés à lire. Un agent peut désormais trouver ces documents et effectuer des actions de suivi sans décision humaine distincte.

Le danger ne requiert pas d’intention malveillante. Une demande vague peut entraîner une recherche trop large. Un plan peu fiable peut sélectionner le mauvais destinataire ou la mauvaise destination.

Un document compromis peut également rediriger le workflow. L’injection indirecte de prompts se produit lorsque des instructions hostiles sont dissimulées dans un contenu lu par l’agent, comme un e-mail ou une page web.

Le modèle peut interpréter ces instructions comme faisant partie de sa tâche. Si ce même agent peut accéder à des données privées et communiquer vers l’extérieur, l’attaquant a relié la découverte à l’exfiltration.

C’est pourquoi cette histoire dépasse un simple titre. L’agent se trouve à l’intersection de l’identité, des données, des applications et de l’action. Chaque connexion étend ce qu’une seule défaillance peut atteindre.

Le changement immédiat est donc architectural. Les entreprises n’accordent plus seulement à des logiciels l’accès aux données. Elles accordent à des systèmes une marge de décision quant à l’usage de cet accès.

La voie d’exposition de l’intérieur vers l’extérieur

Le workflow d’agent le plus dangereux réunit du contenu non fiable, des données sensibles et une action sortante sous une même identité.

Considérez un agent chargé de préparer une revue de compte. Il lit les dossiers clients, recherche des messages internes, vérifie les cas de support récents et élabore un résumé.

Chaque étape paraît légitime. La voie d’exposition apparaît lorsqu’un élément récupéré contient des instructions destinées au modèle plutôt qu’à l’employé.

Un ticket de support malveillant pourrait demander à l’agent d’ignorer sa tâche initiale. Il pourrait diriger le système vers des dossiers supplémentaires et les transmettre via une requête web autorisée.

L’attaquant ne se connecte jamais à l’entreprise. L’agent lit le contenu de l’attaquant après son entrée par un canal métier normal.

Ce schéma d’attaque exploite une frontière que les modèles de langage ne peuvent pas imposer de manière fiable à eux seuls. Un même contexte peut contenir des instructions utilisateur, des faits récupérés, des directives système et du texte contrôlé par un attaquant.

Les modèles traitent ces éléments comme du langage. L’étiquetage et les prompts peuvent aider, mais ils ne créent pas une barrière d’autorisation déterministe.

Les outils de l’agent rendent cette faiblesse conséquente. Une instruction empoisonnée a peu de valeur lorsque le modèle ne peut pas atteindre des données privées ni agir hors de la session.

Le risque augmente lorsque les développeurs fournissent des outils très larges par souci de commodité. Un navigateur généraliste, un connecteur de base de données sans restriction, un shell ou une fonction de messagerie peuvent servir de nombreux workflows. Ils peuvent aussi permettre des actions que la fonctionnalité d’origine n’a jamais exigées.

OWASP identifie ce problème comme une autonomie excessive. Ses exemples incluent des tâches en lecture seule prises en charge par des extensions qui peuvent aussi modifier, supprimer ou envoyer des informations.

Les autorisations ajoutent une autre couche. Un connecteur destiné à lire une table de produit ne devrait pas recevoir d’accès en écriture ni de visibilité sur des dossiers sans rapport.

Les comptes génériques privilégiés sont particulièrement risqués. Ils peuvent effacer la distinction entre ce qu’un utilisateur individuel peut demander et ce que l’infrastructure de l’agent peut récupérer.

La mémoire élargit la fenêtre d’exposition. La mémoire d’un agent stocke des faits ou du contexte pour une utilisation ultérieure, ce qui aide à maintenir la continuité entre les sessions.

Cependant, une mémoire persistante peut conserver des instructions empoisonnées, du matériel confidentiel ou une hypothèse de sécurité erronée. Un problème introduit lors d’une tâche peut influencer un autre utilisateur ou workflow ultérieurement.

Les journaux peuvent devenir un second référentiel de données. Des traces détaillées aident les équipes à enquêter sur les décisions d’un agent, mais elles peuvent contenir des prompts, des documents récupérés, des identifiants ou des informations personnelles.

Une équipe peut ainsi réduire un risque tout en en créant un autre. Des données d’observabilité mal protégées deviennent une cible précieuse, car elles consignent ce que l’agent a vu et tenté de faire.

Les systèmes multi-agents ajoutent davantage de transferts. Un agent peut collecter des informations, un deuxième les analyser et un troisième communiquer le résultat.

Chaque transfert requiert des identités authentifiées, des autorisations limitées et des données validées. Sinon, un composant compromis peut transmettre des instructions nuisibles en aval sous l’apparence d’un trafic interne de confiance.

L’attaquant externe reste pertinent, mais l’action finale se produit depuis l’intérieur de l’entreprise. Elle provient d’une identité approuvée et suit un chemin applicatif que les défenseurs peuvent considérer comme normal.

C’est le problème de l’intérieur vers l’extérieur. La défaillance de sécurité commence par un accès légitime, franchit des frontières internes de données et sort par un outil autorisé.

Pourquoi les équipes identité subissent la première pression

Les agents IA se comportent comme des utilisateurs, s’authentifient comme des services et opèrent plus vite que les processus de gouvernance conçus pour l’un ou l’autre groupe.

Les systèmes d’accès humains supposent un employé identifiable, un rôle professionnel, un responsable et un cycle de vie d’emploi. Les comptes de service prennent généralement en charge des logiciels prévisibles aux fonctions stables.

Les agents ne correspondent à aucune de ces catégories. Leurs actions évoluent avec les prompts, le contexte récupéré, les outils disponibles, les versions de modèles et les résultats intermédiaires.

Un agent peut s’authentifier avec un jeton API, agir pour un employé et déléguer une partie d’une tâche à un autre agent. Cela crée plusieurs identités au sein d’un même workflow.

Les équipes de sécurité doivent savoir qui a initié la demande. Elles doivent également savoir quel agent a agi, quels identifiants il a utilisés et quelle autorisation s’appliquait.

Une action finale devrait rester attribuable à ces identités. Sans cette chaîne, les intervenants en cas d’incident peuvent voir un appel API autorisé sans comprendre le raisonnement ni l’intention utilisateur qui le sous-tendent.

NIST a reconnu cette lacune dans son projet de 2026 sur l’identité des agents. Les travaux proposés portent sur l’identification, l’autorisation, l’audit et la non-répudiation des agents logiciels.

Ces exigences ressemblent à des pratiques établies en matière d’identité, mais les agents modifient le rythme de fonctionnement. Une revue d’accès trimestrielle ne peut pas contenir des privilèges devenus inutiles quelques minutes après la fin d’une tâche.

Les accès permanents créent un problème d’accumulation. Les équipes accordent une autorisation pour un pilote, la conservent par commodité, puis connectent plus tard l’agent à un autre système.

La portée effective de l’agent s’accroît même lorsqu’aucun administrateur ne crée intentionnellement un super-agent privilégié. Des autorisations distinctes peuvent se combiner pour former une voie dangereuse.

Par exemple, l’accès en lecture à une base de données peut paraître sûr à lui seul. Un accès web externe peut également prendre en charge une tâche de recherche légitime.

Ensemble, ces capacités peuvent permettre à des dossiers sensibles de quitter l’organisation. Les équipes de sécurité qualifient souvent cette combinaison de toxique, car le risque total dépasse celui de chaque autorisation considérée isolément.

La pression repose également sur les propriétaires d’applications. Ils doivent exposer des fonctions plus étroites plutôt que de fournir aux agents des interfaces administratives génériques.

Un agent de planification peut avoir besoin de créer des réservations dans le calendrier. Il n’a pas nécessairement besoin d’être autorisé à supprimer chaque événement ni à lire les notes privées de chaque participant.

Les propriétaires de données font face à une décision connexe. Ils doivent déterminer si les autorisations utilisateur existantes restent appropriées lorsqu’un logiciel peut rechercher, résumer et redistribuer des informations à la vitesse d’une machine.

Un employé qui peut techniquement ouvrir des milliers de documents les examinera rarement tous. Un agent peut parcourir rapidement cet accès et supprimer la friction pratique qui limitait autrefois l’exposition.

Cela ne signifie pas que chaque agent mérite moins d’accès que son utilisateur. Cela signifie que l’autorisation doit tenir compte de la tâche demandée, de la destination, de la sensibilité des données et de l’action proposée.

Le contrôle d’accès statique basé sur les rôles ne peut pas exprimer toutes ces conditions. Les entreprises ont besoin de contrôles de politique tout au long du workflow, en particulier avant une récupération sensible ou une communication externe.

Google News amplifie un enjeu de sécurité qui traverse les responsabilités organisationnelles. Les équipes identité contrôlent les identifiants, les équipes applicatives créent les outils et les équipes données classifient les informations.

Les responsables des programmes IA contrôlent souvent la vitesse de déploiement. Lorsque ces groupes travaillent indépendamment, l’agent hérite de leurs lacunes et les relie en un seul chemin d’exécution.

Les promesses de productivité se heurtent désormais à la réalité de la sécurité

Les agents deviennent plus utiles à mesure qu’ils gagnent en contexte et en autorité, mais ces mêmes caractéristiques augmentent les dommages causés par une manipulation ou une erreur.

Un agent d’entreprise utile doit en savoir suffisamment pour accomplir un travail réel. Il lui faut accéder aux systèmes pertinents, comprendre le contexte utilisateur et avoir l’autorité d’exécuter les actions approuvées.

La suppression de ces capacités produit un chatbot plus sûr, mais limité. Leur extension produit un collaborateur performant dont les erreurs peuvent avoir des conséquences opérationnelles.

C’est le principal compromis mis en lumière par l’article de Dark Reading. L’objectif n’est pas d’éliminer l’autonomie des agents, mais d’empêcher qu’elle ne devienne une autorité sans limites.

Les contrôles de sécurité peuvent réduire le risque, mais aucun ne fournit à lui seul une réponse complète. Les filtres de prompts peuvent détecter un langage malveillant connu, mais les attaquants peuvent encoder ou dissimuler leurs instructions.

Les garde-fous fondés sur les modèles se heurtent à une limite plus profonde. Ils utilisent des systèmes probabilistes pour évaluer un autre système probabiliste, et des faiblesses similaires peuvent affecter les deux couches.

L’approbation humaine aide lorsqu’une action est rare et lourde de conséquences. Elle devient moins utile lorsque les employés approuvent régulièrement des demandes denses qu’ils ne peuvent pas examiner de manière significative.

Les invites d’approbation doivent également fournir des informations claires. Un utilisateur ne peut pas évaluer une action décrite uniquement comme « poursuivre le flux de travail » ou « utiliser le connecteur ».

L’interface devrait identifier la ressource, l’opération, le destinataire et la catégorie de données. Elle devrait aussi expliquer pourquoi l’action demandée découle de la tâche initiale.

Le principe du moindre privilège réduit les dommages possibles. Cependant, définir le moindre privilège pour un flux de travail évolutif en plusieurs étapes est plus difficile que de délimiter une application traditionnelle.

Les autorisations peuvent être appropriées à une étape et excessives à la suivante. Des identifiants temporaires, liés à une tâche, offrent un meilleur modèle qu’un accès persistant.

La surveillance à l’exécution fournit une autre couche. Elle peut détecter un volume de récupération inhabituel, de nouvelles destinations, des combinaisons d’outils atypiques ou un comportement qui s’écarte de la référence de l’agent.

Toutefois, la détection d’anomalies nécessite un historique, du contexte et une attribution fiable. Un nouvel agent peut ne pas disposer d’une référence stable, tandis que les flux de travail légitimes peuvent varier fortement.

Dark Reading a rapporté une recherche de Gartner suggérant qu’environ 90 % des agents actuels ont une faible autonomie. Les 10 % restants disposent d’outils plus étendus, d’un accès plus large aux données et d’une plus grande latitude à l’exécution.

Ces systèmes à forte autonomie méritent des contrôles ciblés, car leurs modes de défaillance vont au-delà d’un texte erroné. Ils peuvent modifier des systèmes de production ou déplacer des données confidentielles.

Le même rapport citait une enquête menée par un fournisseur auprès de plus de 400 responsables de la technologie et de la sécurité. Elle a révélé que 84 % estimaient que leurs agents pouvaient accéder à des données sensibles.

67 % supplémentaires pensaient que des agents avaient accédé à des informations auxquelles ils n’auraient pas dû avoir accès. Ces chiffres proviennent d’une enquête d’un fournisseur de sécurité ; ils indiquent donc une préoccupation plutôt qu’un taux d’incident universel.

Néanmoins, les résultats correspondent au risque architectural. Les entreprises connectent souvent des agents avant de disposer d’un inventaire complet des identités, des outils, des chemins de données et des autorisations héritées.

Le point de vue sceptique est également nécessaire. Tous les agents ne représentent pas une nouvelle catégorie de menace catastrophique.

De nombreux risques ressemblent à des défaillances familières impliquant des comptes de service, des privilèges excessifs, des intégrations non sécurisées et une faible gouvernance des données. Des contrôles éprouvés mieux appliqués peuvent en prévenir une grande partie.

Ce qui change, c’est la combinaison. Les agents choisissent leurs actions de manière dynamique et traitent un langage contrôlé par l’attaquant, tandis que les intégrations traditionnelles suivent des chemins de code prédéterminés.

Cette différence rend le comportement moins prévisible. Elle rend également la qualité de l’autorisation à l’exécution plus importante que celle de la connexion initiale.

Les contrôles qui limitent l’exposition des données par les agents

Les entreprises ont besoin de contrôles déterministes autour du modèle, car les instructions à l’intérieur du modèle ne peuvent pas faire respecter leur propre autorité.

La première exigence est un inventaire des agents. Les équipes de sécurité ne peuvent pas gouverner des identités, connecteurs, outils et magasins de données dont elles ignorent l’existence.

L’inventaire devrait inclure les agents en production, les projets pilotes internes, les applications de fournisseurs et les assistants installés par les employés. Il devrait également recenser les projets abandonnés dont les identifiants restent actifs.

Chaque agent a besoin d’une identité distincte. Les clés API partagées masquent l’attribution et compliquent la révocation.

L’identité devrait être associée à un propriétaire, un objectif approuvé, un modèle, un ensemble d’outils et un état de cycle de vie. Les entreprises devraient la désactiver lorsque le projet prend fin ou que son propriétaire quitte l’organisation.

La deuxième exigence est une autorisation limitée à la tâche. Les décisions d’accès devraient évaluer ce que l’utilisateur a demandé et l’action que l’agent propose désormais.

Une demande de synthèse d’un dossier ne devrait pas autoriser une recherche dans chaque dépôt. Une demande de rédaction d’un e-mail ne devrait pas autoriser automatiquement son envoi.

La troisième exigence est la séparation entre la lecture et l’action. Les agents qui traitent du contenu non fiable ne devraient pas contrôler automatiquement des outils à fort impact.

Les conseils de sécurité des agents de l’OWASP recommandent un accès minimal aux outils, une mémoire isolée, une revue humaine des actions risquées et une surveillance structurée.

Une option architecturale consiste à utiliser des composants séparés. Un modèle restreint lit le contenu externe, tandis qu’un composant privilégié ne reçoit que des informations validées et structurées.

Cette approche n’élimine pas la manipulation, mais elle rompt le chemin direct entre un texte hostile et une action autorisée.

La quatrième exigence est une application tenant compte des données. Un outil devrait évaluer la classification des informations demandées avant de les renvoyer.

Le point d’application devrait se situer en dehors du modèle. Le modèle peut proposer une requête, mais une politique déterministe devrait décider quels enregistrements et champs deviennent disponibles.

Les entreprises devraient également préserver le contexte de sécurité de l’utilisateur. Un agent agissant pour un employé ne devrait pas basculer silencieusement vers une identité de service plus large.

L’accès en lecture seule devrait être la règle par défaut lorsque cela est possible. Les fonctions d’écriture, de suppression, d’envoi, de publication et de paiement devraient nécessiter des périmètres plus étroits et des contrôles plus stricts.

La cinquième exigence est le contrôle des destinations. Les organisations se concentrent souvent sur ce qu’un agent peut lire, tout en négligeant où il peut envoyer le résultat.

Des domaines autorisés, des destinataires approuvés, l’inspection du contenu et des chemins réseau restreints peuvent limiter l’exfiltration. Ces contrôles restent utiles même lorsque les défenses contre les prompts échouent.

La sixième exigence est une mémoire protégée. Les informations sensibles ne devraient pas entrer dans la mémoire à long terme sans objectif défini, période de conservation et limite d’accès.

La mémoire devrait rester isolée entre les utilisateurs et les espaces de travail. Les équipes devraient analyser le contexte stocké à la recherche d’identifiants, d’informations personnelles et d’instructions suspectes.

La septième exigence est une observabilité significative. Les journaux devraient enregistrer la demande de l’utilisateur, l’identité de l’agent, l’appel d’outil, la décision d’autorisation, la catégorie de données et le résultat de l’action.

Ils ne devraient pas recopier chaque secret en texte clair. La suppression des données sensibles et un accès contrôlé sont essentiels, car les dossiers d’enquête peuvent devenir une autre surface d’exposition.

Une base de connaissances consultable a également besoin d’autorisations claires sur les sources et de limites de récupération. La commodité de la recherche ne devrait pas effacer les règles d’accès au niveau des documents.

Enfin, les équipes doivent tester le flux de travail complet. Les évaluations de modèles seules ne peuvent pas révéler ce qui se produit lorsque l’identité, la récupération, la mémoire, les outils et le contenu externe interagissent.

Les équipes red devraient utiliser des documents empoisonnés, des e-mails trompeurs, des demandes excessives, des tests de mémoire entre utilisateurs et des destinations non autorisées. Elles devraient répéter les tests après toute modification du modèle, du prompt, du connecteur ou de la politique.

Trois signaux à surveiller après cet avertissement de Google News

Le prochain test consistera à déterminer si les entreprises remplacent l’accès large et permanent des agents par une autorité visible, temporaire et applicable.

Le premier signal est l’adoption d’identités spécifiques aux agents. Microsoft et d’autres fournisseurs de plateformes ajoutent des moyens d’enregistrer les agents, d’attribuer des autorisations et de consigner leur comportement.

L’enregistrement seul ne suffit pas. Le changement significatif viendra lorsque les entreprises pourront retracer chaque action via l’agent, l’utilisateur initiateur, l’identifiant et le service délégué.

Si ces enregistrements apparaissent dans les systèmes standards de gouvernance des identités et de réponse aux incidents, le risque interne deviendra plus facile à examiner. Une dépendance persistante aux jetons partagés affaiblirait ces progrès.

Le deuxième signal est l’application des règles à l’exécution. Les équipes de sécurité ont besoin de contrôles capables de refuser un appel d’outil sans arrêter l’agent entier.

Surveillez les identifiants liés à une tâche, les courtes fenêtres d’autorisation, les politiques tenant compte des données et les invites d’approbation qui identifient l’opération proposée. Ces capacités renforceraient l’idée que l’autonomie peut coexister avec le contrôle.

Les promesses marketing concernant des « agents sécurisés » apportent peu de preuves à elles seules. Les acheteurs devraient demander si l’autorisation intervient en dehors du modèle et si les politiques s’appliquent à chaque demande en aval.

Le troisième signal est la preuve publique d’incidents. Le marché manque encore de rapports cohérents sur les défaillances d’agents, les quasi-incidents et l’exposition de données.

Les divulgations utiles devraient décrire l’entrée initiale, les outils disponibles, les autorisations effectives, les garde-fous défaillants et l’impact final. Des affirmations agrégées sans ces détails ne peuvent pas montrer si les nouveaux contrôles fonctionnent.

Les régulateurs et les organismes de normalisation comptent également ici. Le travail de NIST sur les normes pour les agents peut donner aux entreprises un langage commun pour l’identité, l’autorisation et l’auditabilité.

Google News continuera de faire remonter des avertissements à mesure que les fournisseurs placent des agents dans davantage de flux de travail. Les lecteurs devraient aller au-delà des titres spectaculaires et examiner le chemin d’accès derrière chaque événement.

Posez trois questions avant de faire confiance à un agent d’entreprise : que peut-il lire, que peut-il faire et où peut-il envoyer le résultat ?

Si l’organisation ne peut pas répondre à ces trois questions à partir de politiques applicables et de dossiers auditables, l’agent n’est pas simplement un assistant. C’est une identité interne sans limites qui attend la mauvaise instruction.