Les agents d'IA s'authentifient déjà auprès des systèmes, extraient des données et agissent au nom de votre organisation. Autrement dit, ils fonctionnent comme des identités.
La question à laquelle les équipes de sécurité sont confrontées actuellement n'est pas de savoir si les agents d'IA ont besoin de contrôles d'identité, mais plutôt si votre approche actuelle de gestion des identités et des accès (IAM) est conçue pour gérer des entités qui ne se comportent en rien comme les utilisateurs humains pour lesquels elle a été conçue.
Chaque agent d'IA qui se connecte à une application SaaS, interroge une base de données ou lit des fichiers depuis un stockage cloud remplit les mêmes fonctions que n'importe quelle autre entité de votre environnement : il s'authentifie, obtient l'autorisation et agit. Le fait qu'aucun humain ne saisisse ces requêtes ne modifie en rien les exigences de gouvernance.
Cela rend la situation plus urgente.
Alors, qu'est-ce que la gestion des identités et des accès (IAM) pour les agents d'IA ? Elle applique les mêmes principes fondamentaux que ceux utilisés pour les utilisateurs humains (authentification, autorisation, moindre privilège, gestion du cycle de vie et auditabilité) aux identités non humaines qui agissent de manière autonome dans différents systèmes, souvent sans supervision humaine directe au moment de l'action.
Points clés : Gestion des identités et des accès pour les agents IA
- Les agents d'IA fonctionnent comme des identités : ils s'authentifient, obtiennent l'autorisation et agissent sur différents systèmes, ce qui rend les contrôles IAM non pas optionnels, mais essentiels pour toute organisation déployant une IA agentielle.
- La gestion des identités et des accès (IAM) traditionnelle a été conçue pour les utilisateurs humains et les comptes de service statiques. Les agents d'IA agissent de manière dynamique sur plusieurs systèmes, créent des sous-agents et délèguent des tâches d'une manière que les flux de travail de gouvernance des identités existants ne peuvent pas suivre.
- Chaque agent d'IA doit avoir un propriétaire humain ou organisationnel clairement identifié. Sans attribution claire, les agents accumulent des autorisations au fil du temps sans que personne ne soit responsable de leur examen ou de leur révocation.
- La gestion des identités et des accès (IAM) au niveau système est insuffisante à elle seule ; une gouvernance efficace exige de corréler les autorisations des agents avec la sensibilité des données afin d’identifier les types de données réglementées spécifiques auxquels un agent peut accéder, et non seulement les systèmes auprès desquels il peut s’authentifier.
- Les identités d'agents orphelines constituent une véritable surface d'attaque : les agents déployés pour un projet et jamais mis hors service conservent indéfiniment toutes leurs permissions d'origine sans qu'aucun audit ne soit effectué.
- Les examens d'accès périodiques ne peuvent suivre le rythme de l'IA agentielle ; une surveillance automatisée continue est nécessaire pour détecter les dérives d'autorisation avant que des agents disposant de trop d'autorisations ne provoquent une violation de données ou un incident de conformité.
En quoi les agents IA diffèrent-ils des identités non humaines traditionnelles ?
Les comptes de service et les clés d'interface de programmation d'applications (API) sont statiques : autorisations fixes, comportement prévisible et accès défini à l'avance.
Les agents d'IA bouleversent complètement ce modèle — et c'est là que la gouvernance se complique.
Les agents IA nécessitent un nouveau modèle d'identité
Les agents d'IA opèrent sur plusieurs systèmes, effectuant des tâches qui requièrent un accès dynamique et contextuel. Un agent peut lire des données d'un système de gestion de la relation client (CRM), écrire dans un lac de données ou appeler une API externe, le tout dans un flux de travail unique.
Ils peuvent également créer des sous-agents ou déléguer des tâches, formant ainsi des chaînes d'identités que les outils IAM existants peinent souvent à suivre. Cette portée multi-systèmes et cette délégation rendent la détermination des responsabilités complexe, soulignant pourquoi les modèles de comptes de service traditionnels ne conviennent pas aux agents d'IA.
La gestion de l'accès des agents IA est différente
Les utilisateurs humains suivent des schémas prévisibles. Ils se connectent depuis des appareils connus, accèdent à un ensemble défini d'applications et leur comportement est relativement constant. Les agents d'IA, en revanche, ne suivent pas de scripts. Leurs besoins d'accès évoluent dynamiquement en fonction de leurs activités, ce qui rend les autorisations excessives à la fois plus probables et plus difficiles à détecter par les contrôles d'accès classiques.
L'imprévisibilité comportementale des IA agentives rend la certification d'accès périodique insuffisante. Au moment de votre audit trimestriel, un agent peut avoir accédé à des millions d'enregistrements auxquels il n'aurait jamais dû toucher.
Application des principes fondamentaux de la gestion des identités et des accès aux agents d'IA
La bonne nouvelle, c'est que les principes de gestion des identités et des accès (IAM) que votre équipe connaît déjà s'appliquent directement aux agents d'IA. La difficulté réside dans leur application aux entités qui ne s'intègrent pas facilement à vos processus de gouvernance et d'administration des identités existants.
Authentification
Chaque agent d'IA doit posséder une identité unique et vérifiée, associée à un responsable humain ou organisationnel. Le partage d'identifiants est inacceptable. Lorsque plusieurs agents partagent un jeton OAuth (une clé numérique autorisant l'accès aux systèmes) ou une clé API, il devient impossible d'attribuer les actions à un agent spécifique ; or, une piste d'audit claire repose sur la connaissance précise de l'auteur ou du dispositif ayant effectué chaque action.
Autorisation et principe du moindre privilège
Les agents d'IA ne devraient recevoir que les autorisations nécessaires à l'exécution de leurs tâches spécifiques et définies. Ces autorisations devraient se limiter aux types de données, systèmes et actions strictement nécessaires, et non être héritées de l'utilisateur déployant l'agent ou de l'application dans laquelle il opère.
Cela représente un défi de taille, notamment dans les environnements comportant de nombreuses applications SaaS. Les agents intégrés à des applications tierces peuvent hériter de larges autorisations de la plateforme elle-même, plutôt que de bénéficier d'une gestion d'accès délibérée par votre équipe. Les organisations travaillant sur la gouvernance de l'IA reconnaissent qu'il s'agit là d'une des lacunes les plus négligées en matière de sécurité de l'IA en entreprise.
Gestion du cycle de vie
Les agents doivent être dotés d'un objectif défini et désactivés lorsque cet objectif prend fin.
Les identités d'agents orphelines créent une véritable surface d'attaque : un agent mis en place pour un projet il y a six mois peut encore conserver toutes ses autorisations d'origine, souvent sans que personne ne les examine ou ne les audite.
Auditabilité
Chaque action effectuée par un agent doit être consignée et associée à son identité. Le cadre de gestion des risques liés à l'IA du NIST et la loi européenne sur l'IA imposent tous deux des exigences d'auditabilité auxquelles les contrôles IAM doivent se conformer pour les systèmes d'IA.
Il est indispensable de pouvoir reconstituer les données consultées par un agent, les modifications apportées et les données transmises. Cette reconstitution doit être possible sans nécessiter une enquête manuelle de plusieurs jours.
Le problème de la propriété : la responsabilité des agents d’IA
Il s'agit d'un défi de gouvernance que la plupart des cadres IAM n'ont pas pleinement résolu. Chaque identité d'agent d'IA doit être associée à un responsable humain ou organisationnel désigné, chargé de ses autorisations, de son comportement et de sa mise hors service. Sans cette désignation, les agents peuvent accumuler des accès au fil du temps sans que personne ne soit responsable de leur examen ou de leur révocation.
Votre processus de gouvernance doit définir, pour chaque agent :
- Qui est responsable de l'identité de cet agent ?
- Quelles actions est-elle autorisée à effectuer, et sur quelles données ?
- Quand son accès expire-t-il ou nécessite-t-il une recertification ?
La question de la responsabilité se complexifie particulièrement dans les flux de travail multi-agents. Lorsqu'un agent délègue une tâche à un autre, la chaîne de responsabilité peut devenir floue. Les cadres de gouvernance doivent gérer explicitement la délégation, au lieu de la considérer comme un cas particulier.
Si votre équipe ne dispose pas actuellement d'un inventaire des agents d'IA déployés et de leurs responsables humains, commencez par là. Réalisez cet inventaire, attribuez un responsable à chaque agent et documentez l'étendue de ses permissions avant le prochain cycle de revue d'accès.
L'accès aux données est la couche manquante dans la gestion des identités et des accès des agents d'IA
La gestion des identités et des accès (IAM) traditionnelle régit l'accès au système, en déterminant les applications et les API auxquelles une identité peut accéder. pas régir l'accès aux données : quels fichiers, enregistrements ou ensembles de données spécifiques un agent peut lire, écrire ou exfiltrer.
Cette distinction est cruciale. Un agent disposant d'un accès en lecture à un compartiment de stockage cloud peut avoir accès à des millions d'enregistrements sensibles qui n'ont jamais été examinés ni classifiés. Le simple fait de savoir que l'agent s'est authentifié avec succès ne vous renseigne en rien sur les données auxquelles il a réellement accédé.
Le risque qu'un agent d'IA dispose de trop d'autorisations
Prenons l'exemple d'un agent doté d'un accès en lecture/écriture à un lac de données, alors que sa tâche ne requiert qu'un accès en lecture à une seule table. Cet agent peut désormais lire des enregistrements réglementés dans l'ensemble du lac, modifier des données et potentiellement exposer des informations sensibles via ses sorties. L'examen d'accès ayant approuvé cet “ accès au lac de données ” ne précise généralement pas quelles données sont accessibles, et c'est là que le risque d'exposition se présente.
Une gouvernance efficace des agents d'IA exige de corréler les autorisations d'identité avec la sensibilité des données. Il est essentiel de savoir non seulement que l'agent peut s'authentifier auprès du système, mais aussi à quels types de données spécifiques il peut accéder : informations personnelles identifiables (IPI), informations de santé protégées (ISP), données financières ou autres données réglementées.
Sans cette visibilité au niveau de la couche de données, la gestion des identités et des accès (IAM) au niveau du système ne peut à elle seule empêcher les autorisations excessives, les combinaisons d'accès toxiques ou l'accès ouvert dans les environnements cloud, SaaS et sur site.
Gouvernance de préproduction pour les agents d'IA
Les questions de gouvernance auxquelles votre équipe doit répondre au moment de la mise en service (et non après un incident) sont simples, même si la mise en œuvre des réponses nécessite du travail :
- À quelles données cet agent peut-il accéder, et certaines d'entre elles sont-elles réglementées, sensibles ou soumises à des politiques de conservation ?
- À qui appartient cette identité d'agent, et qui examine ses autorisations ?
- Quelles autorisations sont excessives par rapport au périmètre de tâche défini pour l'agent ?
- Comment l'accès de cet agent sera-t-il révoqué lorsqu'il sera mis hors service ou que son périmètre d'intervention changera ?
Il ne s'agit pas de questions ponctuelles. Le comportement des agents et l'exposition des données évoluent plus rapidement que ne le permettent les cycles d'examen trimestriels. Une gouvernance efficace exige des revues d'accès continues, associées à une surveillance automatisée qui signale les dérives d'autorisation avant qu'elles ne constituent une violation de données.
Comment BigID gère l'identité et l'accès des agents IA
BigID aide les organisations à comprendre quels agents et modèles d'IA ont accès aux données sensibles ou réglementées, et pas seulement aux systèmes qu'ils peuvent atteindre. Sa plateforme offre une visibilité sur les autorisations excessives, les combinaisons d'accès à risque et le contexte de la couche de données, autant d'éléments souvent négligés par les outils IAM traditionnels.
La plateforme AI TRiSM (Gestion de la confiance, des risques et de la sécurité par l'IA) de BigID prend en charge la gouvernance tout au long du cycle de vie des agents, depuis la découverte jusqu'à l'application des politiques, en passant par la définition du périmètre d'accès et le suivi de la traçabilité des données. La surveillance automatisée permet de détecter les cas où les autorisations des agents ne respectent pas les politiques définies, et les processus de correction facilitent l'attribution des revues, l'ajustement des accès et l'application du principe du moindre privilège.
Pour renforcer votre modèle de gouvernance de l'IA, commencez par évaluer la couverture de vos identités non humaines, associer les agents IA à leurs responsables et explorer les solutions BigID pour l'accès aux données basé sur l'identité et la gestion des agents IA. L'utilisation de ces outils vous permettra de garantir que votre organisation dispose de la visibilité et des contrôles nécessaires pour gérer les agents IA de manière sûre et efficace.
Contactez notre équipe pour discuter de la manière dont BigID identifie les risques liés à l'IA dans votre environnement de données et renforce la gouvernance des agents d'IA.
Questions fréquemment posées
Qu’est-ce que la gestion des identités et des accès (IAM) pour les agents d’IA ?
La gestion des identités et des accès (IAM) pour les agents d'IA applique les mêmes principes fondamentaux que pour les utilisateurs humains (authentification, autorisation, moindre privilège, gestion du cycle de vie et auditabilité) aux identités non humaines agissant de manière autonome au sein de différents systèmes. Elle garantit que les agents d'IA n'accèdent qu'aux données et aux systèmes nécessaires à leurs tâches.
En quoi les agents IA diffèrent-ils des comptes de service ou des clés API ?
Contrairement aux comptes de service statiques ou aux clés API, les agents d'IA agissent de manière contextuelle, enchaînant les actions et demandant l'accès dynamiquement en fonction de la tâche. Ils peuvent interagir avec plusieurs systèmes, créer des sous-agents ou déléguer des tâches, ce qui soulève de nouveaux défis en matière de gouvernance et d'auditabilité.
Pourquoi la notion de propriété est-elle importante pour les agents IA ?
Chaque agent d'IA doit être désigné comme responsable humain ou organisationnel. En l'absence d'une attribution claire, les agents peuvent accumuler des autorisations au fil du temps sans que personne ne soit chargé de les examiner ou de les révoquer, ce qui engendre des risques en matière de sécurité et de conformité.
Comment les organisations peuvent-elles garantir un accès aux privilèges minimaux pour les agents d'IA ?
Les autorisations doivent être limitées au strict minimum nécessaire aux tâches définies pour l'agent. Les organisations doivent éviter les autorisations héritées ou trop larges, mettre en œuvre une surveillance continue et appliquer des flux de travail automatisés pour l'examen et la correction des accès.
Comment BigID contribue-t-il à la gestion de l'accès des agents IA ?
BigID offre une visibilité sur les agents et modèles d'IA ayant accès à des données sensibles ou réglementées, identifie les autorisations excessives ou les combinaisons d'accès risquées et propose une gouvernance du cycle de vie comprenant la découverte, la définition du périmètre d'accès et l'application des politiques.
Que doivent faire les équipes de sécurité en premier ?
Commencez par associer les agents d'IA à leurs propriétaires humains, définissez leur étendue d'accès et vérifiez la couverture des identités non humaines dans votre environnement. Une surveillance continue et l'application des politiques permettent d'éviter que des agents disposant de trop d'autorisations ne créent des vulnérabilités.
Auteur
