IAM pour les agents IA : un cadre pratique pour sécuriser les identités non-humaines dans votre entreprise

Les agents d’intelligence artificielle (IA) ne se contentent plus de répondre à des questions : ils agissent. Ils réservent des rendez-vous, modifient des bases de données, émettent des ordres de paiement. Chaque action est exécutée au nom de l’entreprise, avec des droits délégués, sans supervision humaine immédiate. Pourtant, dans la plupart des organisations, ces agents sont encore gérés avec des comptes de service partagés, des clés API statiques ou des identités humaines empruntées. Cette situation crée un angle mort critique dans la gouvernance des identités et des accès (IAM).

Selon le rapport 2025 de l’Agence nationale de la sécurité des systèmes d’information (ANSSI), les incidents liés à une mauvaise gestion des accès des systèmes automatisés sont en forte hausse. Le cadre IAM pour agents IA que nous détaillons ici répond à un besoin urgent : donner à chaque agent une identité traçable, des droits strictement limités à sa tâche, et des mécanismes de surveillance permettant de prouver ce qu’il a réellement exécuté.

Ce guide pratique s’adresse aux responsables sécurité, architectes IAM et DSI qui doivent intégrer ces nouveaux acteurs dans leur système de gestion des identités. Il couvre les limites de l’IAM traditionnelle, les composants indispensables d’un cadre dédié, les critères de choix d’un framework et les étapes de déploiement éprouvées sur le terrain.

Pourquoi les systèmes IAM traditionnels échouent face aux agents IA

Les plateformes IAM classiques ont été conçues pour des humains : un utilisateur se connecte, accède à une application, effectue des tâches prévisibles. Les agents IA, eux, enchaînent des actions, invoquent des outils de manière dynamique, et composent des permissions qui n’ont pas été prévues par les processus de revue d’accès. Cette différence fondamentale fait vaciller les piliers de l’IAM traditionnelle.

Le fossé entre l’intention et l’exécution

Dans un environnement IAM classique, la politique d’accès est définie en conception (provisioning, rôles) et appliquée en runtime via l’authentification unique (SSO) ou des vérifications au périmètre de l’application. Mais que se passe-t-il une fois que l’agent a passé la porte ? L’IAM ne le voit plus. L’agent exécute des appels API, crée des ressources, modifie des données - autant d’actions qui n’apparaissent pas dans les logs du fournisseur d’identité.

Le OWASP Top 10 for LLM Applications nomme ce risque « Excessive Agency » (LLM06) : l’agent se voit accorder des fonctionnalités ou permissions trop larges et les utilise au-delà de sa tâche approuvée. La configuration initiale ne peut pas détecter ce comportement ; seule la télémétrie d’exécution le peut.

« Les systèmes IAM expriment l’accès configuré, tandis que les logs applicatifs révèlent l’accès réel. Entre les deux se trouve une matière noire identitaire : agents, credentials, comptes locaux que le SI central ne voit jamais. » - Note d’analyse d’un architecte IAM, 2025.

Les risques du cycle de vie des identités non-humaines

Les identités des agents ne suivent pas le cycle de vie des employés. Elles sont créées par des pipelines DevOps, des scripts d’automatisation ou des équipes applicatives, sans passer par les workflows de gouvernance RH. Les conséquences sont multiples :

• Absence de propriétaire : aucun humain désigné n’est responsable de l’agent, de sa finalité ou de sa suppression.
• Secrets longs : clés API stockées en dur, tokens jamais renouvelés, même après la fin de vie de l’agent.
• Délégation illimitée : l’agent hérite des droits de l’utilisateur ou du compte de service sans périmètre défini.
• Instanciation invisible : des agents créés par d’autres agents ne sont pas enregistrés dans l’annuaire central.
• Absence d’expiration : les accès accordés pour un pilote restent actifs des mois après la fin du projet.

