Le rôle de l’IA dans l’IAM : sécuriser les nouvelles frontières de l’autonomie

L'IA dans la gestion des identités et des accès (IAM) répond à deux défis convergents. Il régit les agents d'IA autonomes et les identités non humaines (NHI) en tant que citoyens de première classe dans le cadre de la gestion des accès à l'entreprise. Il utilise l'analytique comportementale et l'orchestration basée sur les risques pour appliquer les politiques d'identité à une vitesse comparable à celle des machines. Alors que l'IAM traditionnel repose sur des contrôles statiques et ponctuels, les systèmes pilotés par l'IA fournissent une évaluation et une autorisation d'accès en continu pour les utilisateurs humains, les comptes de service, les clés API et les agents autonomes opérant à l'échelle du nuage.

Dans les environnements cloud natif, les comptes de service et les clés API sont souvent plus nombreux que les utilisateurs humains. Ils peuvent fonctionner avec une surveillance limitée, ce qui rend les frameworks de gouvernance centralisés essentiels pour l’application quasi en temps réel des politiques et la détection des menaces d’identité (ITDR).

Cinq contrôles clés pour les agents d'IA

Les organisations doivent traiter les agents d'IA comme des identités de premier ordre.

Contrôles pour sécuriser les flux de travail agentiques :

1. Appliquer l'autorité déléguée
   Les agents d'IA doivent utiliser des politiques d'accès explicites et déléguées plutôt que des identifiants humains. Les modèles normalisés, tels que l'échange de jetons OAuth 2.0(RFC 8693) ou la fédération d'identités de charge de travail, émettent des assertions de courte durée et de portée limitée. L'échange de jetons permet à un agent d'échanger son propre jeton d'identité contre un token d'accès à portée limitée avec des autorisations déléguées, sans exposer les identifiants primaires de l'utilisateur. Ces assertions permettent d'éviter l'usurpation d'identifiants et d'établir une chaîne de confiance cryptographique.
2. Appliquer une autorisation fine (FGA)
   Le contrôle d'accès basé sur les rôles (RBAC) est trop général pour les décisions pilotées par l'IA. Déployez des modèles basés sur les relations (ReBAC) ou sur les attributs (ABAC) pour appliquer des autorisations précises et adaptées au contexte. Un agent ayant une relation « viewer » peut résumer des documents de projet, mais ne peut pas exporter des données vers des API externes.
3. Exécuter la gestion de la sécurité des identités (ISPM)
   L'ISPM offre une découverte continue dans tout le paysage identitaire. Le système identifie les autorisations OAuth non autorisées, les comptes de service et les jetons pouvant être associés à l'IA fantôme. L'ISPM aide les équipes sécurité à détecter la prolifération des identifiants et les dérives en matière d'autorisation avant qu'elles ne soient exploitées.
4. Déclenchez des actions humaines en boucle (HITL) pour les actions à haut risque.
   Les opérations sensibles, telles que la suppression de données de production, déclenchent des workflows d'approbation humaine basés sur des standards, tels que l'authentification par canal de retour initiée par le client (CIBA). Le serveur d'autorisation interrompt l'exécution de l'agent et envoie une demande d'approbation au terminal enregistré de l'humain. L'agent reste dans un état non privilégié jusqu'à ce qu'il reçoive une approbation explicite.
5. Permettre l'évaluation continue de l'accès (CAEP)
   Exploitez le Shared Signals Framework (SSF) et le CAEP pour révoquer l'accès des agents en temps quasi réel lorsque le contexte de risque change. Lorsqu'elle est prise en charge, la révocation en fonction des événements permet d'étendre la sécurité au-delà des sessions statiques. Le système réagit de manière dynamique aux anomalies comportementales ou aux changements d'infrastructure.

IAM traditionnelle contre IAM pilotée par l'IA

Quand mettre en œuvre l'IA dans l'IAM ?

La gestion traditionnelle des identités fonctionne lorsque la création d'identités reste gérable par la gouvernance humaine. 

L'IAM piloté par l'IA devient essentiel lorsque :

