Contrôle d’accès des agents d’IA : comment définir leur périmètre d’action

Vos systèmes regorgent d’identifiants qui n’appartiennent pas à une personne : comptes de service, clés API, jetons OAuth. Ces identités non humaines (NHI) sont environ 45 fois plus nombreuses que les identifiants humains dans une entreprise moyenne, et 144 fois plus nombreuses dans les environnements cloud-native.

Les agents IA utilisent ces mêmes identités de manière innovante. Alors qu’un compte de service se contente d’effectuer la seule tâche pour laquelle il a été conçu, un agent peut choisir lui-même la prochaine étape et étendre ses droits d’accès au fil du temps. Les contrôles d’accès sont généralement conçus pour les comptes de service : leurs droits sont définis une seule fois lors de leur création, puis réévalués tous les trimestres. Ce système ne fonctionne pas pour les agents, qui peuvent étendre leurs propres droits d’accès entre deux réévaluations.

Le contrôle d’accès des agents IA résout ce problème : il fournit une identité unique par agent, des autorisations limitées à sa tâche et une surveillance qui se poursuit après l’octroi des droits.

Points clés

• Le contrôle d’accès régit ce qu’un agent peut faire une fois authentifié : quels outils il peut utiliser, quelles données il peut récupérer et quelles actions nécessitent l’intervention d’un humain.
• L’IAM traditionnel repose sur l’hypothèse d’une session humaine prévisible. Les agents acquièrent des permissions au moment de l’exécution et agissent selon des séquences que personne n’avait modélisées lors du déploiement.
• Parmi les organisations ayant signalé une violation liée à l’IA dans l’étude IBM de 2025, 97 % ont déclaré ne disposer d’aucun contrôle d’accès à l’IA approprié.
• Les modèles RBAC, ABAC, PBAC et ReBAC résolvent chacun une partie du problème. La plupart des entreprises utiliseront une combinaison de ces approches, organisée selon le niveau de risque.
• Les permissions décrivent ce qu’un agent est autorisé à faire. Seule la surveillance comportementale permet de savoir ce qu’il est en train de faire à un instant donné.

Qu’est-ce que le contrôle d’accès des agents d’IA ?

Le contrôle d’accès des agents d’IA consiste à attribuer à chaque agent d’IA sa propre identité, puis à appliquer des règles granulaires définissant ce qu’il peut voir, appeler et faire.

Ce n’est pas la même chose que l’authentification. L’authentification des agents permet de déterminer qui effectue la requête. Le contrôle d’accès régit tout ce qui se passe ensuite : les outils qu’un agent peut invoquer, les enregistrements qu’il peut récupérer et les actions qu’il peut entreprendre sans validation humaine.

Si les agents ont besoin de leur propre modèle de contrôle d’accès, c’est parce qu’ils se situent entre les deux catégories actuellement gérées par l’IAM. Ce ne sont pas des utilisateurs humains, car ils fonctionnent en continu et à la vitesse d’une machine. Ce ne sont pas non plus des comptes de service statiques, car un compte de service effectue une seule tâche avec un seul identifiant.

Le contrôle d’accès des agents IA est particulièrement important car un agent peut (tenter d’acquérir) de nouvelles autorisations en cours de tâche. Cela rompt avec le modèle traditionnel. La portée d’un identifiant d’agent ne peut pas être entièrement déterminée au moment où vous le délivrez.

Pourquoi le contrôle d’accès des agents d’IA est-il si important aujourd’hui ?

Parce que les agents sont déployés plus rapidement que quiconque ne peut les examiner, et que des incidents se sont déjà produits.

Gartner prévoit que, d’ici 2028, l’entreprise moyenne du Fortune 500 mondial utilisera plus de 150 000 agents, contre moins de 15 en 2025. Dans la même étude, seules 13 % des organisations estimaient disposer d’une gouvernance adaptée.

Le rapport « Cost of a Data Breach » d’IBM a révélé que 13 % des organisations avaient signalé une violation de leurs modèles ou applications d’IA, et que 97 % d’entre elles déclaraient ne pas disposer de contrôles d’accès à l’IA appropriés. Soixante pour cent de ces incidents ont entraîné la compromission de données.

Autre exemple : en août 2025, le Threat Intelligence Group de Google a documenté une campagne au cours de laquelle des attaquants ont utilisé des jetons OAuth volés provenant de l’agent de chat IA Drift pour interroger des instances Salesforce dans des centaines d’organisations, un nombre par la suite estimé à plus de 700. Aucune vulnérabilité n’a été exploitée. Les jetons étaient valides, les requêtes correctement formées et le trafic ressemblait à celui d’une intégration faisant son travail. Les permissions constituaient la vulnérabilité.

Les agents qui accèdent à vos systèmes via l’autorisation MCP élargissent le même problème, puisqu’un seul endpoint de protocole peut exposer des dizaines d’outils à la fois.

Quels sont les principaux composants des autorisations des agents d’IA ?

