Les agents IA ne correspondent pas à la dichotomie utilisateur-ou-service. Ils agissent pour le compte des personnes, composent des outils et accomplissent des tâches par rafales. La gestion traditionnelle des identités attend des rôles durables, des groupes statiques et une recertification périodique. Les agents ont besoin de permissions éphémères, ciblées par intention, qui expirent à la fin du travail. Ils ont aussi besoin de traçabilité : quel humain a initié la tâche, quels outils et ensembles de données ont été utilisés, et quelle politique a autorisé ou refusé chaque action. En l’absence de cela, les auditeurs constatent des lacunes, les intervenants en cas d’incident voient des zones grises, et les attaquants trouvent des identifiants permanents et des jetons API trop larges. Le changement consiste à reconnaître les exécutions d’agents comme des principaux pouvant s’authentifier, s’autoriser et être entièrement audités.

Les modes d’échec courants apparaissent rapidement : les agents héritent de rôles humains beaucoup trop larges ; les comptes de service partagés contournent le moindre privilège ; SCIM et RBAC ne suivent pas le rythme des cycles d’accès à l’échelle de la minute ; et les revues trimestrielles manquent les pics risqués entre les audits. Les files d’attente de tickets retardent le travail légitime et normalisent les exceptions de politique. Une fois que plusieurs agents enchaînent des actions à travers CRM, dépôts de code et entrepôts de données, vous obtenez une dérive des droits et une journalisation partielle entre systèmes. Le résultat est un bruit coûteux pour les équipes de sécurité et une exposition réelle pour les données réglementées. Sans droits d’exécution et révocation automatique liés à l’usage, le risque résiduel s’accumule à chaque nouveau flux de travail d’agent.

Un modèle efficace ressemble à ceci : émettre une identité d’exécution unique à chaque exécution d’agent ; demander des identifiants au moindre privilège et limités dans le temps liés à l’intention déclarée et à la classification des données ; signer et attester chaque étape (entrée, appel d’outil, accès aux données) ; évaluer continuellement le risque à l’aide de signaux provenant de l’IdP, de l’EDR, du réseau et de la télémétrie applicative ; et révoquer ou réduire les droits dès que le comportement diverge. Cartographier toutes les relations dans un graphe d’identité reliant le délégant humain, l’exécution de l’agent, les outils, les ensembles de données et les politiques. Favoriser les mécanismes alignés sur les standards quand c’est possible (liaison de jetons/DPoP, extensions OIDC/OAuth, SPIFFE/SPIRE pour les identités de charge de travail, délégation fine de type GNAP) pour réduire le verrouillage et faciliter les audits.

Phase 1 (Semaines 1-3) : inventorier les flux de travail des agents et les frontières de données ; intégrer l’IdP (Okta/Entra), SIEM, gestionnaire de secrets et principaux outils SaaS/données. Définir la politique en tant que code avec des étiquettes pour la sensibilité et les intentions. Phase 2 (Semaines 4-7) : pilote sur le triage des tickets et les mises à jour CRM ; activer les droits just-in-time ; simuler les politiques sur les journaux historiques ; établir des déclencheurs de risque et des procédures opérationnelles. Phase 3 (Semaines 8-12) : étendre à un flux de travail d’extraction de données ou de dépôt de code ; appliquer la révocation automatique et la réduction basée sur les anomalies ; alimenter les résultats dans l’audit. Suivre quatre indicateurs : réduction des droits permanents, temps moyen d’octroi, temps moyen de révocation et exhaustivité de l’audit. Éviter les anti-modèles : jetons partagés, héritage de rôle global et exceptions manuelles.

L’identité sécurisée pour agents ne restera pas une niche. Les fournisseurs IdP, PAM et CIEM en place se précipitent pour ajouter la délégation éphémère, l’autorisation en temps réel et le nettoyage basé sur l’usage. Les acheteurs doivent s’attendre à une consolidation autour de la politique en tant que code, des graphes d’identité et des standards qui lient les jetons aux agents et appareils (par exemple, liaison de jetons/DPoP), ainsi que des systèmes d’identité de charge de travail (SPIFFE/SPIRE) et des modèles de fédération adaptés aux chaînes d’outils. La pression réglementaire mettra l’accent sur la provenance, le moindre privilège et la limitation des violations. Les déclencheurs d’achat incluront la preuve de latence de révocation sous charge, l’étendue des connecteurs et la compatibilité avec les IdP, SIEM et magasins de secrets existants. Les gagnants offriront une assurance en temps réel sans ajouter de friction aux développeurs.