• Les identités non humaines surpassent en nombre les utilisateurs humains
• Les comptes de service et les clés API se multiplient plus rapidement que ce que les vérifications manuelles peuvent suivre.
• Les agents d’IA ont besoin d’un accès autonome aux ressources de l’entreprise.
• La conformité exige une autorisation continue et des pistes d’audit.
• Les outils d’IA clandestins fonctionnent en dehors de la supervision informatique.

Comment l’IA transforme la sécurité des identités

Des vérifications statiques à l’authentification continue

L’identité IAM traditionnelle était vérifiée lors de la connexion, l’accès était accordé en fonction de rôles statiques, et la confiance était maintenue jusqu’à l’expiration de la session. Cette approche crée une fenêtre de vulnérabilité où le risque peut évoluer sans être détecté au cours d’une session.

L'IAM piloté par l'IA met en œuvre une autorisation continue et une évaluation de l'accès, en évaluant la confiance à chaque interaction. L'authentification prouve l'identité une fois. L'autorisation continue valide les droits d'accès pour chaque action sur la base d'une évaluation des risques en temps réel.

Les systèmes IAM modernes analysent les signaux contextuels en parallèle, y compris :

• La posture du terminal, telle que l'état de conformité, les niveaux de correctif et la configuration de sécurité
• Anomalies de localisation qui s’écartent du comportement historique et des modèles d’accès attendus
• Signaux comportementaux non humains tels que la fréquence des appels API, le temps d’exécution, l’entropie des requêtes et la séquence d’accès aux ressources
• Comparaisons avec des groupes de pairs pour comparer l'activité à celle d'utilisateurs ou d'agents similaires et identifier les valeurs aberrantes.
• Classification de la sensibilité des données pour évaluer si les demandes correspondent aux politiques d’accès aux ressources

Les scores de risque dynamiques regroupent ces données et déterminent les décisions d’accès de manière continue, en s’adaptant à l’évolution des conditions de la session.

Architecture de défense unifiée

L'écosystème de sécurité des identités est un architectural framework qui relie des outils de sécurité précédemment cloisonnés grâce à un contexte partagé et à une corrélation des signaux en temps réel. Il crée un plan de contrôle unifié où l'identité devient la principale frontière de sécurité.

Lorsqu’un agent d’IA demande l’accès, le système corrèle en temps réel les signaux de sécurité provenant de systèmes intégrés. Les indicateurs de Threat Intelligence, les modèles d’exfiltration de données SIEM et les actions de mise en quarantaine des terminaux se transforment d’événements isolés en Threat Intelligence corrélés.

Principaux avantages de l'intégration de l'IA dans la gestion des identités et des accès (IAM)

Automatisation du cycle de vie des identités à une vitesse comparable à celle des machines

Les environnements cloud-native génèrent des identités de machines plus rapidement que la gouvernance traditionnelle ne peut les suivre. Un seul cluster Kubernetes provisionne des milliers de comptes de service en quelques minutes. Les contrôles d'accès manuels ne peuvent pas suivre cette cadence. L’IA comble le déficit de gouvernance grâce à une gestion automatisée du cycle de vie.

Selon la norme NIST SP 800-207 (Architecture Zero Trust), les organisations doivent partir du principe "qu'un attaquant est présent dans l'environnement" et qu'"aucune confiance implicite n'est accordée à des actifs ou à des comptes utilisateur sur la seule base de leur emplacement physique ou de leur emplacement sur le réseau". Ce principe devient critique lorsqu'il s'agit de gérer les identités des machines qui prolifèrent plus rapidement que la surveillance humaine ne peut le faire.

Le provisionnement intelligent utilise des modèles qui analysent les exigences des rôles et le contexte du projet pour attribuer les autorisations appropriées. Le système révoque immédiatement les identifiants lorsqu’un agent d’IA ou un compte de service prend sa retraite. L’attestation continue valide la pertinence des autorisations en fonction des modèles d’utilisation réels, plutôt que par des examens manuels périodiques.

Découvrir l'IA de l'ombre

L'IA fantôme implique des outils d'IA non autorisés fonctionnant en dehors de la visibilité informatique. Ces outils accèdent aux données sensibles de manière autonome et peuvent exfiltrer des informations sans intervention explicite de l'utilisateur. Les vulnérabilités de la chaîne logistique dans les applications LLM présentent des risques critiques que les organisations ne peuvent pas atténuer si elles ignorent l'existence des systèmes d'IA.

