Les agents d'IA compromettent la sécurité des données : voici comment y remédier.

Le plan de sécurité des données que la plupart des entreprises appliquent aujourd'hui a été conçu pour un monde où l'humain était l'identité principale. Un utilisateur est authentifié dans un système et accède aux données en fonction des contrôles d'autorisation. Chaque contrôle significatif, applicable à de multiples domaines, y compris DLP, DSPMIAM, ITDR et CASB sont basés sur ce principe.

Ce monde a été bouleversé par les agents. Les flux de travail automatisés, de plus en plus autonomes, sont massivement adoptés par les entreprises.

• Des développeurs qui exécutent des agents de codage sur leurs ordinateurs portables.
• Les équipes financières utilisent des agents pour analyser des données propriétaires dans Snowflake.
• Les équipes marketing qui exploitent les données clients dans les CRM.
• Et peut-être même une application interne destinée au public, portant la marque de votre entreprise, prenant des décisions pour lesquelles vous n'avez aucune trace d'audit.

Cela diffère radicalement des chatbots classiques. Les agents sont des entités autonomes ou semi-autonomes capables d'accéder à vos données sensibles, d'utiliser des outils, d'interroger des API et d'agir en conséquence. Votre scénario actuel n'est pas adapté à leurs besoins. Nous détaillerons ci-dessous les problèmes rencontrés et proposerons des solutions.

Comment les agents brisent les contrôles traditionnels

1. Les identités sont égales aux humains‍

Votre infrastructure IAM et ITDR repose sur l'identification humaine. L'authentification unique (SSO), l'authentification multifacteur (MFA), les rôles utilisateurs, le provisionnement, etc., sont tous conçus pour une utilisation humaine. Or, les agents sont plus rapides et opèrent à une échelle bien plus vaste. Ils sont actifs 24 h/24 et 7 j/7, par pics d'activité, sur des milliers d'appels API, héritant souvent des autorisations de l'utilisateur qui les a créés. Pour les outils ITDR traditionnels, les agents sont perçus comme des comptes compromis. Le rapport signal/bruit devient alors critique.

2. Les données sensibles résident dans des systèmes, et nous contrôlons ces systèmes.‍

DSPM et DLP ont été conçus pour découvrir et protéger les données au repos dans des systèmes connus. Les agents introduisent un nouveau mode de défaillance : ils récupèrent des données sensibles d’un système, les mettent en contexte, les transforment et les utilisent ailleurs. Les données ne circulent plus comme le permettait la détection DLP. Elles font l’objet d’un raisonnement. et a agi surVos besoins en matière de visibilité des données doivent vous fournir un contexte sur les actions de l'agent, et non sur l'état du fichier.

3. Défenses périmétriques. ‍

L'analyse des invites et des réponses est importante, mais le véritable risque lié à un agent se situe bien plus tôt. Il réside dans les permissions : l'appel d'outil auquel vous ignoriez son accès, le connecteur lui donnant un accès en écriture à une base de connaissances publique, la récupération de données depuis un entrepôt de vecteurs jamais nettoyé. Cela concerne également la manière dont l'agent a été conçu et l'intention derrière ses actions.

4. Visibilité et gouvernance sont identiques‍

Les tableurs regorgeant de cas d'usage d'IA approuvés constituent la nouvelle forme d'informatique parallèle. Le nombre d'agents au sein des grandes entreprises croît rapidement à mesure que les plateformes low-code se démocratisent et deviennent accessibles aux non-ingénieurs. Les inventaires statiques, constitués manuellement, ne pourront pas suivre le rythme. La gouvernance doit être continue et automatisée, sous peine de se réduire à une simple formalité de conformité.

Le nouveau guide : découvrir, gouverner, protéger, valider

Découvrir

La découverte des agents est plus complexe qu'elle ne l'était pour les charges de travail cloud ou les applications SaaS. Les agents résident dans de nombreux environnements inaccessibles aux méthodes de découverte traditionnelles :

• Plateformes d'agents natifs (Copilot Studio, Agentforce, Bedrock Agents, Foundry Agents)
• Services d'agents auto-hébergés sur AWS, Azure et GCP
• Les agents de point de terminaison, tels que Claude Code, Cursor ou CodeEx, s'exécutent sur les ordinateurs portables des développeurs, souvent avec des identifiants qui accèdent à la production.
• Des outils d'IA publics basés sur navigateur se connectant à des serveurs MCP et à des registres d'outils que peu d'équipes de sécurité ont audités.

