Okta, Azure AD et Lutril : qui gère les accès quand les agents IA entrent en scène ?

La question que l’IT commence à poser

La plupart des entreprises du mid-market et des grands comptes ont investi du temps pour bien faire leur IAM. Elles ont Okta ou Azure AD configuré en SSO sur tous leurs outils SaaS majeurs, le provisionnement SCIM branché sur leur SIRH, le MFA imposé partout, et des politiques de cycle de vie qui révoquent les accès quelques minutes après un événement de départ. Ce travail est réel, il compte, et il fonctionne bien.

Puis l’équipe d’ingénierie ou d’exploitation déploie un agent IA. L’agent doit lire et écrire dans Salesforce. Il doit créer des tickets Jira, publier dans Slack, puiser dans une base de connaissances. Les demandes d’accès arrivent sur le bureau de l’IT, et le manuel habituel ne colle pas. L’agent n’est pas un humain. Il n’a pas de manager. Il n’a pas de cycle de vie qui corresponde à une embauche et à un départ. Il passe des dizaines ou des centaines d’appels d’outils par heure, guidé par la sortie d’un LLM plutôt que par une intention délibérée d’utilisateur.

La question que l’IT commence à poser est : mon IAM actuel couvre-t-il cela, ou me faut-il autre chose ?

La réponse honnête : votre IAM actuel est la bonne fondation, mais il ne couvre pas nativement les agents. Voici précisément ce que chaque produit prend en charge, et où se situe la frontière.

Ce que fait Okta (et ce qu’il ne fait pas)

Okta excelle réellement dans ce pour quoi il a été bâti. Ses capacités centrales sont profondes et éprouvées sur des milliers de déploiements en entreprise.

• L’authentification unique. Le catalogue SSO d’Okta couvre des milliers d’intégrations SaaS. Les collaborateurs s’authentifient une fois et accèdent à toutes les applications connectées sans ressaisir d’identifiants. La couverture et la fiabilité sont ici parmi les meilleures du marché.
• La gestion du cycle de vie avec SCIM. Quand une personne arrive ou part, Okta propage automatiquement le changement à toutes les applications connectées. Le déprovisionnement au départ est fiable et rapide, à condition que SCIM soit correctement configuré.
• Le MFA adaptatif. L’authentification fondée sur le risque évalue des signaux comme la posture de l’appareil, le réseau et la localisation avant de décider de challenger une connexion. Cela attrape des attaques par identifiants qui passeraient à travers une politique de mots de passe statique.
• Les politiques d’accès par groupes. Les attributions de rôles découlent des groupes, qui découlent de votre SIRH. Une nouvelle recrue en ingénierie reçoit automatiquement les bons outils. Une promotion d’analyste à manager déclenche les changements de rôle sans ticket manuel.

Là où Okta s’arrête, c’est au concept d’identité d’agent. Son annuaire est un annuaire d’humains et, dans une moindre mesure, de comptes de service. Quand vous ajoutez un agent IA, le contournement courant consiste à créer un compte de service dans Okta, à lui donner un identifiant machine, et à l’affecter aux groupes applicatifs pertinents. Cela fonctionne au premier degré. L’agent peut s’authentifier. Il peut accéder aux outils SaaS que vous lui accordez.

Ce qu’Okta n’a pas : un concept d’identité d’agent de plein droit, aucun mécanisme pour définir quels appels d’outils précis un agent peut effectuer au sein d’une application connectée, aucun journal d’audit consignant les séquences d’appels pilotées par un LLM, et aucun coupe-circuit capable d’arrêter une session d’agent en cours quand quelque chose dérape. Le contournement par compte de service a été conçu pour l’automatisation d’infrastructure, pas pour un agent piloté par LLM qui décide seul des actions à poser en fonction d’une tâche qu’on lui a confiée.

Ce que fait Azure AD (Entra ID), et ce qu’il ne fait pas

Microsoft a renommé Azure Active Directory en Microsoft Entra ID en 2023. Les capacités sous-jacentes sont solides, en particulier pour les organisations qui exploitent des charges Microsoft 365, de l’infrastructure Azure, ou les deux.