ISPM permet la découverte continue et l’évaluation des risques liés aux identités dans l’ensemble de l’environnement, y compris les entités non enregistrées :

• La détection de la prolifération des identifiants identifie les tokens OAuth et les clés d'API avec des privilèges excessifs.
• La cartographie des accès aux données permet de suivre quelles applications et intégrations accèdent aux données de l’entreprise.
• L’analyse des dérives d’autorisation signale les comptes de service disposant d’un accès élevé qui sont restés actifs au-delà des exigences initiales.

Une sécurité adaptative pour une expérience utilisateur sans faille

L'IA rend les contrôles adaptatifs et améliore l'expérience utilisateur. Les contrôles deviennent stricts lorsque le risque est élevé et invisibles lorsque le risque est faible :

• L’authentification biométrique sans mot de passe aide à éliminer les vulnérabilités liées au vol d’identifiants tout en réduisant la latence d’authentification et l’exposition des identifiants.
• L'AMF adaptative basée sur le risque ajuste dynamiquement les exigences d'authentification. L'accès aux applications de routine à partir de terminaux connus se fait sans difficultés supplémentaires. Les tentatives d'accès aux systèmes financiers à partir de nouveaux lieux géographiques déclenchent une authentification renforcée ou un blocage dans l'attente d'une vérification.
• L’authentification renforcée contextuelle évalue en temps réel le risque en fonction des scores de Device Trust, des analytiques comportementales et des flux de Threat Intelligence, afin de déterminer les exigences d’authentification appropriées pour chaque requête.

Les utilisateurs accèdent sans difficulté aux ressources autorisées tandis que les équipes sécurité appliquent des contrôles basés sur les risques.

Sécuriser l’IA générative, des chatbots aux flux de travail agentiques

Le concept d’autorité déléguée

Les agents d'IA ne peuvent pas se faire passer pour des utilisateurs sans créer des lacunes en matière de responsabilité. Lorsqu'un assistant d'IA utilise les identifiants de l'utilisateur pour exécuter des actions, les journaux d'audit attribuent ces actions à l'utilisateur humain plutôt qu'au système autonome. Cela entraîne des défaillances en matière de conformité et obscurcit les enquêtes médico-légales.

L'autorité déléguée fournit un modèle d'autorisation formel dans lequel les agents d'IA agissent au nom des utilisateurs par le biais de subventions explicites plutôt que par l'usurpation d'identifiants mise en œuvre par le biais de modèles basés sur des standards. L'échange de jetons OAuth 2.0(RFC 8693) et les frameworks d'autorisation basés sur des assertions(RFC 7521/7522) spécifient les actions autorisées, les ressources cibles, les limites temporelles et les exigences conditionnelles.

La piste d'audit enregistre explicitement la délégation. Par exemple, lorsqu'un assistant de planification IA réserve une salle de conférence, le système enregistre « Agent-Calendar-Bot-v2, agissant au nom de user@company.com », a réservé Room-401 pour le 15.05.2026 de 14 h à 15 h UTC. La délégation reste vérifiable et révocable sans affecter les identifiants de l'utilisateur.

Autorisation granulaire (FGA) pour les agents d’IA

FGA permet de s'assurer que les agents d'IA n'ont accès qu'aux données spécifiques nécessaires à l'accomplissement des tâches qui leur sont confiées. Dans les architectures de génération augmentée par récupération (RAG), les systèmes d'IA interrogent les bases de connaissances de l'entreprise pour répondre aux questions.

Sans FGA, les organisations sont confrontées à un choix binaire : accorder un large accès et risquer une fuite de données, ou restreindre l'accès si sévèrement que l'agent ne puisse pas fonctionner. Le contrôle des accès basé sur les relations (ReBAC) permet des contrôles précis. "Cet agent IA peut lire les documents étiquetés projet=Phoenix, sensibilité=interne, mais ne peut pas accéder aux documents financiers=vrais, et ne peut que résumer le contenu, pas le copier ni l'exporter."

FGA s’étend au-delà du contrôle d’accès basé sur les rôles (RBAC) afin de mettre en œuvre une autorisation fondée sur les attributs et les relations.

