Qu’est-ce qu’Agent Gateway ?
Agent Gateway est une couche d’application de l’identité à l’exécution au sein d’Okta for AI Agents. Elle valide chaque requête d’agent vers un outil par rapport aux politiques d’identité à l’aide de l’échange de tokens RFC 8693. Contrairement aux passerelles traditionnelles qui reposent sur des clés de service partagées, Agent Gateway exige des identifiants associés à la fois à l’agent d’IA agissant et à l’utilisateur ou l’utilisatrice humaine, ce qui empêche les attaques de type « confused deputy » et l’héritage non autorisé d’autorisations.
Si un agent d’IA dans votre environnement devenait incontrôlable à l’instant, seriez-vous en mesure d’identifier pour qui il agissait, ce à quoi il a accédé et à quel moment ? De nombreuses équipes sécurité n’y parviennent pas.
Les agents d’IA sont déployés plus rapidement que les dispositifs de contrôle prévus pour les encadrer. Les passerelles peuvent connecter des agents à des outils. Cependant, peu de personnes peuvent vous dire pour qui un agent agit. C’est une faille dont les attaquants peuvent tirer parti, et elle ne sera visible que lorsque le problème sera déjà survenu.
Les passerelles sont présentées comme un moyen de contrôle, mais la plupart ne peuvent pas vérifier qui se trouve réellement derrière une demande. Sans cela, elles ne contrôlent rien : elles se contentent de router les appels et d’enregistrer ce qui s’est passé, en utilisant l’autorité qui leur a été confiée. Sans l’identité comme fondement, une passerelle n’est qu’un point de contrôle sans règles à appliquer, sans agent à attribuer et sans gouvernance à mettre en œuvre.
Agent Gateway d’Okta comble cette lacune. Il s’agit de la couche d’application à l’exécution au sein de Okta for AI Agents. Partout où un agent d’IA peut être configuré pour appeler un protocole Model Context Protocol (MCP) externe, Agent Gateway valide chaque appel agent-vers-outil selon la politique, isole les identifiants au moment de l’action et génère une piste d’audit unifiée.
Okta for AI Agents ajoute la couche d’identité et de gouvernance autour d’Agent Gateway : découverte des agents, inscription en tant qu’identités à part entière, workflows d’accès, campagnes de certification et corrélation des audits sur différents systèmes. Agent Gateway est disponible en version GA dès aujourd’hui dans le cadre d’Okta for AI Agents. Cette fonction répond à la troisième question du plan d’action pour l’entreprise agentique sécurisée: « Que font mes agents ? »
Dans ce blog, vous découvrirez l’un des principaux problèmes de la plupart des passerelles d’agents : elles peuvent connecter un agent à un outil, mais elles ne peuvent pas vérifier pour le compte de qui l’agent agit. Vous découvrirez en quoi l’Agent Gateway d’Okta se distingue : il ne traite un appel que si l’identifiant mentionne à la fois l’utilisateur et l’agent associé, ce qui contribue à éviter que l’autorité ne soit empruntée, partagée ou transmise par inadvertance.
Pourquoi les passerelles MCP traditionnelles ne parviennent-elles pas à sécuriser les agents d’IA ?
Les passerelles MCP traditionnelles peuvent router les requêtes des agents vers des outils, mais elles présentent souvent une lacune essentielle : elles ne peuvent pas vérifier pour le compte de qui un agent agit.
Explication de la vulnérabilité du « confused deputy »
Commençons par un exemple de scénario dans lequel vos agents ne disposent pas de passerelle :
- Provisioning étendu des identifiants : votre équipe crée un assistant RH pour répondre aux questions concernant les dossiers des personnes employées. Pour que cela fonctionne pour toute personne qui en fait la demande, une personne lui attribue un compte de service avec un accès en lecture à l’ensemble de ces ressources.
- Demande d’utilisateur ou d’utilisatrice non autorisé·e : Katie est prestataire. Elle demande à l’agent quelle est la rémunération de la directrice générale ou du directeur général.
- Contournement de la politique : l’agent le lui transmet en utilisant l’accès qu’il détient légitimement.
- Échec de l’audit : la demande semble parfaitement conforme dans le journal d’audit.
Rien n’a été piraté. La seule chose qui séparait Katie de ces données était le discernement propre à l’agent.
C’est le problème du mandataire confus: la requête transmet la demande de l’utilisateur, mais pas son autorité. L’agent agit en fonction de ce à quoi il a accès, et non en fonction de ce que la personne qui fait la demande est réellement autorisée à connaître. Il s’agit d’une faille qui existe depuis des décennies dans la façon dont les autorisations fonctionnent, et c’est précisément ce qui se produit lorsque vous accordez à un agent un accès étendu et que vous comptez sur lui pour s’autogérer.
Limites des architectures MCP traditionnelles
Révocation tout ou rien
La révocation d’un identifiant de passerelle partagé interrompt l’accès pour tous les agents connectés, ce qui conduit les administrateurs à laisser des identifiants trop permissifs actifs en permanence :
- L’administrateur configure une passerelle connectée à un serveur MCP GitHub en utilisant une seule information d’identification partagée
- Chaque agent qui se connecte via cette passerelle hérite du même accès étendu
- Révoquer l’identifiant coupe l’accès pour tous les agents opérant derrière lui
- Le résultat : personne ne le révoque
Tokens au porteur à identité unique
MCP a été conçu en tenant compte du problème de l’adjoint confus. Mais il existe une contrainte fondamentale : MCP fonctionne avec des tokens au porteur OAuth 2.1, qui ne désignent qu’une seule identité. Une passerelle ne peut pas transmettre le token de l’agent, elle doit en générer un nouveau. Ainsi, même si une passerelle souhaite indiquer à GitHub « il s’agit de l’agent de développement de Katie, agissant pour le compte de Katie », elle ne le peut pas. L’identité sélectionnée est alors la seule que GitHub perçoit.
Les mesures de sécurité du prompt engineering présentent des failles
Vous pourriez essayer de corriger cela dans l’invite en demandant à l’agent de ne jamais accéder aux données de rémunération. Cela ne sera probablement pas le cas. Mais l’identifiant permet toujours d’accéder à tout, si bien que la mesure de protection la plus efficace consiste pour l’agent à choisir de ne pas consulter les informations — ce qui était précisément le problème initial.
Agent Gateway d’Okta : une application des règles à l’exécution native de l’identité pour les agents d’IA se connectant aux outils d’entreprise
Agent Gateway, une nouvelle fonctionnalité d’Okta for AI Agents, constitue le point de contrôle d’exécution qui définit à quoi un agent peut se connecter et ce qu’il peut effectuer lors de chaque action. Un appel ne sera traité que si l’appelant présente un justificatif désignant les deux parties : l’utilisateur qui demande l’action et l’agent qui effectue la requête. Cette obligation d’appliquer l’identité distingue Agent Gateway d’une passerelle qui se contente de relayer le trafic.
Configuration d’un Agent Gateway.
Une passerelle classique peut authentifier que quelque chose est autorisé à se connecter. Agent Gateway vérifie pour quel utilisateur la demande est destinée, quel agent d’IA agit et si cet agent a été autorisé à agir au nom de cet utilisateur, puis applique la politique au moment où l’appel d’outil est effectué.
Chaque appel d’outil est attribué à une identité d’agent gérée, à un utilisateur final, à un outil et à un résultat.
Supposons que Katie soit une collaboratrice, et qu’un agent s’apprête à passer un appel en son nom. Certaines passerelles authentifient l’appelant à l’aide d’une clé de plateforme et prennent l’utilisateur comme paramètre :
POST /mcp HTTP/1.1
Authorization : Bearer <platform api key>
{ "user_id": "Katie", "tool": "read_file", ... }
Une passerelle conçue de cette manière peut vérifier la clé, mais elle ne peut pas vérifier l’identité de Katie. Son nom n’est qu’un texte dans la requête, saisi par la personne qui a effectué l’appel, si bien que toute personne détenant cette clé peut se faire passer pour n’importe qui.
Agent Gateway n’accepte absolument pas ce type d’identifiant. Au lieu de cela, Agent Gateway met en œuvre la délégation RFC 8693, exigeant que chaque appel d’outil présente un identifiant émis par votre fournisseur d’identité contenant deux revendications d’identité distinctes :
- Le sujet (
sub) : l’utilisateur final authentifié qui demande l’action - L’acteur (
act) : l’agent d’IA enregistré qui exécute la demande
Voici ce qu'Agent Gateway attend à chaque appel :
{
"sub": "00uKatie456",
"aud": "https://acme.gateway.okta.com/mcp/servers/eng-tools",
"act": {
"sub": "0oafxqCAJWWGELFTYASJ",
"sub_profile": "ai_agent web_app"
}
}
L’appel concerne sub, et act indique qui l’effectue. sub_profile indique que l’appelant est une application et un agent.
Rien n’est hérité, donc Agent Gateway ne peut pas créer un utilisateur. Le sub dans cet identifiant est le seul utilisateur au nom duquel Agent Gateway peut agir lors de cet appel. Lorsque Agent Gateway a besoin d’un identifiant pour le serveur MCP, l’identifiant de l’agent est échangé avec Okta et en reçoit un lié au même utilisateur, ce qui correspond à la sémantique de délégation définie dans la RFC 8693. Okta ne peut renvoyer cet identifiant que parce que l’utilisateur y a préalablement consenti sur le serveur MCP via une connexion enregistrée par un administrateur.
Ainsi, un agent ne peut pas convaincre Agent Gateway d’agir pour une autre personne. Katie peut toujours demander. Cependant, Agent Gateway agit désormais en son nom avec un identifiant qui lui est attribué, ce qui limite l’agent aux seules actions que Katie pourrait effectuer elle-même.
Matrice des capacités d’application de l’identité
En règle générale, une passerelle ne peut agir que sur les éléments déjà présents dans l’identifiant qu’elle reçoit. Que cet identifiant contienne l’identité réelle de l’utilisateur et de l’agent, ou aucune identité, cela se décide au moment de sa création.
| Type d’identifiant reçu par une passerelle | Contexte utilisateur capturé | Contexte de l’agent capturé | Contexte de l’agent capturé |
|---|---|---|---|
| Clé de service partagée | Aucun | Aucun | Faible : aucune gouvernance ni attribution possible |
| Token réservé aux utilisateurs | Utilisateur uniquement | Aucun ; chaque agent semble identique | Moyen : impossible de distinguer l’activité des agents de celle des utilisateurs |
| Token délégué (RFC 8693) | Utilisateur vérifié | Agent vérifié | Élevé : application complète des politiques à l’exécution et attribution |
L’Agent Gateway d’Okta fonctionne uniquement à la troisième ligne. Il ne traitera un appel que si l’identifiant est un token délégué et vérifié, mentionnant à la fois l’utilisateur et l’agent.
Règles d’accès efficaces pour les agents
En pratique, ce qu’un agent peut réellement accomplir est limité par l’intersection exacte des autorisations d’Agent Gateway et des droits de l’utilisateur :
Ce que l’agent peut faire = Ce que la passerelle autorise ∩ Ce que l’utilisateur ou l’utilisatrice peut déjà faire
Ce que permet la passerelle ← appliqué par la passerelle
Ce que l’utilisateur peut déjà faire ← imposé par le serveur MCP
Agent Gateway sait quel agent effectue l’appel et quels outils sont exposés. Le serveur MCP connaît ses propres enregistrements ainsi que les utilisateurs autorisés à y accéder. Les deux couches de sécurité sont nécessaires.
Agent Gateway est une charge de travail enregistrée, disposant de son propre principal et ne bénéficiant d’aucune autorisation permanente pour accéder à quoi que ce soit. Un administrateur configure deux éléments avant que tout appel ne soit traité :
- Lien de délégation : accorde à un agent spécifique l’autorisation de déléguer à cette passerelle au nom de l’utilisateur ou de l’utilisatrice. En l’absence de celui-ci, l’échange est refusé.
- Connexion de ressource : accorde à cette passerelle l’autorisation d’accéder à un serveur MCP spécifique et définit précisément quels outils de ce serveur sont exposés.
Aucune autorisation n’est déduite de l’appelant ni accordée par l’identifiant de l’agent. L’accès est limité aux autorisations de délégation et de ressources qu’un administrateur configure.
La gouvernance de l’identité constitue également le socle de la maîtrise des coûts
Les agents d’IA ne créent pas seulement des risques d’accès, ils peuvent aussi générer des dépenses à la vitesse des machines. Un agent qui sollicite de manière répétée une API premium, déclenche des workflows coûteux ou utilise des outils à forte consommation peut générer des coûts imprévus bien avant qu’une personne ne s’en rende compte.
La gouvernance des coûts commence par l’attribution. Si plusieurs agents partagent un identifiant, il devient difficile de répondre à des questions élémentaires, telles que : quel agent a généré l’activité ? Pour qui agissait‑il ou elle ? Quel outil ou quelle ressource a généré le coût ?
Agent Gateway d’Okta crée le contexte d’identité nécessaire pour répondre à ces questions. Chaque requête étant liée à la fois à l’utilisateur et à l’agent agissant en son nom, les entreprises peuvent corréler l’activité de l’agent avec les outils et les ressources auxquels il accède. Cela crée une base plus claire pour surveiller l’utilisation, enquêter sur les activités inattendues et appliquer la gouvernance à mesure que les déploiements d’agents prennent de l’ampleur.
Bientôt disponible : prise en charge de Cross App Access et arrêt d’urgence via Agent Gateway
Prise en charge de Cross-App Access par Agent Gateway
Les agents doivent pouvoir accéder aux applications SaaS courantes, telles que Slack ou Salesforce, et Okta propose un protocole ouvert standardisé à cet effet : Cross App Access. Lorsque la prise en charge sera lancée, Cross App Access permettra aux agents d’IA d’accéder de manière sécurisée aux applications pour le compte d’un utilisateur, tout en préservant l’intégrité des deux identités. L’administrateur approuve une fois pour toutes les applications que les agents peuvent utiliser, sans que chaque collaborateur doive approuver individuellement chaque application.
Le faire via une passerelle présente un véritable avantage : cela offre un point de contrôle centralisé pour activer ou désactiver l’accès d’un agent, au lieu de le gérer application par application.
Agent Gateway prendra en charge Cross App Access prochainement. Cela permettra à la passerelle d’indiquer « cette demande provient d’une autorisation que vous avez déjà approuvée », puis d’échanger cette assertion contre un nouveau token, sans qu’aucune modification ne soit nécessaire du côté de l’application. Ce mécanisme est proposé dans le projet de spécification IETF Identity Continuation Assertion.
Arrêt d’urgence basé sur Agent Gateway
Enfin, comme chaque appel d’outil passe par un point unique d’application à l’exécution, Agent Gateway peut bloquer les requêtes en temps réel. Lorsqu’elle sera disponible, la fonctionnalité d’arrêt d’urgence rendra la désactivation d’un agent immédiate, y compris pour les tokens déjà émis, en rejetant toute requête transmettant un token délivré à un agent désactivé. Comme cette mesure sera appliquée à la frontière d’Okta, il ne sera plus nécessaire d’attendre que chaque application connectée révoque l’accès de manière indépendante.
Comment évaluer une passerelle d’agent d’IA : quatre questions essentielles à se poser
Quatre questions vous permettront de situer précisément chaque passerelle :
- Vérification de l’émetteur : Quel justificatif le serveur MCP reçoit-il, et qui l’a émis ?
- Preuve d’identité de l’utilisateur : la passerelle peut-elle indiquer à quel utilisateur un appel est destiné, ou l’utilisateur est-il un paramètre fourni par l’appelant ?
- Traçabilité du consentement : Le consentement de qui a autorisé l’accès de l’agent à ce serveur MCP ?
- Risque de contournement : L’agent détient-il à un moment donné un identifiant qui fonctionne sans que la passerelle soit sur le chemin ?
Agent Gateway a été conçu pour répondre aux quatre besoins.
Agent Gateway n’est qu’un élément d’un ensemble plus vaste : Okta for AI Agents constitue la plateforme globale qui offre la visibilité, le contrôle et la gouvernance nécessaires pour sécuriser les agents déployés par votre entreprise.
Agent Gateway est disponible avec Okta for AI Agents sans coût supplémentaire.
Clients actuels : Contactez votre responsable de compte pour commencer à l’utiliser dès aujourd’hui.
Vous n’êtes pas encore client d’Okta for AI Agents ? Téléchargez notre fiche produit pour découvrir comment Okta for AI Agents peut vous aider à gérer en toute sécurité vos agents d’IA depuis un plan de contrôle unique.
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.
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 à ces supports pour prendre des 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 à l’adresse okta.com/agreements.
