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

67 % des entreprises déploient déjà des agents d’IA sans gouvernance identitaire structurée. Conséquence : des identités non-humaines invisibles, des permissions surdimensionnées et une absence de piste d’audit fiable. Alors que l’authentification et le contrôle d’accès traditionnels (IAM) peinent à suivre le rythme d’autonomie des agents, un nouveau cadre s’impose. Découvrez comment concevoir une architecture IAM pour agents IA, de l’attribution d’identité à la preuve d’exécution, en passant par les critères de choix d’un framework adapté au contexte français (RGPD, ANSSI, ISO 27001).

Pourquoi l’IAM traditionnel échoue face aux agents IA

Le fossé entre intention et exécution

Les plateformes IAM classiques excellent dans la gestion du cycle de vie des identités humaines : joiner-mover-leaver, SSO, règles d’accès au périmètre applicatif. Mais elles ne décrivent que l’accès configuré, jamais ce qu’un agent a réellement exécuté une fois à l’intérieur du système. Un agent peut enchaîner des appels API, sélectionner des outils, composer des actions qu’aucune revue d’habilitation n’avait anticipées. L’OWASP Top 10 for LLM Applications identifie ce mode de défaillance sous le terme excessive agency (LLM06) : un agent doté de permissions larges ou d’une autonomie excessive exerce des capacités au-delà de sa tâche approuvée. L’IAM traditionnel, centré sur des vérifications statiques, ne peut ni prévoir ni mesurer ce comportement.

En pratique, une configuration de rôles peut sembler correcte dans l’annuaire, mais l’exposition réelle dépend des permissions attachées à l’identité de l’agent, des systèmes accessibles depuis son contexte d’exécution et des conditions d’exploitation. Les constats de configuration décrivent une possibilité ; la télémétrie décrit ce qui s’est produit. C’est cette distance que l’IAM pour agents IA doit combler.

Cycles de vie des identités non-humaines

Contrairement aux employés, les agents sont souvent créés par l’automatisation d’infrastructure, des pipelines de déploiement ou des équipes applicatives - jamais par les workflows RH. Ils contournent ainsi les circuits de gouvernance qui détectent les anomalies d’accès humaines et s’accumulent hors de l’inventaire exigé par les obligations de conformité (par exemple, l’article 5 du RGPD sur la minimisation des données).

Les modes de défaillance récurrents incluent :

• Absence de propriétaire : aucun humain nommé n’est responsable de la finalité, du périmètre ou de l’existence continue de l’agent.
• Secrets longs : des clés API statiques persistent d’un déploiement à l’autre, sans rotation liée à la fin de vie de l’agent.
• Délégation illimitée : l’agent hérite en bloc des permissions de l’utilisateur ou du service, au lieu de recevoir une autorité limitée à sa tâche.
• Instanciation invisible : des agents créés par d’autres charges de travail ne sont jamais enregistrés dans le fournisseur d’identité (IdP) ni dans le système de gouvernance.
• Aucune expiration : un accès accordé pour un pilote reste actif bien après la fin du pilote.

Selon l’ANSSI, dans son guide de sécurisation des systèmes d’IA (2024), ces identités non-humaines représentent une surface d’attaque croissante, exploitée par des techniques de type « valid accounts abuse » (T1078 du MITRE ATT&CK).

Composants essentiels d’un cadre IAM pour agents IA

Pour répondre à ces défaillances, un cadre IAM pour agents IA doit couvrir trois dimensions : l’identité, l’autorisation et la preuve d’exécution. Aucun produit n’offre l’intégralité de ces briques ; elles s’assemblent généralement en combinant extension d’une plateforme existante, développement interne et achat de briques spécialisées.

Identité, authentification et gestion des credentials

Chaque agent doit posséder une identité distincte, attribuable, jamais un compte de service partagé ni un identifiant humain emprunté. L’attribution est le prérequis de tout contrôle aval, car une piste d’audit qui ne peut pas séparer l’activité de l’agent de celle de l’humain ne permet pas de démontrer la conformité au niveau de la mise en œuvre.

La gestion des secrets doit privilégier la fédération d’identité de charge de travail et des credentials à courte durée de vie, automatiquement renouvelés. Lorsque l’agent agit pour le compte d’un utilisateur, l’échange de jetons OAuth 2.0 (RFC 8693) permet de préserver la distinction entre l’identité propre de l’agent et l’autorité qui lui a été prêtée - distinction qui disparaît dès que l’agent réutilise simplement le jeton de session de l’utilisateur.