• L'évaluation des attributs tient compte non seulement de l'identité de l'agent, mais aussi de l'action spécifique qu'il tente d'entreprendre
• L'évaluation du contexte des ressources inclut les ressources impliquées et leur classification de sensibilité.
• Les conditions temporelles tiennent compte du moment où les demandes sont formulées et de la conformité de ce délai avec les plages approuvées.
• Les contrôles de limitation de finalité vérifient que les demandes d’accès sont conformes au périmètre et à la finalité commerciale définis pour l’agent.

Human-in-the-loop (HITL) pour les actions à haut risque

La prise de décision autonome en matière d'IA nécessite une supervision pour les opérations à haut risque, telles que l'approbation des transferts financiers, la modification des politiques de sécurité ou la suppression des données de production.

L’authentification par canal arrière initiée par le client (CIBA), qui fait partie des spécifications OpenID Connect (OIDC), permet le consentement asynchrone de l’utilisateur. Dans son « flux découplé », le serveur d’autorisation demande l’approbation d’un utilisateur sur un terminal différent de celui utilisé pour lancer l’authentification. Cette approche permet une supervision HITL des agents d’IA effectuant des actions à haut risque.

Lorsqu’un agent d’IA tente une opération sensible, le workflow d'autorisation est interrompu et demande une approbation humaine :

• La préservation du contexte fournit aux examinateurs humains des informations complètes sur l’action tentée par l’IA et sa justification commerciale. 
• La diffusion multicanal achemine les demandes d'approbation vers les décideurs par le biais de notifications mobiles push, d'e-mails ou de SMS.
• L'état d'attente sécurisé maintient l'agent dans un état non privilégié dans l'attente d'une approbation explicite.
• L'exhaustivité de la piste d'audit enregistre chaque approbation ou refus avec des horodatages, l'identité de l'examinateur et des métadonnées contextuelles.

Les contrôles HITL permettent d'assurer une surveillance proportionnelle aux niveaux de risque.

Tendances futures : L'IA dans l'évolution de l'IAM

Protocole de contexte de modèle (MCP) : Normaliser les connexions entre l'IA et les entreprises

Le protocole Model Context (MCP) est une spécification préliminaire qui standardise la manière dont les agents d'IA interagissent avec les outils et les sources de données des entreprises. Si le MCP fournit un framework pour la connectivité et l’échange de contexte, le protocole ne définit pas de couche d’autorisation pour appliquer les politiques d’accès. MCP agit comme un conduit standardisé pour les politiques IAM, plutôt que comme un moteur de politique en soi.

Au fur et à mesure que la spécification évolue, le MCP peut permettre aux équipes IAM d'appliquer des contrôles de sécurité cohérents à travers divers fournisseurs de LLM et frameworks agentiques. 

Le protocole pourrait influencer l'architecture IAM dans quatre domaines anticipés :

• Les contrôles d’injection de contexte peuvent définir des ensembles de données spécifiques disponibles pour les systèmes d’IA lors de l’inférence. 
• L’autorisation d’action peut restreindre les opérations que les agents d’IA peuvent effectuer sur les ressources auxquelles ils ont accès. 
• La gestion des sessions peut établir des règles pour la durée et l'expiration de l'accès. 
• La transparence des audits peut permettre de mieux comprendre les données spécifiques qui sous-tendent les décisions en matière d’IA.

Les entreprises déployant des agents d’IA en production doivent surveiller le développement des MCP afin de se préparer aux exigences futures en matière de conformité et d’auditabilité. Les architectures IAM actuelles doivent rester flexibles pour intégrer ces protocoles émergents au fur et à mesure qu'ils arrivent à maturité.

Gouverner la main-d'œuvre numérique : Les INSA, première cible de l'attaque

Dans les entreprises cloud natif, les identités non humaines sont souvent plus nombreuses que les utilisateurs humains et continuent d'augmenter à mesure que l'automatisation se développe.

Les NHI (comptes de service, clés API, tokens OAuth, identifiants de pipeline CI/CD) sont devenus des cibles privilégiées pour les attaques car ils présentent généralement des autorisations plus larges, une authentification plus faible, des durées de vie des identifiants plus longues et une surveillance réduite.