Une véritable découverte doit prendre en compte ces cas d'utilisation en combinant les API natives de la plateforme, la télémétrie réseau, les signaux OAuth, la détection basée sur les journaux et la cartographie des points de terminaison. Si votre inventaire d'agents se limite aux informations déclarées par votre équipe d'ingénierie, il y a fort à parier que vous n'avez exploré que la partie émergée de l'iceberg.

Gouverner

La découverte se résume à une liste, tandis que la gouvernance garantit la responsabilité.

Pour chaque agent, il vous faut trois choses : une intention claire (À quoi servait cet agent ?), une image précise de son rayon d'explosion (à quelles données et systèmes peut-il réellement accéder, compte tenu de ses outils et des autorisations dont il dispose ?), et un risque qui prend en compte la posture, le comportement, le niveau d'autonomie et l'exposition des données sensibles dans une mesure quantifiable sur laquelle un responsable de la sécurité peut agir.

La question de gouvernance la plus utile est une question à laquelle presque personne ne peut répondre aujourd'hui : étant donné tout ce à quoi cet agent a accès, son comportement réel est-il cohérent avec son intention déclarée ? Un agent conçu pour résumer les tickets de support ne devrait pas accéder au dossier Fusions et Acquisitions. La difficulté actuelle à détecter ce type d'accès explique précisément pourquoi la gouvernance des agents doit être continue et basée sur les données, et non se limiter à un simple examen statique et ponctuel des accès.

Protéger

Comment se protéger des menaces en temps réel ? Comment bloquer les actions malveillantes ? L’analyse des invites et des réponses est cruciale, mais insuffisante à elle seule. Une véritable protection des agents implique l’application des politiques de sécurité en interne. la boucle :

• Bloquez l'appel d'un outil avant son exécution s'il enfreint la règle de résidence des données.
• Supprimer les informations sensibles avant qu'elles n'atteignent un modèle tiers
• Interrompez un agent qui commence soudainement à accéder à des données en dehors de son périmètre d'utilisation.
• Détecter l'injection d'invites intégrées au contenu récupéré, et pas seulement aux entrées utilisateur.

Le niveau technique est élevé car les défaillances les plus graves des agents ne ressemblent pas à des attaques. Elles s'apparentent plutôt à un agent exécutant scrupuleusement les instructions reçues, sur des données auxquelles il n'aurait pas dû avoir accès. La protection se situe entre l'agent et les données : suffisamment proche de l'action pour être appliquée, et suffisamment intelligente pour ne pas perturber les flux de travail légitimes.

Valider

La dernière étape devrait se généraliser une fois que la réglementation de l'IA aura atteint sa maturité. Elle s'articule autour de la question suivante : Comment savoir si vos contrôles ont réellement fonctionné ?‍

La validation consiste à tester la sécurité de vos propres agents de manière automatisée et à grande échelle. Il s'agit de les sonder par des injections de vulnérabilités, des jailbreaks, des tentatives d'exfiltration et des appels d'outils non conformes aux politiques de sécurité, et de produire des preuves que les garde-fous ont tenu. Sans cette couche de validation, vous avez une idée de votre niveau de sécurité, mais pas de preuves concrètes. Grâce à ces preuves, vous disposez d'éléments fiables pour un conseil d'administration, un auditeur ou un organisme de réglementation.

L'avenir de la sécurité des données

La sécurisation des agents d'IA ne peut reposer sur le statu quo ni sur une architecture technologique d'avant l'ère de l'IA. Elle nécessite une refonte complète de la manière dont la sécurité des données et la sécurité des identités interagissent, ainsi que la mise en place d'une nouvelle couche d'exécution pour les agents, inédite jusqu'alors.

C’est le principe sur lequel Cyera s’est appuyée. solution de sécurité IA Cette solution combine déjà la découverte et la gouvernance des ressources et agents d'IA, ainsi qu'une couche de protection pour les interactions entre modèles, agents et données. Ces deux éléments reposent sur le même graphe de données et la même plateforme qui alimentent nos solutions DSPM et DLP. Il est ainsi possible de relier directement chaque agent, quelle que soit sa plateforme, aux données sensibles situées dans son rayon d'action, tout en tenant compte des identités humaines, machines et agents.

Pour que la vision « agent-based » des entreprises prenne son essor, la sécurité devra évoluer en conséquence. Les entreprises qui réussiront dans ce domaine ne seront pas celles qui auront le modèle le plus sophistiqué. Ce seront celles qui pourront répondre à une question simple, à la demande, pour n'importe quel agent de leur environnement : Quelles données avez-vous consultées, pourquoi, et était-ce autorisé ?‍

Si votre stratégie actuelle ne permet pas de répondre à cette question, elle est déjà obsolète. La bonne nouvelle, c'est que la nouvelle est en train d'être élaborée et que vous avez encore le temps d'en prendre la direction.