« L’authentification établit l’identité ; l’autorisation détermine le rayon d’explosion. » - NIST SP 800-53 Rev. 5

Autorisation fine et application des politiques

L’autorisation doit reposer sur des grants limités à une tâche, une allowlist d’outils, des frontières de données et des seuils d’action. Le point d’application doit se situer au plus près de l’action, non à la porte d’entrée de l’application.

Audits, surveillance et capacités de révocation

Les contrôles de conception ne deviennent défendables que lorsque l’environnement peut montrer ce que l’agent a exécuté. Le NIST AI RMF (AI 100-1) fait de la responsabilité et de la transparence des caractéristiques de fiabilité qui dépendent d’un comportement système traçable. La surveillance des agents doit être comportementale, pas simplement fondée sur des journaux d’authentification. Les attaques par abus de comptes valides génèrent des enregistrements d’authentification normaux ; la détection repose donc sur la comparaison entre la tâche prévue et l’exécution réelle, et sur la capacité à révoquer l’autorité déléguée en cas d’écart.

Comment choisir le bon framework IAM pour agents IA

La question « quel framework IAM utiliser pour les agents IA ? » n’a pas de réponse unique. Le choix dépend de la maturité de l’organisation, de son secteur (régulé ou non) et de la criticité des agents. Deux capacités sont souvent sous-estimées lors des évaluations : la vitesse de révocation et la qualité de la preuve. Les fonctionnalités de provisioning sont plus faciles à démontrer, mais ce sont la détection des écarts et la production de preuves télémétriques qui font la différence en environnement régulé.

Critères de décision pour l’IAM en entreprise

1. Modèle de propriété : chaque identité agent doit être traçable vers un humain responsable de sa finalité et de son expiration.
2. Architecture des credentials : le pattern supporte-t-il l’identité fédérée de charge de travail et des secrets courts, ou repose-t-il sur des secrets stockés ?
3. Autorisation déléguée : l’identité propre de l’agent est-elle préservée séparément de l’autorité utilisateur, avec délégation limitée et révocable ?
4. Couverture de découverte : les identités agents sont-elles découvertes depuis les applications et l’infrastructure, ou seulement depuis ce que l’IdP connaît déjà ?
5. Télémétrie d’exécution : l’architecture capture-t-elle les actions au niveau applicatif (invocation d’outil, accès données, utilisation de privilège), pas seulement les événements d’authentification ?
6. Portée d’application : l’autorité peut-elle être contrainte ou révoquée au point d’action, dans le laps de temps d’une chaîne de tâches autonome ?
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 IAM existante

Pour la plupart des entreprises disposant déjà d’un programme de gouvernance des identités, étendre la plateforme IAM existante est le point de départ raisonnable. Les workflows de cycle de vie, les chaînes d’approbation et la gouvernance des politiques existent déjà ; les reconstruire pour les agents fragmenterait un programme déjà souvent éparpillé. Des plateformes comme SailPoint ou Saviynt adressent la moitié conception du problème, mais leurs capacités agent évoluent rapidement - à vérifier dans la documentation actuelle.

Construire en interne se justifie lorsque les frameworks d’agents sont propriétaires et que l’autorisation doit être intégrée au runtime lui-même. Acheter 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 l’application dans le runtime, et acheter pour l’observabilité.

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

Voici un exemple de structure d’identité agent en JSON, intégrant les éléments clés décrits :

{
  "agentId": "agent-procurement-v2",
  "owner": "user:jean.dupont@entreprise.fr",
  "purpose": "Récupération des prix fournisseurs",
  "expiration": "2025-12-31T23:59:59Z",
  "credentials": {
    "type": "workload-identity-federated",
    "rotation": "24h"
  },
  "authorization": {
    "taskScopedGrant": "pricing:read",
    "allowedTools": ["api-fournisseurs", "base-prix"],
    "dataBoundaries": ["dataset-prix-publics"],
    "humanApprovalRequiredFor": ["purchase-order:create"]
  },
  "runtimeTelemetry": {
    "enabled": true,
    "logActions": ["toolInvocation", "dataAccess", "privilegeUse"]
  }
}

Cas d’usage concrets et modèles de mise en œuvre

Agents internes vs agents orientés clients