Un modèle complet de contrôle d’accès des agents d’IA comprend cinq couches.

1. Gestion des identités des agents. Chaque agent dispose de sa propre identité, qu’il s’agisse d’un compte de service dédié, d’un client OAuth à périmètre limité ou d’une identité cryptographique de workload. Aucun agent ne doit fonctionner avec les identifiants d’un humain ni partager une identité avec un autre agent. Sans identité unique, aucun des quatre contrôles ci-dessous ne peut être attribué ou révoqué.
2. Définition du périmètre des outils et des API. Limitez précisément les outils et endpoints qu’un agent peut utiliser, et évaluez chaque appel proposé par rapport à cette liste. Un agent qui résume des tickets de support n’a aucune raison d’appeler l’API de remboursement, même si ses identifiants l’y autorisent techniquement.
3. Isolation du contexte et garde-fous sur les données. Filtrez ce que l’agent peut récupérer avant que quoi que ce soit n’atteigne le prompt du modèle. C’est ce contrôle qui empêche qu’une requête portant sur les données d’un client ne renvoie l’intégralité de la table.
4. Droits d’action et de décision. Distinguez ce qu’un agent peut lire de ce qu’il peut modifier. Les actions à fort impact telles que les paiements, les déploiements, la suppression de données et les communications externes doivent nécessiter une validation humaine, quelles que soient les autorisations accordées par le rôle de l’agent.
5. Journalisation des audits. Enregistrez l’identité de l’agent, l’action, la ressource et la raison pour laquelle la requête a été autorisée. « L’agent X a accédé à l’enregistrement Y » ne vous apprend rien lors d’un incident. « L’agent X a accédé à l’enregistrement Y conformément à la politique Z, à la demande de l’utilisateur W », voilà ce dont une enquête a réellement besoin.

RBAC, ABAC, PBAC ou ReBAC : quel modèle de contrôle d’accès convient aux agents d’IA ?

Le RBAC traditionnel constitue un point de départ raisonnable, mais un rôle correspond à un ensemble statique de permissions, tandis que les besoins d’accès d’un agent changent à chaque tâche qui lui est confiée.

L’ABAC améliore le RBAC en évaluant les attributs au moment de la requête : la sensibilité de l’enregistrement, l’heure de la journée, le type d’opération. C’est une meilleure solution, mais la décision est toujours prise une seule fois par requête et s’applique pour le reste de la session.

Le PBAC centralise les règles dans un moteur de politiques situé en dehors de l’agent, ce qui permet de renforcer une politique en réponse à un incident sans avoir à déployer de nouveau code d’agent. Compte tenu de la rapidité avec laquelle les capacités des agents évoluent, ce découplage revêt une importance bien plus grande que pour les applications classiques.

Le ReBAC régit l’accès par le biais de relations plutôt que de rôles ou d’attributs : cet agent agit pour le compte de cet utilisateur, sur les ressources que cet utilisateur possède. Cela s’applique parfaitement aux workflows délégués et à l’orchestration multi-agents, où la question n’est pas tant « qui est cet agent » que « sous l’autorité de qui opère-t-il ? ».

La plupart des entreprises utiliseront une combinaison de ces approches, hiérarchisée en fonction des risques : le RBAC et l’ABAC pour la définition de périmètre de base, le PBAC pour les politiques qui évoluent plus rapidement que le code, le ReBAC pour la délégation, et l’approbation humaine pour les actions irréversibles.

Pourquoi l’IAM traditionnel ne suffit-il pas pour les agents d’IA ?

L’IAM traditionnel ne suffit pas pour les agents IA car le RBAC et l’ABAC ont été conçus pour des sessions humaines prévisibles sur des applications statiques. Les agents remettent en cause ces deux hypothèses.

Un utilisateur humain suit un parcours globalement reproductible au sein de vos systèmes. Un agent chargé d’une tâche ouverte enchaîne les outils, synthétise les données provenant de différentes sources et génère des schémas d’accès qu’aucune définition de rôle n’avait anticipés.

La fréquence des révisions constitue le deuxième décalage. Les révisions d’accès ont été conçues en fonction des effectifs humains, qui varient de quelques pour cent par trimestre. Les agents sont déployés en quelques minutes, et leur nombre se compte bientôt en centaines de milliers par entreprise. Un cycle d’attestation trimestriel ne peut pas régir une population dont le renouvellement est plus rapide que la révision elle-même.

Vient ensuite le problème de la responsabilité. Lorsqu’un employé quitte l’entreprise, les RH déclenchent le processus de départ. Mais que se passe-t-il lorsque le développeur qui a déployé un agent change d’équipe ? La Cloud Security Alliance a constaté que seules 20 % des organisations disposent d’un processus formel de désactivation et de révocation des clés API.

Comment appliquer le contrôle d’accès au trafic des agents d’IA en temps réel ?

