L’identité, l’angle mort des workflows multiagents
À l’instant où vous lisez ces lignes, quelque part dans votre entreprise, un agent d’IA pourrait être en train invoquer un autre agent de manière autonome. Un agent de vente extrait l’historique des paiements d’un client d’un agent financier. Un agent de surveillance déclenche un agent de diagnostic pour analyser un service en échec. Des tâches qui nécessitaient autrefois l’intervention de dizaines de personnes s’exécutent désormais en quelques secondes.
Voici le problème : chacun de ces transferts constitue un événement d’accès que vous devez gouverner.Pourtant, la plupart des équipes sécurité n’ont aucune visibilité sur ces événements. Pendant ce temps, les équipes IA qui créent ces workflows multiagents développent sur mesure l’autorisation entre chaque paire d’agents, en reliant des solutions ponctuelles sans disposer d’un espace centralisé pour visualiser ou contrôler ce qui se passe.
Les architectures multiagents, qu’elles soient initiées par des humains, par des machines ou, de plus en plus souvent, par les agents eux-mêmes, sont déjà en production. Mais la couche d’identités sous-jacente fait défaut. Sans une couche d’identités spécialement conçue pour les interactions entre agents, ces connexions deviennent des angles morts : non gouvernées, non attribuables et impossibles à auditer.
Nouveauté : sécuriser les connexions entre agents
Pour sécuriser et gouverner les workflows multiagents, Okta for AI Agents s’appuie sur le plan d’action pour l’entreprise agentique sécurisée d’Okta, un framework stratégique permettant de découvrir, d’autoriser et de gouverner les agents d’IA autonomes. Le deuxième pilier de ce plan d’action pose la question suivante : « À quoi [mes agents] peuvent-ils se connecter ? ». Il met ainsi l’accent sur la sécurisation des connexions entre les agents et les ressources, afin d’accorder aux agents un accès limité et audité aux données et systèmes de l’entreprise dont ils ont besoin.
Nous étendons désormais ce même modèle de connectivité sécurisée afin d’inclure les workflows multiagents. Les mêmes primitives qui protègent aujourd’hui les personnes et les applications, comme les identités d’agent, les identifiants à champ d’application limité et l’attribution des audits, s’étendent désormais aux connexions entre agents.
Au cœur de cette approche se trouve Agent-to-Agent Connections, une nouvelle fonctionnalité d’Okta for AI Agents qui vous permet de définir :
- Des politiques de connexion par agent
- Les services en amont et agents qu'un agent peut invoquer
- Le champ d’application de l’agent (ce à quoi il peut accéder)
- La durée de la session (période pendant laquelle cet accès reste actif)
L’identité est préservée à chaque transfert, de sorte que chaque connexion reste vérifiable tout au long du workflow.
Pour les équipes sécurité, cela signifie que chaque appel entre agents est gouverné, limité et entièrement traçable. Pour les développeurs, cela signifie créer des workflows multiagents sans avoir à coder l’autorisation pour chaque agent. Il vous suffit de définir une seule fois les politiques d’autorisation et d’accès dans Okta, et chaque agent de la chaîne de délégation appliquera automatiquement ces politiques définies.
Comment fonctionne Agent-to-Agent Connections ?
Chaque fois qu’un agent sollicite un autre agent, Okta vérifie que la connexion est autorisée, limite les données à ce qui est strictement nécessaire pour la tâche, et consigne qui agit pour le compte de qui, afin que le workflow multiagent soit gouverné de bout en bout.
Flux multiagent étape par étape
Pour comprendre le fonctionnement de ce flux, suivons une requête unique à travers le workflow multiagent. Imaginez une tâche courante de génération de rapports prise en charge par deux agents :
- L’agent assistant de l’utilisateur : agit au nom du collaborateur
- L’agent d’analyse de données : extrait des données de bases de données sensibles
Voici le flux :
- L’utilisateur demande à l’agent assistant de « préparer un rapport sur le quatrième trimestre ».
- L’agent assistant a besoin de données. Il fait donc appel à l’agent d’analyse de données « pour le compte de [utilisateur] ».
- Okta vérifie la politique : l’agent assistant est-il autorisé à appeler l’agent d’analyse des données ? L’agent d’analyse des données peut-il partager ces données avec l’utilisateur ?
- Si oui, Okta émet un token temporaire indiquant : « Agent d’analyse de données, cette demande provient de [utilisateur] via [agent assistant]. Le partage de X, Y, Z est autorisé. »
- L’agent d’analyse de données valide le token, partage uniquement les informations autorisées et consigne la demande.
- L’agent assistant utilise les données pour élaborer le rapport et le restitue à l’utilisateur.
- Chaque action est traçable. Le journal indique : Utilisateur → agent assistant → agent d’analyse de données.
Figure 1 : Exemple d’un workflow de Agent-to-Agent Connections
Trois principes rendent cela possible :
- Listes d’autorisation explicites : définir quels agents peuvent contacter d’autres agents.
- Autorisations à champ d’application limité : accorder à chaque agent en aval uniquement les droits nécessaires à sa mission.
- Chaînes de délégation vérifiables : accompagner chaque token pour permettre au journal d’audit d’indiquer qui a autorisé quoi.
Le résultat : les équipes sécurité bénéficient d’une visibilité complète sur chaque action de l’agent. Les développeurs cessent d’écrire du code d’autorisation entre agents et lancent plus rapidement des workflows multiagents.
Pourquoi la chaîne de délégation multiagent reste fiable ?
Deux éléments garantissent la fiabilité de la chaîne de délégation :
- Chaque agent peut agir à la fois en tant que client et que ressource.
- Chaque token contient un historique complet et vérifiable des autorisations accordées. L’autorisation intervient à l’exécution, et l’action est enregistrée dans le journal d’audit.
Agents agissant comme clients et ressources
Chaque agent dans Okta est à la fois un client et une ressource. C’est un élément important car, dans un véritable workflow multiagent, les agents ne se contentent pas d’être à une extrémité d’un appel ; ils sont au cœur du processus. Chaque agent peut initier des requêtes vers d’autres agents ou services, et peut recevoir des requêtes de leur part. C’est cette double fonction qui rend l’orchestration possible.
- En tant que client : l’agent peut appeler d’autres agents ou services
- En tant que ressource : d’autres agents peuvent appeler cet agent (si la politique le permet)
Un seul agent peut être à la fois spécialisé et orchestrateur, sans rompre la chaîne de confiance.
Préserver le contexte grâce à l’enregistrement de la délégation basé sur des tokens
Quand Okta émet un token pour un appel agent à agent, un enregistrement de l’ensemble du parcours est inclus :
- « Ceci concerne l’utilisateur A. »
- « L’utilisateur A a délégué à l’agent assistant. »
- « L’agent assistant a délégué à l’agent d’analyse de données. »
- « L’agent d’analyse de données est autorisé à effectuer X, Y, Z. »
Okta inclut l’intégralité de la chaîne de délégation dans le token afin que l’agent destinataire puisse vérifier l’autorisation avant d’agir. Le journal d’audit d’Okta enregistre la chaîne de délégation pour chaque appel, en la conservant bien après l’expiration du token lui-même.
En cas de problème, comme un incident de sécurité, une question d’audit ou un contrôle de conformité, vous pouvez consulter l’enregistrement d’audit et voir précisément ce qui s’est passé, qui l’a autorisé et si cela était conforme à la politique. Sans recherche manuelle dans les journaux. Sans travail de mise en corrélation.
Comparatif des modèles de flux pilotés par l’humain et par la machine
Qu’un workflow soit initié par une personne ou une machine, une seule identité constitue le point d’ancrage de l’ensemble du processus. Chaque agent en aval agit sous cette autorité, et chaque étape lui est attribuable. Agent-to-Agent Connections gère actuellement les deux modèles.
Modèle 1 : Une personne démarre la chaîne
Un utilisateur se connecte et demande à un agent d’effectuer une action. Cet agent peut faire appel à d’autres agents pour mener à bien la tâche, mais l’identité de la personne reste le point d’ancrage.
Exemple : Un collaborateur demande : « Fais un résumé des métriques du quatrième trimestre ».
- L’agent de résumé appelle l’agent du tableau de bord (pour le compte du collaborateur).
- L’agent du tableau de bord appelle l’agent de base de données (pour le compte du collaborateur).
L’identité du collaborateur circule tout au long de la chaîne, et chaque étape est enregistrée sous son nom.
Figure 2 : Exemple d’un workflow multiagent piloté par un humain
Ce qu’Okta enregistre dans le journal d’audit : « Le Collaborateur a autorisé l’Agent de résumé à appeler l’Agent du Tableau de bord. L’Agent du Tableau de bord a récupéré des métriques auprès de l’Agent de Base de données dans le périmètre d’accès du Collaborateur. »
Modèle 2 : Un service démarre la chaîne
Les entreprises ont des dizaines d’applications de service, de pipelines ETL, de tâches planifiées et de microservices exécutant des charges de travail déterministes. Ces systèmes intègrent désormais l’IA.
Exemple : Un service de surveillance détecte un pic d’utilisation du processeur.
- Le service de surveillance appelle l’agent de diagnostic.
- L’agent de diagnostic appelle l’agent d’analyse des journaux.
Aucun utilisateur n’a initié la demande. Le service de surveillance est le client, l’agent de diagnostic est sa ressource et l’autorité du service s’exerce tout au long de la chaîne.
Figure 3 : Exemple d’un workflow multiagent piloté par une machine
Ce qu’Okta enregistre dans le journal d’audit : « Le service de surveillance a autorisé l’agent de diagnostic à appeler l’agent d’analyse des journaux. L’agent d’analyse des journaux peut analyser les journaux de production pour le service de surveillance. »
Principales différences entre les deux modèles
|
Modèle 1 : piloté par l’humain |
Modèle 2 : piloté par la machine |
|
|---|---|---|
Qui commence |
Un utilisateur authentifié |
Un service ou une charge de travail planifiée |
Ancrage de la chaîne |
L’identité de l’utilisateur |
L’identité du service |
L’audit révèle |
Tout est lié à cet utilisateur |
Tout est lié à ce service |
Champ d’application |
Limité aux éléments auquel l’utilisateur peut accéder |
Limité à ce pour quoi le service est autorisé |
Qui commence
Un utilisateur authentifié
Ancrage de la chaîne
L’identité de l’utilisateur
L’audit révèle
Tout est lié à cet utilisateur
Champ d’application
Limité aux éléments auquel l’utilisateur peut accéder
Qui commence
Un service ou une charge de travail planifiée
Ancrage de la chaîne
L’identité du service
L’audit révèle
Tout est lié à ce service
Champ d’application
Limité à ce pour quoi le service est autorisé
Le résultat : un seul modèle de gouvernance, quel que soit le point de départ de la chaîne de délégation. Les équipes sécurité bénéficient d’une traçabilité complète sur l’ensemble des workflows initiés par des personnes et des machines, chaque transfert étant enregistré. Les équipes IA bénéficient d’une autorisation qui fonctionne de la même manière, qu’un utilisateur ou un service soit à l’origine de la demande, ce qui évite d’avoir à développer et maintenir une logique distincte pour chaque modèle.
Modèle 3 : Un agent autonome démarre la chaîne (bientôt disponible)
Un troisième modèle sera bientôt disponible : On-behalf-of-self, dans lequel un agent autonome peut agir entièrement de sa propre initiative, sans aucune délégation, selon une politique préapprouvée par un administrateur. En utilisant ce modèle, vous pourrez exécuter des agents autonomes au sein d’une politique prédéfinie, entièrement audités et gouvernés.
Centraliser la gouvernance des workflows multiagents
Les agents appellent déjà d’autres agents dans votre environnement, mais aucune règle ne gouverne ces échanges. La question n’a jamais été de savoir si les agents allaient contacter d’autres agents, mais plutôt : serez-vous en mesure de les suivre quand ils le font.
C’est ce que Okta for AI Agents rend possible. En étendant les mêmes principes d’identité qui protègent vos collaborateurs, applications et agents aux connexions entre agents, vous faites passer le workflow multiagent d’un angle mort au cadre de gouvernance. Agent-to-Agent Connections vous fournit des listes d’autorisation, des autorisations à champ d’application limité et une chaîne vérifiable qui rendent les workflows autonomes fiables à grande échelle.
À mesure que les architectures multiagents gagnent en complexité, les entreprises qui réussiront ne se contenteront pas d’aller vite ; elles seront en mesure de démontrer, à tout moment, qui a fait quoi, pour le compte de qui, et dans le cadre de quelle politique.
Prêt à gérer vos workflows multiagents ?
Agent-to-Agent Connections est disponible dès maintenant en Early Access pour les clients Okta. Contactez votre équipe de compte Okta pour vous inscrire.
Découvrez comment ces contrôles d’agent d’IA fonctionnent en pratique. Regardez notre streamcast Okta pour découvrir comment fonctionne la gouvernance des agents lorsque l’identité devient le point de contrôle.
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.