Prenons l’exemple d’un agent interne de traitement des tickets. Il interroge un CRM, un système de ticketing et une base de connaissances. L’IdP enregistre quelques authentifications par jour - un motif anodin. Pourtant, à l’intérieur des applications, le même agent consulte des fiches clients, exporte des données et met à jour des droits. Une vue uniquement fournisseur d’identité le présente comme bien gouverné ; la télémétrie applicative révèle les accès réels. La fiabilité de la détection dépend de cette seconde vue.

Dans un contexte français, le respect du RGPD exige que seules les données nécessaires à la tâche soient accessibles. Un agent non supervisé qui accède à des données personnelles non nécessaires constituerait une violation de l’article 5.1.c (minimisation).

Accès délégué entre outils, API et sources de données

Un agent d’achat illustre parfaitement le problème de délégation. Sa tâche approuvée est de récupérer les prix fournisseurs. Ses permissions accordées incluent toute la surface API des achats. Ses actions exécutées peuvent inclure la création de bons de commande, parce que la chaîne de tâches a raisonné jusqu’à cette action. Trois artefacts distincts : intention, habilitation, exécution. Seul le troisième décrit ce qui s’est réellement passé.

Un agent de déploiement détenant une identité de plan de contrôle élève encore les enjeux : les credentials d’automatisation d’infrastructure exigent des permissions larges, ce qui en fait des cibles de choix pour un attaquant. Un agent compromis peut remodeler l’environnement, y compris les contrôles censés le détecter.

Mise en œuvre progressive et gouvernance

La maturité de la gouvernance des identités agents se déploie en trois stades :

1. Gouvernance statique : les agents sont inventoriés comme identités non-humaines avec propriétaire, finalité et expiration ; les accès sont revus périodiquement. Fonctionne pour des pilotes, insuffisant pour des actions autonomes.
2. Gouvernance événementielle automatisée : le provisionnement, la rotation des credentials et la révocation se déclenchent sur des événements de déploiement et de retrait, non sur des calendriers de revue.
3. Observabilité continue des identités : le comportement de l’agent est observé à travers les applications et l’infrastructure ; l’exécution est comparée au périmètre de tâche prévu ; des preuves d’audit sont générées à partir de la télémétrie.

Ce troisième stade est celui où des solutions d’observabilité, comme celles proposées par des acteurs spécialisés, entrent en jeu : elles découvrent les identités directement depuis les applications et l’infrastructure, et non depuis les seules données de configuration IAM, révélant ainsi les identités agents, credentials et chemins d’accès que les systèmes d’identité fragmentés ne rapportent pas.

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

Politiques lisibles par machine et confiance agent-à-agent

Lorsqu’un agent délègue une sous-tâche à un autre, l’autorité se propage à travers une chaîne qu’aucun humain n’a approuvée étape par étape. La politique lisible par machine - une autorisation exprimée sous une forme que les agents peuvent évaluer et appliquer à l’exécution - est une réponse émergente. Parallèlement, des travaux de normalisation sur les credentials d’agent vérifiables et la délégation contrainte sont en cours, 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 a besoin d’une identité, d’un périmètre, d’une expiration et d’un humain in fine responsable. Le catalogue MITRE ATLAS, qui répertorie les tactiques et techniques adverses contre les systèmes d’IA, constitue un point de référence utile pour anticiper la manière dont ces chaînes seront attaquées.

Autorisation continue pour systèmes adaptatifs

L’autorisation continue remplace la décision unique d’admission par une évaluation permanente, réévaluant l’autorité au fur et à 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 ramène au point de départ : un cadre IAM pour agents IA qui gouverne le provisioning sans observer l’exécution ne produit que de l’intention politique, pas une assurance opérationnelle.

Agissez dès maintenant : sécurisez vos identités agents avec un cadre IAM adapté

L’autonomie croissante des agents d’IA exige une refonte de la gestion des identités. L’IAM traditionnel ne suffit plus. Un cadre complet combine identité attribuable, autorisation limitée à la tâche, credentials éphémères et surveillance continue de l’exécution. Les agents sont déjà à l’œuvre dans vos systèmes ; la question est de savoir si votre environnement peut prouver ce qu’ils ont fait. En adoptant une approche progressive, en évaluant vos plateformes IAM existantes et en intégrant une couche d’observabilité, vous transformerez l’intention politique en assurance opérationnelle - et respecterez les exigences du RGPD, de l’ANSSI et des normes ISO 27001. Le moment d’agir, c’est maintenant.