IAM pour les agents IA : structurer l'identité et les autorisations en entreprise

Selon le Verizon Data Breach Investigations Report 2025, plus de 80 % des incidents de sécurité impliquent des identités compromises. L’analyse de la faille CVE-2026-42608 dans Grav CMS exploitée par ShinyHunters illustre concrètement comment des identités compromises peuvent être exploitées pour pénétrer un système. Alors que les entreprises françaises accélèrent le déploiement d’agents d’intelligence artificielle - ces entités logicielles qui authentifient, invoquent des outils et agissent sur les systèmes avec une autorité déléguée -, la question de leur gouvernance identitaire devient critique. L’IAM pour agents IA (Identity and Access Management) constitue l’architecture de contrôle qui permet de gérer ces acteurs non humains : leur identité, leurs droits, leur durée de vie et leur traçabilité. Sans une telle architecture, les entreprises s’exposent à des fuites de données, à des escalades de privilèges et à une incapacité à prouver la conformité réglementaire. Ce guide expose les limites des approches traditionnelles, les composants essentiels d’un framework adapté, et les critères pour choisir la solution la mieux adaptée à votre contexte.

Pourquoi l’IAM classique ne peut pas gouverner les agents intelligents

Les plateformes IAM historiques ont été conçues pour des identités humaines et des cycles de vie pilotés par les ressources humaines. Elles fonctionnent selon deux dimensions : la gestion du cycle de vie (provisioning, déprovisioning, révisions d’accès) et l’exécution au moment du login (authentification unique, vérification des droits au périmètre applicatif). Or, un agent IA ne suit pas un chemin de tâches prévisible : il chaîne des actions, sélectionne des outils dynamiquement et compose des comportements qu’aucune revue d’habilitation n’avait anticipés.

Les limites des autorisations statiques

L’OWASP Top 10 for Large Language Model Applications identifie ce mode de défaillance sous le nom d’agence excessive (LLM06) : un agent doté de fonctionnalités, permissions ou autonomie trop larges peut exercer des capacités bien au-delà de sa mission approuvée. L’affectation statique d’un rôle ne peut borner ce comportement, et une revue de configuration ne peut le mesurer. Comme le souligne la publication spéciale NIST SP 800-53, le principe de moindre privilège (AC-6) s’applique sans modification aux identités non humaines, mais son application pratique exige des mécanismes de contrainte au moment de l’exécution, et non seulement lors de l’attribution.

« Least privilege - The principle that a security architecture should be designed so that each entity is granted the minimum system resources and authorizations needed to perform its function. » - NIST SP 800-53, CA-6

Le cycle de vie des identités non humaines

Les identités d’agents sont souvent créées par l’automatisation des déploiements, des pipelines CI/CD ou des équipes applicatives, contournant les workflows de gouvernance qui détectent les anomalies d’accès humain. Le cas du domaine placeholder-third-party.com compromis illustre comment une dépendance externe non gouvernée ouvre une voie d’attaque silencieuse dans la chaîne de développement. Elles s’accumulent hors de l’inventaire que la conformité consulte. Cinq modes de défaillance récurrents émergent :

• Absence de propriétaire : aucun humain n’est responsable de la finalité de l’agent, de sa portée ou de sa durée de vie.
• Secrets longs : des clés API statiques persistent sans rotation liée à la retraite de l’agent.
• Délégation illimitée : l’agent hérite en bloc des permissions d’un utilisateur ou d’un service, sans limitation par tâche.
• Instanciation invisible : des agents générés par d’autres workloads ne s’enregistrent jamais dans le fournisseur d’identité (IdP) ou dans le système de gouvernance.
• Absence d’expiration : un accès accordé pour un pilote reste actif bien après la fin du pilote.

« Toutefois, tous les environnements ne présentent pas ces cinq failles, mais chacune correspond à une couche de contrôle qu’un framework d’identité agent doit fournir », constate l’état de l’art dans ce domaine émergent.

Composants essentiels d’un framework IAM pour agents IA

Face à ces défaillances, une architecture dédiée combine trois grandes fonctions : établir qui est l’agent, contraindre ce qu’il peut faire, et prouver ce qu’il a fait.

Identité, authentification et gestion des credentials

Chaque agent nécessite une identité distincte et attribuable, jamais un compte partagé ni un identifiant humain emprunté. L’attribution est la condition préalable de tout contrôle aval : une piste d’audit qui ne peut séparer l’activité d’un agent de celle d’un humain ne peut pas soutenir la conformité réglementaire (RGPD, directive NIS 2, référentiel d’agrément ANSSI).

En pratique, la gestion des credentials doit privilégier la fédération d’identité pour workloads et des jetons court-lignes automatiquement renouvelés, plutôt que des secrets embarqués. Lorsqu’un agent agit pour le compte d’un utilisateur, le protocole OAuth 2.0 Token Exchange (RFC 8693) offre les sémantiques de délégation et d’impersonation qui préservent la distinction entre l’identité propre de l’agent et l’autorité qui lui a été prêtée. Cette distinction disparaît dès que l’agent réutilise simplement le jeton de session de l’utilisateur.