• Les politiques d’accès conditionnel. L’accès conditionnel d’Entra ID est l’un des moteurs de politique les plus granulaires de l’IAM d’entreprise. Vous pouvez exiger des appareils conformes, des conditions réseau précises, ou une force d’authentification donnée selon la sensibilité de l’application et les signaux de risque de l’utilisateur.
• Les identités managées pour les charges Azure. Pour les applications et services qui tournent dans Azure, les identités managées suppriment purement et simplement le besoin d’identifiants stockés. Une fonction Azure ou une VM reçoit une identité gérée par Azure, à laquelle vous attribuez des rôles RBAC. C’est bien conçu pour l’infrastructure native Azure.
• L’intégration Microsoft 365. Pour les organisations déjà dans l’écosystème Microsoft, Entra ID offre avec SharePoint, Teams, Exchange et Dynamics une intégration profonde qu’Okta ne peut pas égaler nativement.
• Privileged Identity Management (PIM). PIM permet l’activation de rôles juste-à-temps, avec des flux d’approbation et un accès limité dans le temps. Cela réduit les privilèges permanents sur les rôles sensibles.

Pour les agents IA, le tableau ressemble à celui d’Okta. Les identités managées fonctionnent bien si vos agents sont hébergés dans Azure et n’appellent que des API Azure. Dès qu’un agent doit appeler des API SaaS hors de l’écosystème Azure, comme Salesforce, Notion, Slack ou n’importe quel service connecté en MCP, les identités managées ne s’y étendent pas. L’agent a besoin d’un identifiant ou d’un jeton OAuth distinct, géré en dehors d’Entra ID.

Entra ID n’a pas de couche de politique pour les appels d’outils MCP. Il ne peut pas imposer qu’un agent ait le droit d’envoyer un message Slack sans pouvoir supprimer un canal. Il ne capte pas les séquences d’appels au niveau de l’agent. Ses journaux d’audit consignent les événements d’authentification et l’accès aux ressources au niveau du RBAC Azure, pas la sémantique de ce qu’un agent piloté par LLM a décidé de faire de l’accès qu’on lui a accordé.

La faille que les deux laissent ouverte

Okta et Azure AD ont été bâtis avant que les agents LLM n’existent comme réalité déployée. Ces failles ne sont pas des défauts d’exécution. Elles reflètent une frontière de périmètre qui avait tout son sens jusqu’à récemment.

Aucun des deux produits ne prend aujourd’hui en charge :

• L’identité d’agent dans l’annuaire. Il n’existe pas de type d’objet de plein droit « agent IA », avec des propriétés comme l’équipe propriétaire, la finalité, les outils autorisés et la durée de session. Le compte de service est un contournement, pas une réponse adaptée.
• L’application d’une politique par appel d’outil. Ni Okta ni Azure AD ne savent exprimer ni faire respecter une politique du type « cet agent peut lire les fiches du CRM mais pas modifier l’étape d’une opportunité ». Les permissions au niveau applicatif sont grossières. La granularité requise pour gouverner des agents n’existe pas dans le modèle IAM actuel.
• Des journaux d’audit inaltérables pour les appels d’outils d’un LLM. Quand un agent exécute une tâche en plusieurs étapes et appelle dix API à la suite, les journaux d’audit IAM existants consignent l’événement d’authentification. Ils ne consignent ni la séquence d’appels, ni la décision du LLM qui a précédé chaque appel, ni les données renvoyées. Cette trace disparaît à la fin de la session.
• Des coupe-circuits pour les agents en cours d’exécution. Si un agent se comporte de façon inattendue en pleine tâche, il n’existe aucun mécanisme dans Okta ou Azure AD pour arrêter cette session précise sans révoquer l’accès de tout le compte de service, ce qui peut affecter des systèmes sans rapport.
• La parité de rôles entre humains et agents. Dans un environnement bien gouverné, un humain disposant d’un accès en lecture seule à un système devrait se traduire par un agent doté du même accès en lecture seule. Cette correspondance n’existe pas. L’accès de l’agent se configure indépendamment des définitions de rôles humains qu’il est censé refléter.