Tous les contrôles décrits jusqu’à présent sont évalués au moment où l’identifiant est émis ou lorsque la requête arrive. Aucun ne couvre le cas où un agent disposant d’identifiants entièrement légitimes commence à se comporter d’une manière que ses opérateurs n’avaient jamais prévue. Cela inclut les jetons compromis, les agents victimes d’une injection de prompt et les agents tiers qui modifient discrètement leur comportement après que vous les avez autorisés.

L’application des contrôles au moment de l’exécution nécessite quatre éléments :

1. Une vérification de l’identité qui ne repose pas sur l’auto-déclaration
2. Un score d’anomalie pour chaque requête
3. Une analyse des schémas au niveau de la session
4. Une atténuation automatique capable de limiter le débit, de soumettre à un challenge ou de bloquer sans perturber les agents légitimes

La vérification de l’identité est importante, car une chaîne de user agent est une déclaration plutôt qu’un identifiant vérifié. DataDome a envoyé une requête avec une identité ChatGPT-User usurpée à 698 214 sites web accessibles et 79,7 % l’ont laissée passer directement. OpenAI publie les plages d’adresses IP de cet agent, de sorte qu’une simple vérification aurait permis de détecter chacune de ces requêtes. Seuls 20 % des sites web l’ont fait.

Agent Trust de DataDome couvre à la fois l’identité des agents et les politiques. L’identité des agents est établie au moyen des signatures cryptographiques Web Bot Auth, des plages d’adresses IP publiées, du DNS inversé et du fingerprinting, chaque identification étant accompagnée d’un niveau de fiabilité transparent.

La politique est ensuite appliquée par agent et par point de terminaison, ce qui vous permet d’autoriser un agent à naviguer tout en l’empêchant de créer un compte. La détection s’effectue avec une latence P95 inférieure à 2 ms, une précision de 99,99 % et un taux de faux positifs inférieur à 0,01 %. L’analyse d’intention se poursuit après la vérification de l’agent, ce qui permet de détecter le credential stuffing, le scraping et la fraude au paiement commis par des agents qui semblent par ailleurs légitimes.

La même couche s’applique à vos terminaux MCP, où les agents appellent directement des outils au lieu de récupérer des pages.

Comment élaborer une stratégie de contrôle d’accès des agents d’IA ?

Pour élaborer une stratégie de contrôle d’accès des agents d’IA, commencez par un inventaire, puis ajoutez l’identité, la définition du périmètre et l’application des contrôles, dans cet ordre.

1. Inventoriez chaque agent. Vous ne pouvez pas définir le périmètre de ce que vous n’avez pas recensé, et les agents que personne n’a enregistrés sont généralement ceux qui disposent des identifiants les moins restrictifs.
2. Attribuez des identités uniques. Aucun agent ne doit fonctionner avec des identifiants partagés ou humains. C’est cette étape qui rend le journal d’audit pertinent et permet la révocation.
3. Appliquez le principe du moindre privilège par défaut. Limitez les outils, les données et les actions à l’ensemble le plus restreint nécessaire à la tâche, et privilégiez les identifiants à courte durée de vie plutôt que les accès permanents.
4. Ajoutez des mécanismes de validation humaine pour les actions qui ne peuvent pas être annulées : paiements, suppressions, déploiements en production et tout ce qui est envoyé à un client. Limitez ces validations à ces seules actions. Un agent qui demande une autorisation quarante fois par période de travail habitue son approbateur à cliquer sur oui sans lire.
5. Journalisez l’identité, l’accès, le raisonnement et le résultat pour chaque action de l’agent, et pas seulement le fait qu’un événement s’est produit.
6. Ajoutez une couche d’application comportementale en temps réel, car tout ce qui précède décrit le comportement attendu sans jamais garantir le comportement réel.

Passez en revue l’ensemble à une fréquence fixe. Les capacités des agents, les intégrations d’outils et les agents tiers évoluent plus rapidement que ne le suppose n’importe quel cycle d’attestation annuel.

Les autorisations sont une décision, le comportement est un fait

Le contrôle d’accès des agents IA commence par l’identité et la définition du périmètre selon le principe du privilège minimal. Ces éléments sont nécessaires, mais ils constituent également une décision prise à un moment donné. Ils décrivent ce qu’un agent était censé faire le jour où ses identifiants ont été délivrés, ce qui ne vous apprend pas grand-chose sur ce qu’il fera par la suite.

Les organisations qui adopteront l’IA agentique sans crise de gouvernance seront celles qui associeront un accès délimité à une application continue des règles comportementales, car le nombre d’agents dépasse désormais celui des effectifs humains au sein de chaque grande entreprise et aucun processus de révision n’est capable de s’adapter à cette échelle.

Une première étape raisonnable consiste à déterminer quels agents peuvent déjà accéder à vos systèmes. Réservez une démonstration de DataDome Agent Trust pour voir comment la vérification d’identité et la détection d’intention fonctionnent conjointement sur le trafic réel des agents.