Autorisation fine et contrôle d’accès

L’authentification établit l’identité ; l’autorisation détermine le rayon d’explosion. Les contrôles de la famille Access Control (AC) du NIST SP 800-53 s’appliquent aux identités agents sans modification : moindre privilège, séparation des tâches, limites d’autorisation explicites. Le point d’application doit toutefois se situer plus près de l’action qu’une passerelle d’authentification unique.

Voici les mécanismes d’autorisation qui contraignent concrètement le comportement d’un agent :

1. Grants limités à une tâche : l’autorité est délivrée pour une tâche spécifique et expire avec elle, sans persister sous forme de rôle permanent.
2. Liste blanche d’outils : l’agent ne peut invoquer que les API et fonctions nécessaires à sa finalité.
3. Périmètres de données : les sources de récupération sont contraintes, car un agent qui raisonne sur des données manipulées agira fidèlement sur celles-ci.
4. Seuils d’action : les opérations à haute conséquence exigent une approbation humaine ou un second chemin d’autorisation.

Par exemple, un agent d’approvisionnement qui doit consulter les tarifs fournisseurs ne devrait pas pouvoir passer de commandes. Dans la pratique, un simple écart entre l’intention déclarée et les permissions accordées peut conduire à des actions non souhaitées. « En outre, les contrôles d’accès doivent être réévalués en continu, et non seulement lors de la création de l’agent », recommande l’ANSSI dans ses guides de sécurisation des systèmes d’IA.

Auditabilité, surveillance et révocation

Les contrôles de conception ne deviennent défendables que si l’environnement peut montrer ce que l’agent a exécuté. Le NIST AI Risk Management Framework (AI 100-1) traite la responsabilité et la transparence comme des caractéristiques de fiabilité qui dépendent d’un comportement système traçable. La famille Audit and Accountability (AU) du SP 800-53 suppose des enregistrements suffisants pour reconstituer une séquence d’actions, et non seulement la preuve qu’une politique existait.

La surveillance des agents doit être comportementale, pas simplement basée sur les logs. Les techniques d’attaque identitaire répertoriées dans MITRE ATT&CK, notamment l’abus de comptes valides (T1078) et l’escalade de privilèges, génèrent des journaux d’authentification normaux car les identifiants sont légitimes. La détection repose sur la comparaison entre la tâche prévue de l’agent et son exécution réelle à travers les applications et l’infrastructure, ainsi que sur la capacité à révoquer l’autorité déléguée lorsque les deux divergent.

« Continuous monitoring - The process of maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions. » - NIST SP 800-137

Choisir la meilleure approche IAM pour les agents IA

La question « quel framework IAM utiliser pour les agents IA ? » ne trouve pas de réponse unique dans un catalogue de produits. Elle dépend de la capacité de l’architecture à couvrir l’ensemble de la chaîne de contrôle - de la propriété humaine à la preuve d’exécution -, et non du nombre de connecteurs proposés.

Critères d’évaluation pour l’entreprise

Le tableau ci-dessous présente les sept dimensions critiques à évaluer lors de la sélection d’une solution ou d’une architecture IAM pour agents IA :

« Néanmoins, la pondération diffère selon l’environnement : une entreprise régulée avec obligations de certification optimisera différemment d’une équipe qui déploie un agent interne unique. »

Construire, acheter ou étendre une plateforme existante

Pour la plupart des entreprises qui disposent déjà d’un programme de gouvernance identitaire, étendre la plateforme IAM existante est la position de départ raisonnable. Les workflows de cycle de vie, les chaînes d’approbation, les cycles de certification et la gouvernance politique existent déjà ; les reconstruire pour les agents fragmenterait un programme déjà souvent éclaté. Un chef de projet cybersécurité est généralement le pilier de ces décisions d’architecture et de gouvernance, combinant vision technique et pilotage budgétaire. Des plateformes comme SailPoint et Saviynt adressent la moitié « design-time » du problème et publient des capacités pour les identités non humaines et agents - dont la couverture évolue avec chaque version.

La construction est plus facile à justifier lorsque les frameworks d’agents sont propriétaires et que l’autorisation doit être intégrée dans le runtime lui-même. L’achat devient pertinent pour la couche que les plateformes de gouvernance ne fournissent généralement pas : la découverte des identités agents directement depuis les applications et l’infrastructure, et la vérification que l’exécution correspond à l’intention.

De nombreux programmes finissent par combiner les trois : étendre pour le cycle de vie, construire pour le contrôle d’application, acheter pour l’observabilité. Ce choix reflète les modèles de déploiement concrets présentés ci-après.

Cas d’usage concrets et modèles de déploiement

L’approche « étendre-construire-acheter » devient concrète lorsque des agents spécifiques entrent en production, chaque classe d’agent échouant différemment.

Agent interne de gestion de tickets