Ces modes de défaillance ne sont pas théoriques. Dans la pratique, nous avons observé que la majorité des incidents liés à des agents en production provenaient d’une identité non révoquée ou d’un secret non roté. Selon le Verizon Data Breach Investigations Report 2024, 49 % des violations de données impliquent des identifiants volés ou compromis - un risque accru avec des agents IA aux secrets longs. Le cadre IAM doit donc intégrer des contrôles à chaque étape du cycle de vie.

L’absence de télémétrie d’exécution

Les systèmes de surveillance traditionnels se concentrent sur les événements d’authentification. Or, les attaques d’identité (abuse de comptes valides, escalade de privilèges) produisent des logs d’authentification normaux, car les identifiants sont légitimes. La technique T1078 (« Valid Accounts ») du MITRE ATT&CK est l’une des plus utilisées pour persister dans un environnement. Sans télémétrie au niveau de l’action (outil invoqué, donnée accédée, ressource créée), impossible de distinguer une utilisation conforme d’un détournement.

« La capacité à prouver ce qu’un agent a fait est aussi importante que la capacité à définir ce qu’il peut faire. Sans la première, la seconde n’est qu’une déclaration d’intention. »

Les piliers d’un cadre IAM pour agents IA

Un cadre IAM adapté aux agents IA repose sur trois piliers : l’identité attribuable, l’autorisation contrainte et l’audit probant. Chacun doit être conçu pour répondre aux spécificités des acteurs non-humains.

Identité, authentification et gestion des identifiants

Chaque agent doit posséder une identité distincte et attribuable - jamais un compte de service partagé, jamais un identifiant humain emprunté. Cette identité est la clé de voûte de tous les contrôles aval. Sans elle, les logs d’audit ne peuvent pas séparer les actions de l’agent de celles d’un humain, ce qui rend impossible toute démonstration de conformité.

La gestion des identifiants doit privilégier des solutions d’identité fédérée de workload (workload identity federation) et des tokens courts automatiquement rotés, plutôt que des secrets stockés. Lorsque l’agent agit pour le compte d’un utilisateur, le standard OAuth 2.0 Token Exchange (RFC 8693) permet de déléguer l’autorité tout en préservant la distinction entre l’identité propre de l’agent et les droits qu’il exerce. En pratique, plutôt que de réutiliser le jeton de session d’un humain, on émet un jeton dédié à l’agent avec un périmètre limité et une durée de vie courte.

Autorisation fine et contrôle d’accès

L’authentification établit l’identité ; l’autorisation détermine le périmètre d’action. Le cadre NIST SP 800-53 Rev. 5 s’applique sans modification aux identités agent, notamment les contrôles de moindre privilège (AC-6), de séparation des tâches (AC-5) et de limitation des actions autorisées. Mais le point d’application doit être plus proche de l’action qu’une simple porte d’entrée.

Voici les contrôles recommandés pour borner le comportement d’un agent :

Dans la pratique, ces contrôles doivent être implémentés au niveau de la couche d’exécution de l’agent (par exemple via un proxy d’API ou un service de médiation), et non pas seulement au niveau de l’accès réseau ou du fournisseur d’identité.

Audit, surveillance et capacité de révocation

Les contrôles de conception ne deviennent défendables que si l’environnement peut montrer ce que l’agent a effectivement exécuté. La famille AU (Audit and Accountability) du NIST SP 800-53 exige des enregistrements suffisants pour reconstruire une séquence d’actions, pas seulement une attestation qu’une politique existait.

La surveillance des agents doit être comportementale et non uniquement basée sur les logs d’authentification. Il faut comparer l’intention de la tâche (ce que l’agent est supposé faire) avec l’exécution réelle (ce qu’il a fait) à travers les applications et l’infrastructure. Cette comparaison nécessite une découverte des identités agent depuis les applications elles-mêmes, et pas seulement depuis l’annuaire central.

La capacité de révocation est tout aussi cruciale. Lorsque la surveillance détecte un écart entre l’intention et l’exécution, il faut pouvoir révoquer les droits délégués en temps réel, avant que l’agent n’achève sa chaîne d’actions. Cela implique une intégration étroite avec le point d’application des contrôles.

