Résumé
La gestion interne de l’identité des agents d’IA en entreprise devient rapidement une charge continue en matière de gouvernance et de conformité. Cette gestion implique de centraliser l’authentification, l’autorisation, la gestion du cycle de vie des tokens et la journalisation des audits pour l’ensemble des agents internes, tiers et non référencés (Shadow AI). La création d’une couche d’accès personnalisée entraîne des failles de sécurité, des échecs de conformité lors des audits et une charge constante pour les ingénieurs à mesure que les cahiers des charges MCP et OAuth évoluent.
Investir dans une couche d’identités centralisée pour les agents permet aux entreprises de dissocier l’accès aux outils de la gestion des identifiants, tout en facilitant l’auditabilité continue et la sécurité Zero Trust. Cela permet également à vos équipes d’ingénierie de se concentrer sur le développement des agents qui vous aident à mener à bien les missions essentielles de votre entreprise.
Qu’est-ce qu’une couche d’identités pour agents d’IA et comment est-elle conçue ?
Lorsque les agents d’IA ont commencé à agir plutôt qu’à simplement répondre aux questions, les équipes en charge des plateformes ont dû les connecter rapidement à des outils et à des données réels. De nombreuses équipes ont finalement conçu elles-mêmes une couche d’accès, qui comprend généralement trois éléments principaux :
- Une passerelle Model Context Protocol (MCP) qui achemine le trafic des agents vers les serveurs MCP
- Un courtier de tokens qui conserve et renouvelle les identifiants de chaque utilisateur et utilisatrice pour les applications SaaS auxquelles les agents font appel
- Un filtrage du champ d’application basé sur les rôles qui limite les outils qu’un agent peut utiliser en fonction du rôle de l’utilisateur
Ces développements ont nécessité plusieurs mois de travail d’ingénierie, permis de mettre les agents en production et empêché que les identifiants ne soient exposés dans les invites. Pour la plupart des équipes, développer en interne était la seule option à l’époque.
Téléchargez notre livre blanc AI Agent Identity: Build vs. Buy pour découvrir pourquoi l’acquisition d’une couche d’identités conçue spécifiquement est la solution la plus efficace pour gérer les agents d’IA tout au long de leur cycle de vie, sans imposer à votre équipe d’ingénierie une maintenance d’identités chronophage et sans fin.
Les six questions essentielles sur l’identité pour les agents d’IA en entreprise
À mesure que l’adoption des agents progresse et que les agents prennent en charge des tâches de plus en plus stratégiques pour l’entreprise, les équipes constatent qu’elles doivent répondre à davantage de questions :
- Identité de l’agent : Qui est chaque agent ?
- Propriété : Qui est responsable de l’agent ?
- Délégation : au nom de qui l’agent agit-il ?
- Permissions : à quels outils et ressources peut-il accéder ?
- Piste d’audit : Quelles actions précises ont été réalisées ?
- Arrêt d’urgence : comment les équipes révoquent-elles rapidement l’accès ou le neutralisent-elles ?
Comment le champ d’application s’amplifie
La première version de la création d’une couche d’accès pour les agents reste maîtrisable. Une équipe crée quelques agents, attribue à chacun une identité de service, stocke les tokens SaaS des utilisateurs dans un broker et tient à jour une liste des agents existants ainsi que des personnes qui les ont créés. Pour une seule équipe dont les agents restent au sein de sa propre plateforme, ce concept fonctionne bien.
Ensuite, la population d’agents et les besoins de l’entreprise continuent de croître. Chaque nouvelle application SaaS à laquelle vos agents accèdent utilise son propre serveur d’autorisation, avec son propre modèle de consentement, ses durées de vie de token et son propre comportement de révocation, ce qui implique que le broker nécessite une intégration supplémentaire. D’autres équipes commencent à lancer des agents selon leur propre calendrier, et certaines ne passent jamais par la couche que votre équipe plateforme a mise en place.
Les développeurs exécutent des agents de codage tels que Claude Code, Codex et Cursor sur leurs ordinateurs portables, et ces agents se connectent directement aux serveurs MCP et aux référentiels de code en insérant des tokens dans un fichier de configuration local, car ils ne passent jamais par la compilation centrale. Les agents présents sur les plateformes du fournisseur accèdent à vos données via les connecteurs propres à ce fournisseur. Les agents embarqués, les essaims d’agents et les modèles locaux font apparaître de nouvelles failles, et chaque nouvelle intégration alourdit une pile d’identité dont dépendent désormais des workflows encore plus critiques.
À ce stade, l’équipe qui a conçu une couche d’accès pour ses propres agents gère un produit d’identité pour le reste de l’entreprise.
Gérer soi-même la gouvernance de l’identité, c’est faire de la saison des audits une réalité permanente
De nombreuses organisations commencent par un registre simple des agents : une liste de chaque agent, de la personne responsable et des outils et applications auxquels il peut accéder. Cela cesse de fonctionner lorsque d’autres équipes lancent des agents, que les responsables changent de rôle ou quittent l’entreprise, et que les auditeurs demandent une preuve indiquant qu’une personne a examiné l’accès de chaque agent ce trimestre.
Ces éléments de preuve se trouvent rarement en un seul endroit. La passerelle enregistre une information, le broker en consigne une autre, et les applications SaaS auxquelles l’agent a accédé en consignent une troisième. Pour prouver ce qui s’est passé, il faut donc extraire les journaux de chaque système et les rapprocher manuellement.
Pour réellement faire passer les agents à l’échelle, la plupart des équipes constatent que le registre doit également remplir d’autres fonctions : réaffecter ou retirer les agents dont les propriétaires ne sont plus présents, lancer des certifications d’accès selon un calendrier défini, et indiquer qui a autorisé une action, pour qui, et selon quelle politique, plusieurs mois après les faits. Ce travail se répète à chaque cycle d’audit et s’intensifie à mesure que votre organisation ajoute de nouveaux agents.
OWASP classe l’utilisation abusive de l’identité et de privilèges des agents au 3e rang des principaux risques pour les applications agentiques, en évoquant la propriété floue, les identifiants hérités et les tokens mis en cache. Ce sont précisément les lacunes qui apparaissent lorsqu’un registre développé en interne atteint ses limites.
Les standards de sécurité MCP et OAuth évoluent en permanence
Les standards relatifs à l’autorisation des agents sont encore en cours d’élaboration. Au cours des 12 derniers mois, nous avons constaté des évolutions majeures dans les recommandations :
| Date | Mise à jour des spécifications et de la réglementation |
|---|---|
| Juin 2025 | La spécification d’autorisation du protocole Model Context a adopté OAuth 2.1 et interdit la transmission du token d’un client en aval vers les API. |
| septembre 2025 | Le Groupe de travail OAuth de l’IETF a adopté le Identity Assertion Authorization Grant, qui sert de base pour déléguer l’accès depuis un fournisseur d’identité d’entreprise vers des applications tierces. |
| juillet 2026 | La spécification MCP a commencé à exiger la validation de l’émetteur du serveur d’autorisation et a déplacé l’inscription des clients vers les documents de métadonnées de l’ID client. |
De plus, les recommandations de la NSA sur la sécurité MCP précisent que le protocole ne définit pas la procédure de renouvellement ni de révocation des tokens, si bien que chaque équipe qui développe sa propre couche doit concevoir et protéger elle-même ces comportements.
Chaque modification de spécification implique qu’une personne lise la nouvelle spécification, mette à jour le code et effectue de nouveaux tests.
Pourquoi les brokers de tokens développés en interne échouent dans l’autorisation SaaS en entreprise
Un broker développé en interne peut conserver et actualiser les tokens déjà émis par les applications SaaS, mais il ne peut pas accorder l’accès de sa propre initiative. Chaque application SaaS détermine quels fournisseurs d’identité elle considère comme fiables pour authentifier vos utilisateurs, et les éditeurs d’applications établissent cette relation de confiance avec une liste restreinte de fournisseurs d’identité reconnus. Si un broker utilisé en interne par une entreprise ne figure pas sur cette liste, chaque nouvelle application implique une nouvelle série d’écrans de consentement pour chaque utilisateur ou de validations manuelles par l’administrateur.
Cross App Access fonctionne différemment. Votre fournisseur d’identité accorde directement à l’agent un accès limité, de sorte que l’équipe informatique définit la politique une seule fois, les utilisateurs passent l’écran de consentement, et le contrôle des accès est centralisé. Un nombre croissant d’applications SaaS le prennent en charge, et le Model Context Protocol a adopté le même modèle pour l’autorisation gérée par l’entreprise.
Développer ou acheter : réorienter la rapidité des équipes techniques vers les besoins stratégiques de l’entreprise
La valeur d’un agent réside dans ce qu’il apporte à l’entreprise : le workflow qu’il automatise, les données qu’il rassemble et les décisions qu’il accélère. Chaque heure que vos ingénieurs consacrent à la maintenance de la logique de rafraîchissement des tokens, à la reconstruction des workflows de consentement pour la prochaine application SaaS ou à la production de rapports de revue des accès pour les auditeurs est une heure qu’ils ne consacrent pas directement aux agents eux-mêmes.
La plupart des ingénieurs et ingénieures de plateforme préfèrent développer des fonctionnalités pour les agents plutôt que de gérer un service d’identité.
Conservez ce que vous avez développé, adoptez une solution prête à l’emploi pour l’infrastructure sous-jacente
Les couches d’accès que les équipes ont créées pour leurs premiers agents ont permis de résoudre un problème urgent. La couche d’identités sous-jacente représente un engagement différent. Elle doit couvrir chaque agent au sein de l’entreprise, y compris ceux que votre équipe n’a jamais développés, accéder à des applications que votre entreprise ne contrôle pas, suivre le rythme de standards encore en évolution, et produire des preuves d’audit à chaque cycle tant que les agents sont en fonctionnement.
Investir dans une couche de sécurité permet à vos ingénieurs et ingénieures de se concentrer sur les agents qui font avancer l’entreprise, offre aux équipes sécurité et IT un point central pour visualiser et contrôler les agents, et confie la gestion continue des standards, des intégrations et de la gouvernance à une équipe dédiée exclusivement à l’identité.
Okta® for AI Agents est une couche d’identités pour les agents, conçue pour fonctionner en complément du fournisseur d’identité et des passerelles que vous utilisez déjà. Elle répond à quatre questions essentielles concernant l’ensemble de votre flotte d’agents :
- Où sont mes agents ? Découverte et enregistrement
- Que peuvent-ils faire ? Gestion des étendues et des droits
- Que font-ils ? Journalisation unifiée des audits
- Comment répondre ? Révocation automatisée et isolement des menaces
Guide d’achat : analyse technique et framework d’évaluation de la sécurité
Pour une analyse complète, y compris les questions à poser à tout fournisseur d’identité lors de votre évaluation de sécurité, lisez le livre blanc Identité des agents d’IA : développer ou acheter ?
Le contenu de ce document revêt un caractère purement informatif et ne constitue pas des conseils d’ordre juridique ou commercial, de confidentialité, de sécurité ou de conformité.
Il pourrait ne pas refléter les normes de sécurité, de confidentialité et les réglementations les plus récentes. Pour obtenir de tels conseils, il vous revient de vous adresser à votre conseiller juridique ou à tout autre conseiller professionnel et de ne pas vous en remettre à ce document pour vos décisions relatives à la conformité, au déploiement ou aux achats.
Okta ne formule aucune déclaration, garantie ou autre assurance concernant le contenu de ce document et décline toute responsabilité quant aux pertes ou dommages pouvant résulter de la mise en œuvre des recommandations fournies dans le présent document. Les informations sur les assurances contractuelles d’Okta à ses clients sont disponibles à la page okta.com/agreements.