Prenons un agent interne qui résout des tickets de support à travers un CRM, un outil de ticketing et une base de connaissances interne. L’IdP enregistre chaque jour quelques authentifications réussies - un profil anodin. Mais à l’intérieur des applications, le même agent interroge des fiches clients, exporte des données et met à jour des habilitations. Une vue centrée sur le fournisseur d’identité rapporte que l’agent est bien gouverné ; une télémétrie applicative révèle les accès réels aux données et aux outils. La fidélité de détection dépend de cette seconde vue, car le comportement qui compte n’atteint jamais le journal d’authentification.

Agent d’approvisionnement avec délégation

Un agent de gestion des approvisionnements illustre le problème de délégation. Sa tâche approuvée est de récupérer les tarifs fournisseurs. Les permissions accordées incluent la surface d’API complète de l’outil d’approvisionnement. Ses actions exécutées peuvent inclure le déclenchement de bons de commande, car la chaîne de tâches a raisonné jusque-là. Trois artefacts distincts apparaissent donc : l’intention, l’habilitation, l’exécution. Seul le troisième décrit ce qui s’est réellement passé.

« Separation of duties - The principle that no single individual should have the ability to perform all steps of a critical function. » - NIST SP 800-53, AC-5 (appliqué aux identités agents, un agent ne doit pas cumuler les étapes d’un processus critique sans supervision.)

Agent de déploiement de code

Un agent de livraison de code détenant une identité de plan de contrôle élève encore les enjeux. Les identifiants d’automatisation d’infrastructure nécessitent des permissions étendues, ce qui en fait des cibles de valeur et peut permettre à un agent compromis de remodeler l’environnement, y compris les contrôles censés le détecter.

Mise en œuvre progressive et gouvernance

Face à la complexité, une approche par stades de maturité permet d’avancer sans tout réarchitecturer d’un coup.

1. Gouvernance statique par comptes et rôles : les agents sont inventoriés comme identités non humaines avec propriétaire, finalité et expiration ; les accès sont révisés périodiquement. Fonctionnel pour des pilotes, insuffisant pour une action autonome.
2. Gouvernance automatisée et événementielle : le provisionnement, la rotation des credentials et la révocation sont déclenchés par des événements de déploiement et de retraite, et non par des calendriers de revue.
3. Observabilité continue des identités : le comportement des agents est observé à travers les applications et l’infrastructure ; l’exécution est comparée au périmètre de tâche prévu ; les preuves d’audit sont générées par télémétrie.

Le troisième stade est celui où la détection des écarts devient possible. Des solutions émergentes découvrent les identités directement depuis les applications et l’infrastructure, sans se limiter aux données de configuration IAM, révélant des identités agents, des credentials et des chemins d’accès que des systèmes d’identité fragmentés peuvent ne pas remonter.

L’avenir de la gestion des identités dans un monde d’agents IA

L’observabilité au stade trois devient plus difficile, et non plus facile, à mesure que les agents commencent à s’autoriser mutuellement.

Politiques lisibles par machine et confiance inter-agents

Lorsqu’un agent délègue une sous-tâche à un autre, l’autorité se propage le long d’une chaîne qu’aucun humain n’a approuvée étape par étape. Les politiques lisibles par machine - c’est-à-dire des autorisations exprimées sous une forme que les agents peuvent évaluer et appliquer en runtime - constituent une réponse émergente, accompagnées de travaux normatifs en cours sur des identifiants agents vérifiables et une délégation contrainte. Ces efforts sont encore préliminaires, et l’interopérabilité entre frameworks d’agents n’est pas stabilisée.

Le besoin de gouvernance, lui, ne change pas. Chaque maillon de la chaîne doit posséder une identité, un périmètre, une expiration et un humain en dernier ressort responsable. La matrice MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) catalogue les tactiques et techniques adverses ciblant les systèmes d’IA, et constitue une référence utile pour anticiper la manière dont ces chaînes seront attaquées.

Autorisation continue pour les systèmes adaptatifs

L’autorisation continue remplace la décision d’admission unique par une évaluation permanente, réévaluant l’autorité à mesure que le comportement de l’agent, ses sources de données et son contexte d’exécution évoluent. Elle ne fonctionne que là où un signal comportemental existe, ce qui renvoie à l’idée de départ : un framework d’identité qui gouverne le provisionnement sans observer l’exécution produit une intention politique, pas une assurance opérationnelle.

Conclusion : de l’intention à la preuve concrète

Les agents IA sont déjà à l’œuvre dans les entreprises françaises. La question n’est plus de savoir si vous allez devoir les gérer, mais si votre environnement peut prouver ce qu’ils ont fait. Une architecture IAM pour agents IA ne se résume pas à un outil : c’est une combinaison de composants - identité, autorisation fine, surveillance continue - dont la robustesse se mesure à la capacité de produire, pour chaque action, une preuve télémétrique que l’exécution est restée dans le périmètre de la tâche approuvée. En adoptant une approche par stades, en évaluant chaque critère de choix et en combinant des briques existantes avec des capacités d’observabilité complémentaires, vous pouvez transformer l’intention de contrôle en assurance vérifiable. L’année 2026 marque un tournant : les premières obligations réglementaires françaises sur la sécurisation des systèmes d’IA émergent, et les entreprises qui auront structuré leur IAM pour agents disposeront d’un avantage compétitif en matière de confiance et de conformité.