De l’identité humaine à l’identité des AI Agents
Human Identity → Machine Identity → AI Agent Identity → Autonomous Agent
Le changement ne vient pas uniquement de la technologie utilisée pour s’authentifier. Il vient surtout du niveau d’autonomie associé à cette identité.
Un agent peut recevoir un objectif, sélectionner un outil, interroger plusieurs systèmes et enchaîner des actions sans qu’un utilisateur humain valide explicitement chaque étape. Microsoft recommande désormais de considérer chaque agent comme un first-class principal, avec une identité dédiée, un propriétaire identifié, des rôles explicites et un cycle de vie contrôlé.
Illustration 1 : Évolution de l’identité en entreprise
Quand un AI Agent devient un utilisateur privilégié
Selon sa fonction, ses accès peuvent devenir particulièrement sensibles : un agent IT peut intervenir sur l’infrastructure, un agent Finance accéder aux données financières et un agent RH manipuler des informations confidentielles. Dès qu’un AI Agent dispose de droits étendus, il doit donc être traité comme une identité privilégiée, avec des permissions clairement définies et limitées à ce qui est nécessaire à sa mission.
Microsoft souligne précisément le risque d’une accumulation progressive des permissions : un agent initialement conçu pour lire des informations peut ensuite recevoir des droits d’écriture lorsque son workflow évolue, sans que son modèle d’autorisation soit réellement repensé.
Le problème n’est plus seulement « qui se connecte ? »
Un agent peut disposer d’un accès parfaitement légitime et malgré tout réaliser une action non souhaitée si son périmètre est trop large. La sécurité doit donc associer quatre dimensions :
Identity → Permission → Tool → Action
Microsoft recommande notamment de limiter les permissions selon la ressource, la donnée et l’opération , lecture, écriture, export ou administration , tout en contrôlant explicitement les outils accessibles à l’agent.
Service accounts et API keys : les anciens réflexes deviennent risqués
Mais cette simplicité crée un problème d’attribution. Si cinq agents utilisent le même compte technique, quel agent a réellement exécuté l’action ? Si une clé donne accès à dix API alors que l’agent n’en utilise que deux, pourquoi maintenir les huit autres permissions ? Une identité dédiée permet au contraire d’associer chaque action à un agent précis, à son propriétaire et à sa mission. Microsoft recommande explicitement d’éviter les secrets partagés ou comptes réutilisés lorsque l’on veut conserver cette chaîne de responsabilité.
Le moindre privilège doit devenir dynamique
Le least privilege reste valable, mais son application aux AI Agents doit évoluer.
Un agent peut avoir besoin de consulter une information pendant quelques secondes, puis d’obtenir temporairement une autorisation supplémentaire pour réaliser une action.
Le compromis consiste donc à conserver un niveau de privilège permanent minimal et à utiliser, lorsque nécessaire, des tokens courts, des droits temporaires ou des approbations Just-in-Time.
Une action sensible , suppression, export massif, changement de permissions ou déploiement , peut également déclencher une validation humaine supplémentaire. Microsoft recommande précisément cette combinaison entre identité stable et privilèges temporaires pour les workflows agentiques.
Illustration 2 : AI Agent Privilege Model
Accès permanent minimal → demande d’action → contrôle du contexte → élévation temporaire → exécution → journalisation → révocation
Ce modèle évite qu’un agent conserve en permanence les privilèges maximum nécessaires à toutes les situations qu’il pourrait rencontrer.
Les secrets ne devraient pas appartenir à l’agent
API keys, tokens, certificats et credentials représentent une autre surface critique.
Le principe architectural consiste à séparer autant que possible la décision de l’agent et l’autorisation effective de l’action.
L’agent peut déterminer qu’il doit interroger un ERP. Cela ne signifie pas qu’il doit conserver lui-même une clé permanente lui donnant accès à l’ensemble de cet ERP.
Une couche IAM ou un mécanisme d’autorisation doit pouvoir vérifier l’identité de l’agent, le contexte, l’action demandée et le périmètre autorisé avant de délivrer l’accès nécessaire.
En pratique, l’objectif devient : Agent asks → Identity verifies → Policy authorizes → Tool executes → Audit records
Agent-to-Agent : une nouvelle chaîne de confiance
La difficulté augmente avec les architectures multi-agents.
Un agent principal peut déléguer une tâche à un second agent, qui appelle lui-même une API ou un troisième service :
Utilisateur → Agent A → Agent B → Tool/API → Application métier
Chaque délégation constitue potentiellement une nouvelle frontière de confiance.
Le système doit pouvoir déterminer quel agent est à l’origine de la demande, quel agent exécute réellement l’opération, quelles permissions ont été déléguées et au nom de quelle identité l’action finale est réalisée.
Les recommandations de sécurité publiées en 2026 considèrent justement les relations agent-to-agent et les appels d’outils comme des décisions de confiance distinctes devant être explicitement autorisées.
Le point souvent négligé : le cycle de vie
Les entreprises risquent progressivement de rencontrer un problème déjà connu avec les comptes techniques : l’agent sprawl.
Un agent est créé pour un projet. Le projet évolue. Son propriétaire change de fonction. Certaines API ne sont plus utilisées. Pourtant, son identité, ses tokens ou ses permissions restent actifs.
La gouvernance doit couvrir tout le cycle :
Create → Approve → Operate → Review → Revoke → Delete
L’auditabilité devient une exigence d’architecture
Lorsqu’un incident survient, savoir qu’« une API a été appelée » ne suffit plus.
Le CISO doit pouvoir reconstruire :
quel agent → sous quelle identité → au nom de quel utilisateur → avec quel rôle → via quel outil → sur quelle ressource → pour quelle action.
C’est précisément l’une des orientations prises par l’OWASP Agent Control Standard publié le 1er septembre 2026 : les agents doivent être inspectables, traçables et contrôlables, avec une visibilité sur ce qu’ils peuvent consulter, ce qu’ils ont réalisé et les contrôles applicables à l’exécution.
Pour une entreprise tunisienne, où se situe réellement le risque ?
Le sujet ne consiste pas à appliquer une architecture différente simplement parce que l’entreprise est tunisienne. Les principes IAM restent les mêmes.
Le contexte devient néanmoins particulièrement important lorsque les agents accèdent à des systèmes critiques ou à des données sensibles, notamment dans la banque, l’assurance, les télécoms, l’industrie ou le secteur public.
Une entreprise doit notamment savoir où sont exécutés ses agents, où transitent leurs credentials, quelles API externes interviennent dans le workflow, où sont conservés les logs et quelles données peuvent quitter son environnement.
Framework Focus : AI Agent Identity Control
Illustration 3 : AI Agent Identity Control Framework
Cette matrice constitue un modèle qualitatif de priorisation, et non une statistique de risque.
Le point important est de ne pas classer un agent uniquement selon le modèle IA qu’il utilise. La criticité dépend surtout des données, outils, permissions et actions auxquels il est connecté.
Ce que les CIO et CISO doivent faire dès maintenant
Pour les organisations qui commencent à connecter des agents à leur SI, la priorité n’est probablement pas de créer une nouvelle couche de sécurité entièrement séparée.
Il faut d’abord étendre les pratiques IAM existantes aux nouvelles identités non humaines : inventorier les agents, supprimer les credentials partagés, attribuer une identité distincte, définir un propriétaire humain, appliquer le least privilege, utiliser des droits temporaires pour les opérations sensibles et tester réellement les mécanismes de révocation.
Microsoft recommande en 2026 de commencer précisément par l’inventaire des identités agentiques, la suppression des rôles trop larges, l’introduction de RBAC lié aux tâches et la mise en place d’une auditabilité de bout en bout avant d’étendre les déploiements.
Vers 2027 : l’AI Identity pourrait devenir une nouvelle couche de l’IAM
Il s’agit ici d’une projection, et non d’un fait établi.
L’évolution observée en 2026 suggère néanmoins que la gestion des AI Agents pourrait progressivement rejoindre les disciplines traditionnelles IAM, PAM et machine identity.
Microsoft dispose désormais d’Entra Agent ID, conçu pour authentifier, autoriser et gouverner les identités non humaines associées aux agents. Le NIST travaille parallèlement sur l’application des standards d’identité et d’autorisation aux agents logiciels, tandis que l’OWASP développe des standards spécifiques de contrôle des systèmes agentiques.
Le prochain défi des entreprises pourrait donc ne plus être seulement :
« Combien d’utilisateurs privilégiés avons-nous ? » mais : « Combien d’identités humaines, machines et agentiques peuvent réellement agir sur notre SI ? »
L’identité devient le point de contrôle de l’AI Agent
Les AI Agents ne rendent pas les principes IAM obsolètes. Ils rendent leur application plus exigeante.
Lorsqu’une IA dispose d’une identité, de credentials, de permissions et d’outils lui permettant d’agir, elle devient une nouvelle identité opérationnelle du système d’information.
La priorité n’est donc pas simplement de sécuriser le modèle. Elle consiste à savoir qui est l’agent, ce qu’il peut faire, au nom de qui il agit et comment arrêter immédiatement son accès lorsque cela devient nécessaire.
C’est à cette condition que l’autonomie peut augmenter sans faire disparaître le contrôle.
Identifiez vos AI Agents, comptes de service, credentials et privilèges afin de mesurer les nouvelles surfaces d’accès introduites dans votre système d’information.
FAQ — AI Agent Identity
Une identité distincte permet d’identifier précisément l’agent, de limiter ses permissions, d’attribuer ses actions et de révoquer ses accès sans affecter d’autres utilisateurs ou applications.
Une machine identity authentifie généralement une application ou un workload dont les opérations sont relativement prédéfinies. Un AI Agent peut sélectionner des outils et enchaîner différentes actions selon son objectif et son contexte.
Il faut limiter ses ressources, données, outils et opérations autorisées, puis utiliser des tokens courts ou une élévation temporaire lorsqu’une tâche nécessite exceptionnellement davantage de privilèges.
L’organisation doit pouvoir désactiver son identité, invalider ses tokens, révoquer ses credentials et bloquer ses accès aux outils et API. Ces mécanismes doivent être testés avant un incident.
Oui. Chaque interaction agent-to-agent peut représenter une nouvelle frontière de confiance. L’identité de l’agent demandeur et l’autorisation de l’action doivent donc pouvoir être vérifiées.