Note de la rédaction : découvrez comment passer au concret dans le dernier épisode de notre streamcast, « Le plan d’action pour l’entreprise agentique sécurisée », où la théorie est mise en pratique. Vous découvrirez comment le plan d’action pour l’entreprise agentique sécurisée se traduit concrètement par des contrôles adaptés à des outils tels que Claude Code et Cursor.
Vos équipes IA ne peuvent pas se permettre de laisser les déficits de gouvernance ralentir le déploiement. Elles doivent mettre les agents d’IA au service de leur activité dès maintenant.
Selon une enquête menée en 2026 auprès des cadres dirigeants du secteur technologique, 90 % des entreprises n’ont aucun moyen de gouverner les actions réelles des agents en production. Environ 54 % d'entre elles ont déjà subi un incident de sécurité lié à un agent ayant agi de manière inattendue.
Ces agents appellent des API, consultent des données sensibles, délèguent des tâches à d’autres agents et prennent des décisions sans attendre d’intervention humaine. La question n’est pas de savoir si votre entreprise compte des agents qui agissent de cette manière, mais plutôt de savoir si vous exercez un contrôle réel sur leurs activités quand le cas se produit. Pour la plupart des entreprises aujourd’hui, la réponse honnête est non.
Pourquoi ? C’est presque toujours un problème de gouvernance de l’identité. Chaque agent d’IA en production fonctionne soit via une couche d’identités gouvernées, soit en la contournant. La plupart des agents d’IA contournent la couche d’identités.
Faire aller la gouvernance d’identité plus loin
Pour devenir une entreprise agentique sécurisée, vous avez besoin d’un plan directeur qui vous aide à répondre à trois questions essentielles :
- Où sont mes agents ?
- À quoi peuvent-ils se connecter ?
- Que peuvent-ils faire ?
Les fonctionnalités présentées dans cet article de blog sont de nouvelles améliorations qui font progresser encore davantage le plan d’action pour l’entreprise agentique sécurisée précisément sur les deux dernières questions. Elles permettent aux équipes IA de lancer leurs initiatives plus rapidement, et aux équipes sécurité d’obtenir l’application des politiques en temps réel, les contrôles de réponse et la traçabilité nécessaires pour donner leur accord.
À quoi peuvent-ils se connecter ?
Quelque part dans votre entreprise à l’instant même, un agent d’IA délègue peut-être discrètement une tâche à un autre agent.
Voici le problème : chacun de ces transferts constitue un événement d’accès que l’entreprise doit gouverner. Et sans couche d’identités, la plupart des équipes sécurité n’ont aucune visibilité sur ces évènements.
La plupart des entreprises créent des workflows multi-agents de deux manières :
- Workflows initiés par l’utilisateur : un collaborateur demande à un agent de type assistant de préparer une présentation pour le diagnostic trimestriel des activités. L’agent orchestre un essaim d’agents, chacun agissant pour le compte de l’utilisateur et limité à ce que l’utilisateur est autorisé à consulter. L’humain constitue le point d’ancrage, tandis que l’identité circule à chaque transfert.
- Workflows initiés par des machines : un service de surveillance détecte une anomalie et déclenche un agent de diagnostic, qui délègue à un agent d’analyse des journaux pour approfondir l’investigation. Aucune session utilisateur, aucune intervention humaine. L’autorité du service se transmet à chaque agent de la chaîne.
Ces deux modèles répondent au même besoin de gouvernance : chaque transfert constitue un événement d’accès qui doit être autorisé, encadré et consigné. Lorsque des agents d’IA communiquent sans couche d’identités dédiée, les entreprises risquent de perdre la capacité de vérifier l’identité de l’acteur à l’origine de chaque requête, d’appliquer la politique de manière cohérente ou de retracer les actions jusqu’à leur source.
Agent-to-Agent Connections : sécuriser vos workflows multi-agents
Agent-to-Agent Connections, une nouvelle fonctionnalité d’Okta for AI Agents, comble cette lacune en vous permettant de définir des politiques de connexion par agent, d’indiquer quels services en amont et agents peuvent solliciter cet agent, leur champ d’application ainsi que la durée de validité de l’autorisation. L’identité est préservée à chaque étape, de sorte que chaque connexion reste vérifiable tout au long du workflow.
Trois principes rendent cela possible :
- Les listes d’autorisation explicites définissent quels agents peuvent appeler quels autres agents.
- Les autorisations à champ d’application limité donnent à chaque agent en aval uniquement ce dont il a besoin pour accomplir sa tâche.
- Une chaîne vérifiable accompagne chaque token, de sorte que le journal d’audit consigne qui a autorisé quoi.
Voici ce que signifie gouverner les accès des agents au niveau agent à agent : déterminer quels agents peuvent contacter d’autres agents, dans quelles conditions, avec quel champ d’application, et en fournissant des preuves exploitables par tout auditeur ou toute équipe de résolution des incidents qui en ferait la demande.
Disponibilité : Agent-to-Agent Connections est disponible dès maintenant en Early Access. En savoir plus sur la sécurisation de vos workflows multi-agents avec Agent-to-Agent Connections.
Sécuriser les assistants de codage basés sur l’IA tels que Claude Code, Microsoft 365 Copilot et Cursor
Les connexions d’agent à agent ne représentent qu’un aspect du problème de la connectivité. Une autre faille majeure concerne les outils d’IA non gouvernés que vos développeurs utilisent déjà pour se connecter à vos systèmes. Cela inclut des assistants de codage basés sur l’IA tels que Claude Code, Cursor, Microsoft 365 Copilot, GitHub Copilot et Glean.
Ces outils sont intégrés aux workflows quotidiens et connectés aux systèmes internes tels que Jira, ServiceNow, GitHub et vos API internes.
Le vrai problème : leur manière de s’introduire. La plupart de ces outils n’ont pas été conçus pour s’authentifier via un fournisseur d’identité. Ils obtiennent un accès par des jetons codés de manière irréversible, des identifiants ad hoc et des clés API stockées dans des fichiers de configuration. Il n’y a pas d’autorisation centralisée. Ni de piste d’audit. Souvent, les équipes sécurité ne peuvent pas voir quels agents ont accédé à quels systèmes, pour le compte de qui, ni les actions réalisées.
Le MCP Bridge répond à cette problématique sans obliger à modifier les agents eux-mêmes. Un proxy auto-hébergé et sensible à l’identité s’intercale entre vos agents et les outils Model Context Protocol (MCP) auxquels ils se connectent. Chaque appel passe par le bridge. Chaque agent s’authentifie via votre fournisseur d’identité. Chaque action est consignée dans votre journal d’audit. L’agent n’a pas besoin d’être réécrit. Le développeur n’a pas non plus besoin de modifier son workflow.
Le bridge fonctionne dans l’environnement du client, de sorte que les données restent à l’intérieur du périmètre. Aucun service externe ne voit ce qui transite. Le client maîtrise le déploiement, la configuration et les données.
Disponibilité : le MCP Bridge est une offre Professional Services et nécessite un cahier des charges.
Que peuvent-ils faire ?
Gouverner ce que peuvent faire les agents exige que la couche d’identités aille au-delà de l’accès initial. Un token d’accès permet à un agent de franchir la porte ; il ne gouverne pas les actions de l’agent une fois à l’intérieur.
Autorisation des agents IA : appliquer une autorisation dynamique à chaque action d’agent IA
Les autorisations d’un utilisateur peuvent évoluer après l’émission d’un token. Un prestataire peut quitter un projet. Un patient peut retirer son consentement. Un responsable peut partir en vacances. Les rôles statiques et les tokens d’accès ne peuvent pas suivre ces changements. Au lieu de demander « Cet utilisateur ou cet agent a-t-il accès au système ? », l’autorisation d’un agent d’IA pose une question plus précise : « Cet agent, agissant pour cet utilisateur, peut-il effectuer cette action sur cette ressource à ce moment ? ».
Cette distinction est importante, car les conditions d’autorisation évoluent en permanence. L’autorisation granulaire (FGA) prend en compte le contexte au lieu de se limiter au rôle. Elle vérifie si l’utilisateur pour lequel un agent agit possède la relation requise, les attributs actuels et remplit les conditions de la politique afin d’effectuer une action spécifique sur une ressource donnée, au moment de l’exécution.
Cela inclut les relations directes et héritées, les attributs dynamiques, comme le niveau d’habilitation ou le statut en service, ainsi que les seuils de politique, comme les limites quantitatives, les montants en devise ou les règles de classification des données.
Par exemple, un agent d’acquisition peut approuver des factures jusqu’à 10 000 $ pour le compte de l’utilisateur qu’il représente, mais pas au-delà de ce seuil. La FGA vérifie le plafond d’approbation de l’utilisateur en temps réel, et pas uniquement son rôle.
Gouverner ce que peuvent faire les agents nécessite plus que des autorisations statiques définies lors du déploiement. Cela implique une évaluation continue de chaque action, pour chaque agent, en temps réel. C’est ainsi que vous contrôlez ce qu’un agent fait réellement.
Disponibilité : il s’agit d’une implémentation de cas d’usage de la FGA et d’Okta for AI Agents.
Arrêt d’urgence : désactiver un agent malveillant à tout moment
Intégrer la gouvernance dès le départ réduit la probabilité des incidents, mais ne signifie pas qu’il n’y en aura pas. De par leur conception, les agents sont imprévisibles. Ils prennent des décisions, naviguent entre différents systèmes et peuvent effectuer des actions non prévues. Lorsque cela se produit, les équipes sécurité doivent réagir immédiatement.
De nombreux déploiements d’agents d’IA aujourd’hui ne permettent pas de neutraliser un agent lorsqu’il adopte un comportement inattendu. Lorsque le conseil d’administration demande quel est le plan de réponse si un agent devient malveillant, la plupart des CISO ne peuvent pas répondre.
Avec un arrêt d’urgence, tout change. Pour les agents qui se connectent par Okta, la résiliation de l’accès interrompt l’accès à l’ensemble des ressources connectées en une seule action depuis l’admin console Okta. Vous n’avez pas besoin de confirmer qu’un agent est compromis pour l’utiliser. Une mauvaise configuration, une action hors champ d’application ou un comportement qui suscite une interrogation. Chacune de ces raisons suffit à désactiver immédiatement l’agent, le temps d’enquêter sur l’incident.
Le résultat ? Les équipes IA lancent leurs solutions en sachant qu’il y a un filet de sécurité. Les équipes sécurité valident les déploiements en sachant qu’elles pourront intervenir en cas d’incident. Lorsque vous savez que vous pouvez arrêter l’agent, vous pouvez l’approuver.
Disponibilité : la fonctionnalité arrêt d’urgence est disponible en GA et incluse dans Okta for AI Agents. Bientôt disponible : une détection qui analyse les signaux de risque dans l’ensemble de l’écosystème Okta, augmente le score de risque de l’agent et active automatiquement l’arrêt d’urgence.
Chaque agent a besoin d’une couche d’identités
Ces fonctionnalités répondent à différents aspects de la gouvernance des agents, mais elles reposent sur un principe commun. Les primitives d’identité qui protègent vos collaborateurs et vos applications doivent également s’étendre aux agents. Cela inclut la gouvernance des connexions entre les agents, des actions qu’ils effectuent, des outils qu’ils utilisent, ainsi que votre capacité à les interrompre en cas de problème.
Gouverner les agents de cette manière nécessite une couche d’identités faisant autorité en temps réel, déjà déployée sur l’ensemble de votre personnel et de vos applications. Okta se situe à cette couche.
Les entreprises qui maîtrisent cet aspect dès le départ ne se contenteront pas de réduire les incidents. Elles iront plus vite. La découverte, la sécurité et la gouvernance intégrées dès le départ ne freinent pas le déploiement de l’IA. Elles rendent possible la montée en charge. Créez votre socle dès maintenant, et votre équipe sécurité ne sera plus le goulet d’étranglement du déploiement des agents, mais deviendra la clé de leur réussite.
Pour en savoir plus sur ces nouveautés, et voir des démonstrations, regardez le webinar streamcast.
Le contenu de ce document revêt un caractère purement informatif et ne constitue pas des conseils juridiques, commerciaux ou en matière de confidentialité, sécurité ou conformité. Pour obtenir de tels conseils, il vous revient de vous adresser à vos propres conseillers professionnels en matière de sécurité, confidentialité ou conformité. Toute mention de produits, fonctions, fonctionnalités ou certifications futurs dans cet article de blog revêt un caractère purement informatif. Ces éléments ne constituent pas des engagements et ne doivent pas être considérés comme un facteur déterminant dans les décisions d’achat. © Okta, Inc. et ses affiliés. 2026.