Ce ne sont pas des cas marginaux. Ce sont les exigences de gouvernance de base pour toute organisation qui veut étendre sa posture de sécurité existante aux agents IA.

Comment ils se comparent

Sur les dimensions qui comptent pour une gouvernance des accès complète :

La bonne façon de lire ce tableau : les cases « Sans objet » de la colonne Lutril, sur les lignes d’identité humaine, ne sont pas des manques. Lutril ne cherche pas à remplacer Okta ou Azure AD pour le SSO et le cycle de vie des humains. Ce travail est déjà fait, et le refaire ne crée aucune valeur. Le tableau reflète un périmètre, pas une concurrence.

Pourquoi il vous faut les trois

La bonne architecture est en couches. Okta ou Azure AD prend en charge ce pour quoi il a été bâti : authentification des humains, gestion du cycle de vie, MFA, accès par groupes. Cette couche est solide et doit rester en place.

Lutril se pose par-dessus, comme couche de gouvernance des agents. Plutôt que de remplacer votre IdP, Lutril lit les définitions de rôles et de groupes de votre Okta ou Azure AD existant et s’en sert comme source de vérité pour déterminer ce que les agents ont le droit de faire. Si un analyste Salesforce n’a qu’un accès en lecture dans votre IdP, un agent agissant en son nom hérite du même accès en lecture. La parité est appliquée automatiquement, pas configurée à la main agent par agent.

Au-dessus de cette source de vérité, Lutril applique une politique par appel d’outil via MCP. Quand un agent tente un appel, la politique est vérifiée avant exécution : cet agent a-t-il le droit d’exécuter cet outil précis, à ce moment, dans ce contexte de tâche ? Si non, l’appel est bloqué et journalisé. Si oui, l’appel se poursuit et tout le contexte est inscrit dans une trace d’audit inaltérable.

L’intégration fonctionne aussi dans l’autre sens. Quand une personne fait l’objet d’un départ dans votre IdP, Lutril voit le changement et révoque ou suspend tout agent qui opérait en son nom. Vous n’avez pas besoin de construire un flux de départ distinct pour les agents. Le cycle de vie humain existant déclenche celui des agents.

Quand ajouter une couche d’accès pour les agents

Quelques déclencheurs précis indiquent le moment où le contournement par compte de service cesse d’être suffisant :

• Le premier agent IA avec accès à un SaaS. Dès qu’un agent peut écrire dans un système de production, le profil de risque change. Un accès en lecture seule à de la documentation interne n’engage pas grand-chose. Un accès en écriture à Salesforce, à Jira ou à tout système contenant des données clients demande une gouvernance qu’un compte de service ne peut pas fournir.
• La première question d’audit SOC 2 ou ISO 27001 sur les agents. Les auditeurs commencent à interroger les contrôles d’accès des agents IA. « Nous avons un compte de service » ne satisfait pas les critères de contrôle d’accès du CC6.1 ou de l’A.9 quand cet accès est exercé par un comportement autonome piloté par un LLM. Il faut une trace de politique, un journal d’audit, et la preuve d’une limitation de portée.
• Le premier départ d’une personne qui avait provisionné des agents. Quand l’ingénieur qui a monté l’agent s’en va, qui sait ce que cet agent peut faire ? Si la réponse est personne, l’agent survit à celui qui le comprenait. C’est le problème du shadow IT, appliqué à des systèmes autonomes.
• Plus d’une équipe qui déploie des agents. Quand plusieurs équipes ont des agents en production, la surface de gouvernance grandit plus vite que la capacité à la suivre manuellement. Une couche de politique centrale devient nécessaire à ce stade, et non plus optionnelle.

Si aucun de ces cas ne s’applique encore, l’approche par compte de service peut suffire pour l’instant. Dès que l’un d’eux se présente, c’est le bon moment pour ajouter une gouvernance d’agents dédiée, plutôt que d’étirer un modèle d’identité humaine au-delà de ce pour quoi il a été conçu.