Comment sélectionner le meilleur framework IAM pour vos agents IA

Le choix d’un framework IAM pour agents IA ne doit pas se limiter à un catalogue de connecteurs. Il doit évaluer la capacité à couvrir toute la chaîne de contrôle, de la propriété de l’identité jusqu’à la preuve d’exécution.

Critères d’évaluation pour un environnement d’entreprise

Voici les critères décisionnels à passer en revue avant de choisir une architecture :

1. Modèle de propriété : chaque identité agent peut-elle être tracée jusqu’à un humain responsable de sa finalité et de son expiration ?
2. Architecture des identifiants : le système supporte-t-il des identités fédérées de workload avec des credentials courts, ou repose-t-il sur des secrets stockés ?
3. Délégation d’autorisation : l’identité propre de l’agent est-elle préservée séparément des droits utilisateur qu’il exerce, avec une délégation limitée et révocable ?
4. Couverture de découverte : les identités agent sont-elles découvertes depuis les applications et l’infrastructure, ou seulement depuis le fournisseur d’identité et l’IAM ?
5. Télémétrie d’exécution : l’architecture capture-t-elle les actions au niveau applicatif (invocation d’outil, accès aux données, utilisation de privilèges) ou seulement les événements d’authentification ?
6. Portée de l’application des contrôles : l’autorité peut-elle être contrainte ou révoquée au point d’action, dans le temps d’une chaîne de tâches autonomes ?
7. Preuve d’audit : le système produit-il une preuve basée sur la télémétrie du comportement de l’agent, ou seulement des attestations qu’un contrôle a été configuré ?

Construire, acheter ou étendre une plateforme existante ?

Pour la plupart des entreprises qui ont déjà un programme de gouvernance IAM, étendre la plateforme existante est le point de départ le plus 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 éparpillé.

Des plateformes de gouvernance comme SailPoint ou Saviynt traitent la partie conception du problème : gestion du cycle de vie, politiques, provisioning. Toutefois, leur couverture des identités non-humaines et agents évolue rapidement ; il est impératif de vérifier les fonctionnalités actuelles auprès de l’éditeur.

Construire devient pertinent lorsque les frameworks d’agents sont propriétaires et que l’application des contrôles doit être intégrée dans le runtime lui-même. Acheter une solution tierce est utile pour la couche que les plateformes de gouvernance ne fournissent généralement pas : la découverte des identités agent directement depuis les applications et l’infrastructure, et la vérification que l’exécution correspond à l’intention.

Dans la pratique, de nombreuses organisations combinent les trois : elles étendent la plateforme pour le cycle de vie, construisent des contrôles d’application pour l’exécution, et achètent une solution d’observabilité pour la vérification.

Mise en œuvre : étapes concrètes et cas d’usage

Pour passer de la théorie à la pratique, examinons deux cas d’usage typiques en entreprise et les phases de maturité à franchir.

Agent de support client interne

Prenons un agent interne qui résout des tickets de support en interrogeant un CRM, un système de ticketing et une base de connaissances. Du point de vue du fournisseur d’identité, cet agent effectue quelques authentifications par jour - un profil banal. Mais à l’intérieur des applications, il interroge des données clients, exporte des rapports et met à jour des droits.

Un fournisseur d’identité seul rapportera que l’agent est bien gouverné. La télémétrie applicative, elle, révélera l’accès réel aux données et l’invocation d’outils. La capacité de détection dépend de cette seconde vue, car le comportement critique n’atteint jamais le log d’authentification.

Pour sécuriser cet agent, il faut :

• Lui attribuer une identité distincte avec un propriétaire humain ;
• Limiter ses droits aux seules API de consultation et de mise à jour des tickets (pas de modification des profils clients) ;
• Journaliser chaque appel API avec l’identité de l’agent, l’action, les données consultées ;
• Mettre en place une alerte si l’agent tente d’accéder à une API non autorisée.

Agent d’approvisionnement avec délégation de droits