Pour protéger la main-d’œuvre numérique, il faut traiter les INSA avec la même rigueur de gouvernance que celle appliquée aux humains. Les organisations devraient mettre en œuvre quatre piliers de gouvernance pour aider à sécuriser cette surface d'attaque en expansion.

• La rotation automatisée des identifiants remplace les secrets statiques à longue durée de vie par un accès en flux tendu (JIT) et des tokens à durée limitée afin de minimiser la période d’exposition.
• L'analyse comportementale déploie la détection des anomalies pour identifier les comptes de service qui s'écartent des modèles d'exécution établis ou qui accèdent à des séquences de ressources inhabituelles.
• L’application du principe du moindre privilège passe d’une gestion étendue et statique des droits d’accès à une définition dynamique des autorisations qui s’adapte en fonction de l’utilisation en temps réel et des besoins de l’entreprise.
• Des pistes d’audit complètes relient chaque action des identités non humaines (NHI) à un contexte commercial précis et à un responsable humain, à des fins de responsabilité judiciaire.

Les architectures IAM qui négligent la gouvernance identité non humaine ne parviennent pas à protéger les voies les plus vulnérables des infrastructures modernes. Pour atteindre une véritable posture de Zero Trust, il est nécessaire d’intégrer chaque agent autonome et chaque charge de travail dans un écosystème de sécurité des identités unifié.

Sécuriser l'IA dès la conception

L'identité est le plan de contrôle le plus évolutif et le plus conscient du contexte pour régir l'accès des acteurs humains et non humains opérant à l'échelle du cloud. Les contrôles du réseau, des données et des terminaux restent nécessaires, mais ne suffisent pas à eux seuls lorsque les agents d'IA opèrent dans les clouds, les plateformes SaaS et les écosystèmes de partenaires.

L’écosystème de sécurité des identités doit évoluer pour suivre le rythme opérationnel de l’IA grâce à :

• Zero Trust par défaut
• Autorisation continue à chaque demande
• Application dynamique du principe de moindre privilège
• Découverte continue grâce à l'ISPM
• Modèles de délégation explicites et vérifiables

Secure-by-design IA intègre les contrôles IAM directement dans les cycles de développement et de déploiement, et non comme des ajouts post-déploiement.

Foire aux questions (FAQ)

Quelle est la différence entre autorité déléguée et personnification ?

L’autorité déléguée utilise des modèles d’accès délégué inter-applications pour établir un lien vérifiable entre l’humain et l’agent, tandis que l’usurpation d’identité masque l’identité de l’agent derrière des identifiants humains.

Pourquoi l'autorisation à granularité fine (FGA) est-elle importante pour les agents d’intelligence artificielle ?

FGA signifie que les agents d’IA n’ont accès qu’aux données spécifiques requises pour leurs tâches désignées. Ceci est essentiel dans les architectures de génération augmentée par récupération (RAG), où l’IA interroge les bases de connaissances de l’entreprise, empêchant ainsi tout accès non autorisé ou toute exfiltration de données sensibles de l’entreprise.

Comment l’IA dans IAM soutient-elle l’architecture Zero Trust?

L’IA permet le Zero Trust en évaluant continuellement la confiance dans l’identité sur la base d’analyses comportementales et de signaux partagés (SSF/CAEP). Le Zero Trust traditionnel se concentre souvent sur la vérification de l’identité au périmètre du réseau. L'IAM piloté par l'IA va plus loin en réévaluant la confiance à chaque demande, en analysant la posture du terminal, les anomalies de localisation et les modèles comportementaux. Cela est conforme au principe Zero Trust du NIST, qui stipule qu'aucune confiance implicite ne doit être accordée sur la seule base de l'emplacement du réseau. Chaque décision d’accès devient un nouvel événement d’autorisation, plutôt que de s’appuyer sur une confiance basée sur la session établie lors de la connexion.

Construire une base sécurisée pour l'IA avec Okta

À mesure que les agents d'IA passent du stade du projet pilote à celui de la production, ils doivent faire l'objet de la même rigueur en matière d'Identity Governance que les utilisateurs humains. Okta étend les principes de l'écosystème de sécurité des identités aux agents d'IA grâce à l'ISPM pour une découverte continue, au FGA pour un contrôle des accès précis et à l'orchestration unifiée tout au long du cycle de vie de l'IA.

En savoir plus