Un agent d’approvisionnement illustre parfaitement le problème de délégation. Sa tâche approuvée est de récupérer les prix des fournisseurs. Les droits qui lui sont accordés couvrent toute la surface d’API du module d’approvisionnement. Or, par enchaînement de raisonnements, l’agent peut décider d’initier un bon de commande. Trois artefacts distincts apparaissent alors : l’intention (récupérer les prix), l’habilitation (accès à toutes les API), et l’exécution (passer une commande). Seule la troisième décrit ce qui s’est réellement passé.

Pour y remédier, il faut mettre en place une autorisation par périmètre de tâche : l’agent reçoit un jeton temporaire qui ne couvre que l’API de consultation des prix, avec interdiction d’écriture. Si l’agent tente d’écrire, l’appel est bloqué par le point d’application.

« Un framework qui gouverne le provisioning sans observer l’exécution produit une intention politique, pas une assurance opérationnelle. »

Phases de maturité de la gouvernance

La mise en place d’un cadre IAM pour agents IA s’inscrit dans une progression par étapes :

La phase 3 est l’objectif à atteindre pour une entreprise confrontée à des obligations de conformité (RGPD, certification ISO 27001, directive NIS 2). Elle nécessite des outils de découverte et d’observabilité qui complètent la plateforme IAM existante.

L’avenir de l’IAM dans un monde d’IA agentique

À mesure que les agents deviennent plus autonomes et capables de déléguer entre eux, les défis de l’IAM s’intensifient.

Politiques lisibles par machine et confiance agent-à-agent

Lorsqu’un agent délègue une sous-tâche à un autre agent, l’autorité se propage à travers une chaîne qu’aucun humain n’a approuvée étape par étape. Une réponse émergente est la politique lisible par machine : l’autorisation est exprimée sous une forme que les agents peuvent évaluer et appliquer à l’exécution. Des travaux de standardisation sont en cours sur les credentials d’agent vérifiables et la délégation contrainte, mais l’interopérabilité entre frameworks d’agents n’est pas encore stabilisée.

L’exigence de gouvernance, elle, ne change pas. Chaque maillon de la chaîne doit avoir une identité, un périmètre, une expiration et un humain in fine responsable. Le catalogue MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) constitue une référence utile pour anticiper les modes d’attaque de ces chaînes.

Autorisation continue pour les systèmes adaptatifs

L’autorisation continue remplace la décision d’admission unique par une évaluation en temps réel, qui réévalue les droits au fur et à mesure que le comportement de l’agent, les sources de données et le contexte d’exécution évoluent. Elle ne fonctionne que là où il existe un signal comportemental, ce qui ramène au point de départ : un cadre IAM pour agents IA qui gouverne le provisioning sans observer l’exécution produit une intention politique, pas une assurance opérationnelle.

Conclusion : de l’intention politique à la preuve d’exécution

Les agents IA sont déjà à l’œuvre dans vos systèmes. La question n’est pas de savoir s’ils agissent, mais si votre environnement est capable de prouver ce qu’ils ont fait. Un cadre IAM adapté aux agents IA ne se limite pas à attribuer des identités et des droits ; il doit aussi fournir les mécanismes de surveillance et de contrôle qui transforment une politique en preuve d’exécution.

En suivant les piliers décrits - identité attribuable, autorisation fine, audit comportemental - et en évaluant votre maturité selon les phases proposées, vous pouvez progressivement sécuriser vos agents IA tout en répondant aux exigences réglementaires. Le chemin est itératif : commencez par inventorier et attribuer des propriétaires à chaque agent, automatisez ensuite le cycle de vie, puis déployez les capacités d’observabilité.

L’enjeu est de taille : ne pas maîtriser l’IAM de vos agents IA expose votre organisation à des fuites de données, des non-conformités et une perte de contrôle sur vos systèmes critiques. À l’inverse, une gouvernance robuste des identités non-humaines devient un avantage concurrentiel, en permettant un déploiement confiant de l’IA autonome.

N’attendez pas que l’incident vous force à agir : évaluez dès aujourd’hui la maturité de votre cadre IAM pour agents IA.