Dust + Okta Agent Gateway : sécuriser les outils MCP

De la Blueprint Alliance à une intégration concrète

#

Dans mon précédent article sur la Blueprint Alliance, j’ai souligné l’importance de placer les contrôles d’identité et les policies sur le chemin des appels d’outils effectués par les agents IA. Okta Agent Gateway permet de mettre ce principe en pratique. Voyons maintenant un exemple concret de configuration.

Dust suscite beaucoup d’intérêt ici en France : cette plateforme m’a donc semblé un bon point de départ. Nous allons connecter Dust à quelques serveurs MCP d’exemple via Okta Agent Gateway, puis vérifier comment les requêtes sont associées à l’agent et à l’utilisateur pour lequel il agit.

Dans les prochains jours, je publierai un article plus général sur Okta Agent Gateway, son architecture et son rôle dans l’accès de l’IA aux ressources de l’entreprise. Ici, nous nous concentrons sur la configuration nécessaire pour connecter un chatbot Dust.

À la fin de ce guide, vous disposerez :

• D’un agent IA enregistré dans Okta et lié à une application OIDC.
• D’un Gateway actif exposant les outils sélectionnés de vos serveurs MCP.
• D’une connexion Dust utilisant Static OAuth et Personal accounts.
• D’une conversation de test fonctionnelle et de l’activité correspondante dans Okta.

Ce que nous connectons

#

Okta Agent Gateway regroupe les outils de plusieurs serveurs MCP distants derrière un endpoint sécurisé par Okta. Dust se connecte à cet endpoint et le Gateway gère l’accès aux serveurs downstream configurés.²

La même configuration peut exposer les outils d’un ou de plusieurs serveurs MCP. Choisissez les services adaptés à votre cas d’usage : rechercher des documents, lire des informations dans des repositories ou mettre à jour un enregistrement métier, par exemple.

Deux connexions distinctes sont à configurer :

Nous préparons d’abord les connexions MCP downstream, puis configurons Dust pour utiliser le Gateway. Chaque fournisseur downstream peut également demander à l’utilisateur de s’authentifier et de donner son consentement avant de pouvoir utiliser ses outils.

La vue des composants présente les connexions configurées. La séquence ci-dessous se concentre sur une requête à un outil MCP, y compris la connexion du compte personnel lorsqu’elle est nécessaire.

sequenceDiagram
    actor User as Utilisateur
    participant Dust as Dust
    participant Okta as Okta Authorization Server
    participant Gateway as Okta Agent Gateway
    participant MCP as Serveur MCP distant
    User->>Dust: Demande une action via un outil MCP
    opt Connexion du compte personnel nécessaire
    Dust-->>User: Demande la connexion du compte personnel
    User->>Okta: S’authentifie et autorise l’accès si nécessaire
    Okta-->>Dust: Authorization code via la callback enregistrée
    Dust->>Okta: Échange le code avec les credentials du client enregistré
    Okta-->>Dust: Access token et refresh token lorsqu’il est accordé
    end
    Dust->>Gateway: Discovery ou appel d’outils avec l’access token
    Gateway->>Gateway: Vérifie l’accès et applique les contrôles configurés
    Gateway->>MCP: Appelle l’outil sélectionné via la connexion downstream
    MCP-->>Gateway: Résultat de l’outil
    Gateway-->>Dust: Résultat de l’outil
    Dust-->>User: Présente le résultat de l’outil

L’intégration Dust utilisée ici ne propose pas Cross App Access (XAA) pour cette connexion. Nous utilisons donc un OAuth authorization code flow avec un client enregistré et un client secret. Lorsque Dust ajoutera un support XAA compatible, ce sera mon option privilégiée pour l’authentification déléguée, avec une gestion centralisée des accès et moins d’étapes de consentement séparées pour l’utilisateur. La migration dépendra de l’intégration de Dust et devra préserver les contrôles et la visibilité du Gateway dont vous avez besoin. Pour le modèle de délégation, consultez le guide de configuration XAA³ et mon analyse détaillée des access patterns.

Prérequis

#

Avant de commencer, assurez-vous de disposer des éléments suivants :

1. Un tenant Okta avec AI Agents et Agent Gateway activés, ainsi que les droits nécessaires pour les gérer.

   Okta Preview

   J’ai utilisé un tenant Okta Preview pour essayer les fonctionnalités disponibles dans cette configuration. Les tenants Preview reçoivent les releases avant ceux de production, mais la disponibilité dépend aussi de l’activation des fonctionnalités et des licences. Vérifiez ces conditions pour votre tenant.⁴

2. Un workspace Dust avec un accès administrateur pour ajouter des serveurs MCP et créer des agents.

   Dust Free Tier

   Dust propose actuellement une licence Free avec 500 crédits à vie dans son offre Business, utile pour essayer la configuration. Ces crédits ne sont pas renouvelés chaque mois ; vérifiez les tarifs et les limites actuelles de l’offre avant de commencer.⁵

3. Au moins un serveur MCP distant accessible depuis le cloud d’Okta, avec une authentification OAuth 2.0 Bearer et les credentials nécessaires pour l’enregistrer.

4. Un utilisateur de test Okta à affecter à l’application liée, disposant aussi des droits nécessaires sur le service downstream.

La création ou le déploiement du serveur MCP sort du cadre de cet article. Vous pouvez utiliser un service hébergé compatible, comme le serveur MCP distant de GitHub, ou un serveur que vous développez et hébergez vous-même.

Avantages d’Agent Gateway

#

Pourquoi ajouter un Gateway entre Dust et vos outils ? La présentation d’Okta sur la runtime governance souligne l’intérêt de placer les contrôles d’identité directement sur le chemin des requêtes.⁶

• Contrôle centralisé des accès : gérez les agents qui peuvent atteindre le Gateway et les outils qu’il expose.
• Isolation des credentials downstream : Dust s’authentifie auprès du Gateway ; Okta gère les credentials downstream sans les exposer à Dust.
• Attribution à l’agent et à l’utilisateur : reliez l’activité des outils à l’agent et à la personne pour le compte de laquelle il agit.
• Un point d’intégration commun : connectez les clients MCP compatibles à un endpoint unique, avec une configuration gérée dans Okta.
• Un point central de confinement : désactivez une connexion ou le Gateway lors d’un incident. La section sur la révocation d’urgence explique comment appliquer ces contrôles.

Configuration d’Okta

#

Préparer les serveurs MCP downstream

#

Si vous n’avez pas encore configuré vos serveurs MCP dans Okta, commencez par enregistrer ceux dont vous souhaitez utiliser les outils dans Dust, en laissant de côté ceux déjà enregistrés. De nombreuses intégrations MCP sont disponibles dans le catalogue Okta Integration Network (OIN) : consultez-le avant de saisir une configuration manuellement.⁷ Les captures utilisent GitHub et AtkoTravel, un serveur MCP d’exemple doté d’outils de recherche et de réservation de vols. Vos propres serveurs peuvent proposer des fonctionnalités complètement différentes.

Choisissez le parcours via le catalogue à l’étape 2 ou l’enregistrement manuel à l’étape 3, puis complétez les étapes relatives aux credentials et à la discovery. Les entrées du catalogue préremplissent les informations du serveur ; l’enregistrement manuel permet de les fournir vous-même.⁷⁸

1. Dans l’Okta Admin Console, accédez à Applications and Resources → MCP Servers.

   

2. Sélectionnez Add from Catalog pour trouver un serveur MCP dans le catalogue OIN. Sélectionnez sa vignette, cliquez sur Add MCP Server et renseignez les éventuels champs propres à votre organisation. Okta préremplit les métadonnées disponibles du serveur.

3. Si votre serveur ne figure pas dans le catalogue, choisissez Add MCP Server et suivez l’enregistrement manuel⁸. Saisissez son nom et sa base URL, puis vérifiez ou fournissez les métadonnées de l’authorization server.

4. Configurez les credentials du client OAuth downstream et les scopes nécessaires. Pour l’enregistrement manuel, utilisez Dynamic Client Registration lorsque cette option est disponible et prise en charge par le fournisseur ; sinon, enregistrez un confidential OAuth client auprès du fournisseur et saisissez son Client ID et son Client Secret dans Okta. Lorsque XAA n’est pas pris en charge, pour une connexion assurée par Okta STS, la callback du fournisseur prend cette forme :

   https://YOUR_OKTA_DOMAIN/oauth2/v1/sts/callback

   Utilisez la callback requise par l’intégration Okta STS de votre fournisseur.⁹ Elle est distincte de la callback de Dust, qui doit être configurée dans l’application OIDC Okta liée.

5. Enregistrez les credentials, puis utilisez Test credentials and discover tools pour valider la connexion et découvrir les outils disponibles. Terminez l’enregistrement avec Done and close. Répétez l’opération pour chaque serveur MCP à inclure.

Enregistrer Dust comme agent IA dans Okta

#

Créer l’agent et activer l’accès des utilisateurs

#

1. Dans l’Okta Admin Console, ouvrez Directory → AI Agents → Register AI Agent → Register manually.

   

2. Donnez à l’agent un nom explicite, comme Dust Agent #1, et une description précisant son rôle.

   

3. Sélectionnez Allow users to access this agent, puis Create a new OIDC app linked to this AI agent. Cela crée automatiquement l’application utilisée pour le sign-in des utilisateurs.

   

4. Vous pouvez affecter un utilisateur ou un groupe comme owner afin d’identifier clairement le responsable de l’agent. Cela apporte également un contexte utile aux processus de gouvernance de votre organisation.

   

5. Terminez l’enregistrement. Notez que l’agent apparaît initialement avec le statut STAGED. Ouvrez ses détails pour configurer l’authentification du client.

   

6. Dans Client registration, configurez Client secret.

   

   Flux OAuth et authentification du client

   Nous utilisons ici Client secret, car c’est la seule méthode d’authentification prise en charge par l’implémentation actuelle de Static OAuth dans Dust.

   Public/private key est une méthode préférable et plus sûre, à utiliser lorsqu’elle est disponible dans le service de votre agent.

7. Cliquez sur Generate secret. Copiez le Client ID et le Client Secret dans un emplacement sécurisé, puis cliquez sur Activate. Ce sont les credentials du client que vous saisirez dans Dust.

   

Configurer l’application OIDC liée

#

Nous avons maintenant un agent IA enregistré et lié à une application OIDC. L’étape suivante consiste à configurer l’application pour l’accès des utilisateurs.

Activer l’application et affecter les utilisateurs

#

1. Dans l’onglet User Access de l’agent, suivez Application → Assignments pour ouvrir la fenêtre contenant l’application OIDC liée.

   

2. Activez l’application si elle est inactive.

   

3. Affectez les utilisateurs ou les groupes qui doivent pouvoir utiliser cet agent.

   

Enregistrer les URL de callback de Dust

#

1. Ouvrez les paramètres General de l’application et modifiez Sign-in redirect URIs.

   La callback EU que j’ai utilisée est : https://eu.dust.tt/oauth/mcp_static/finalize

   

   URL de callback de Dust

   La documentation MCP de Dust recommande d’enregistrer la callback régionale et la callback globale.¹⁰

   Pour un workspace EU, ajoutez ces deux entrées :

   • https://eu.dust.tt/oauth/mcp_static/finalize (régionale, EU)
   • https://app.dust.tt/oauth/mcp_static/finalize (globale)

   Pour un workspace US, utilisez https://dust.tt/oauth/mcp_static/finalize comme entrée régionale, avec la même callback globale. Enregistrez les paramètres de l’application.

Créer et activer Agent Gateway

#

Nous avons maintenant un agent IA enregistré, lié à une application OIDC et affecté aux utilisateurs. L’étape suivante consiste à créer l’Agent Gateway qui exposera les outils sélectionnés des serveurs MCP.

1. Accédez à Security → Agent Gateway → Create Agent Gateway.

   

2. Saisissez un nom, par exemple Dust Gateway. Vérifiez l’URL générée du Gateway et personnalisez son path si nécessaire, puis cliquez sur Create et Next.

   

3. Copiez l’URL complète du Gateway. Dans les exemples ci-dessous, il s’agit de :

   https://YOUR_ORG.gateway.oktapreview.com/mcp/servers/dust-gateway

   Utilisez votre propre URL exactement telle qu’elle apparaît. Le path ne peut pas être modifié après l’enregistrement.¹¹

4. Dans l’onglet AI Agents, cliquez sur Edit, sélectionnez Dust Agent #1 et enregistrez. Cliquez sur Next.

   

5. Dans Resource connections, cliquez sur Add connection dans la section des serveurs MCP.

   

6. Sélectionnez les serveurs MCP à exposer, puis Save et Next. La capture montre deux exemples : GitHub et AtkoTravel.

   

7. Dans Tool customization, cliquez sur Manage tools. Sélectionnez les outils que le Gateway doit exposer et enregistrez votre sélection avec Save. Répétez l’opération pour tous les serveurs MCP à exposer via le Gateway.

   

   

   Les captures montrent une sélection large pour cet exemple. Adaptez-la aux tâches que vos utilisateurs doivent accomplir. Vous pouvez toujours revenir ensuite pour ajouter ou retirer des outils.

8. Terminez le wizard une fois les outils souhaités activés.

   

9. Enfin, activez le Gateway s’il est encore inactif. Cliquez sur Activate now lorsque cette option est proposée, ou sélectionnez Actions → Activate.

   

À ce stade, vérifiez trois points : l’authentification du client de l’agent est activée, son application liée est active et affectée, et le Gateway lui-même est actif.

Découvrir les bons endpoints OAuth

#

Voici le détail de configuration qui mérite qu’on s’y attarde : utilisez l’authorization server indiqué par la ressource de votre Gateway. Ne déduisez pas l’issuer de votre domaine Okta et n’utilisez pas les authorization servers org ou default.

Nous pouvons utiliser les endpoints .well-known exposés pour découvrir l’issuer, l’authorization endpoint et le token endpoint corrects.

1. Pour une URL de Gateway se terminant par /mcp/servers/dust-gateway, insérez /.well-known/oauth-protected-resource immédiatement après le hostname afin de construire une URL comme celle-ci :

   https://YOUR_ORG.gateway.oktapreview.com/.well-known/oauth-protected-resource/mcp/servers/dust-gateway

   Vous pouvez ensuite utiliser curl, ou votre navigateur, pour demander le document de discovery. Par exemple :

   curl --fail --silent --show-error \
     'https://YOUR_ORG.gateway.oktapreview.com/.well-known/oauth-protected-resource/mcp/servers/dust-gateway' | jq

   Info

   Ce mécanisme de discovery fondé sur le path est défini dans la RFC 9728, section 3.1.¹²

   La réponse d’exemple a cette structure, avec les identifiants remplacés ici :

   {
     "resource": "https://YOUR_ORG.gateway.oktapreview.com/mcp/servers/dust-gateway",
     "authorization_servers": [
       "https://YOUR_ORG.oktapreview.com/oauth2/ausEXAMPLE"
     ],
     "scopes_supported": ["openid", "offline_access"]
   }

2. Notez la resource, l’authorization server indiqué et les scopes pris en charge. Nous utiliserons ces valeurs dans les étapes suivantes.

3. Pour l’issuer Okta retourné ci-dessus, nous devons demander ses métadonnées OIDC. Utilisez l’endpoint .well-known de cet authorization server. Par exemple :

   https://YOUR_ORG.oktapreview.com/oauth2/ausEXAMPLE/.well-known/openid-configuration

   Utilisez à nouveau curl (ou un navigateur) pour demander le document de discovery :

   curl --fail --silent --show-error \
     'https://YOUR_ORG.oktapreview.com/oauth2/ausEXAMPLE/.well-known/openid-configuration' | jq

4. Copiez authorization_endpoint et token_endpoint directement depuis la réponse. Voici un extrait illustratif :

   {
     "issuer": "https://YOUR_ORG.oktapreview.com/oauth2/ausEXAMPLE",
     "authorization_endpoint": "https://YOUR_ORG.oktapreview.com/oauth2/ausEXAMPLE/v1/authorize",
     "token_endpoint": "https://YOUR_ORG.oktapreview.com/oauth2/ausEXAMPLE/v1/token"
   }

Pour aller plus vite, j’ai créé un script d’OAuth discovery qui découvre la configuration OAuth indiquée par un Okta Agent Gateway. Il nécessite curl et jq ; passez l’URL du Gateway en argument ou définissez GATEWAY_URL.

Par exemple : bash discover-agent-gateway-oauth.sh 'https://YOUR_ORG.gateway.oktapreview.com/mcp/servers/dust-gateway'. Copiez ensuite les endpoints découverts et les scopes pris en charge dans Dust.

Configuration de Dust

#

Maintenant que nous avons l’URL du Gateway, les credentials du client et les bons endpoints de l’authorization server, nous pouvons configurer Dust pour se connecter à Okta Agent Gateway.

Ajouter le Gateway à Dust

#

Créer la connexion MCP

#

1. Dans Dust, ouvrez Spaces → Tools → + Add Tools.

   

2. Sélectionnez Add MCP Server.

   

3. Collez la Gateway MCP URL, puis choisissez Static OAuth comme méthode d’authentification.

   

4. Renseignez le formulaire avec vos propres credentials et les résultats de la discovery :

   Champ Dust	Valeur pour cette configuration
   URL	L’URL MCP complète du Gateway, se terminant par /mcp/servers/dust-gateway
   Authentication	Static OAuth
   How do you want to connect?	Personal accounts
   OAuth Client ID	Client ID copié depuis l’onglet Client registration de l’agent IA dans Okta
   OAuth Client Secret	Le client secret actif correspondant
   OAuth Token Endpoint	token_endpoint du document de discovery de l’issuer du Gateway
   OAuth Authorization Endpoint	authorization_endpoint du même document de discovery
   OAuth Scope(s)	openid offline_access, comme indiqué dans cet exemple
   OAuth Resource / Audience	Laissé vide dans la configuration testée ; voir la note ci-dessous
   Token Endpoint Authentication Method	Request body (client_secret_post) pour la configuration du client utilisée ici

   Choisissez Personal accounts pour que les utilisateurs établissent leurs propres connexions. Dust précise que les administrateurs doivent tout de même réaliser une connexion OAuth initiale pendant le setup, puis que chaque utilisateur s’authentifie lors de sa première utilisation de l’outil. Voir Personal vs Shared Credentials.

   

5. Cliquez sur Setup connection et terminez l’autorisation initiale si elle est demandée. La connexion devrait ensuite apparaître dans Dust avec l’authentification active.

   

   Resource, audience et scopes

   Laisser Resource / Audience vide a fonctionné dans cette configuration testée. Ce n’est pas une règle valable pour toute intégration OAuth, et la valeur resource indiquée n’est pas automatiquement interchangeable avec chaque paramètre audience propre à un fournisseur.

   Si votre environnement exige un resource indicator explicite, utilisez la resource du Gateway indiquée dans les métadonnées et vérifiez que la configuration respecte ses exigences.

   De même, utilisez des scopes pris en charge par l’authorization server du Gateway. Les scopes downstream, comme tool:search, appartiennent à la connexion downstream ; ne les copiez pas dans Dust.

6. Ouvrez Tools & Stakes pour confirmer que la discovery a réussi et vérifier le paramètre de confirmation de chaque outil.

   

   Dans mon setup, les outils apparaissaient initialement comme High, ce qui exige une confirmation à chaque exécution. L’interface proposait aussi Low, qui permet de mémoriser la confirmation de l’utilisateur, et Never ask, qui autorise l’exécution automatique.

7. Gardez la confirmation activée pour les opérations ayant des conséquences importantes, comme créer, modifier ou supprimer des enregistrements. Les paramètres de confirmation de Dust régissent l’interaction avec l’utilisateur ; l’autorisation dans Okta et dans le service downstream reste un contrôle distinct.

Créer un chatbot dans Dust

#

Créez un chatbot adapté aux outils MCP que vous avez connectés. Les captures montrent un assistant de voyage, mais les mêmes étapes s’appliquent à un assistant pour repositories, à la recherche documentaire ou à un autre workflow métier.

Créer le chatbot et définir ses instructions

#

1. Ouvrez Create → From Scratch dans Dust.

   

2. Dans Instructions, décrivez le rôle du chatbot, les outils qu’il doit utiliser et le résultat attendu. La capture montre un assistant de voyage ; adaptez son rôle et ses instructions à votre cas d’usage :

   

   Info

   Dans l’exemple illustré, les instructions spécialisent le chatbot dans la recherche de vols ainsi que la création, la consultation, la modification et l’annulation des réservations. Remplacez ce périmètre par les fonctionnalités de votre MCP. Le prompt guide le comportement ; les permissions doivent toujours être appliquées par les systèmes connectés.

3. Dans Capabilities and knowledge, cliquez sur Add Capability.

   

4. Sélectionnez Dust Gateway parmi les outils disponibles, puis cliquez sur + Add.

   

5. Confirmez avec Add 1 Capability.

   

6. Définissez le nom, la description et la visibilité du chatbot en fonction de son rôle. TravelHelper est simplement le nom d’exemple dans les captures. Enregistrez l’agent.

   

7. Cliquez sur Start Chat pour ouvrir une conversation.

   

Tester la connexion end-to-end

#

Commencez par une requête en lecture seule correspondant à un outil exposé par votre serveur MCP. Par exemple, demandez à un MCP pour repositories de lister ceux qui sont accessibles, ou à un MCP documentaire de rechercher un document. Avec le serveur d’exemple pour les vols présenté ici, j’utilise :

Search for flights from CDG to LIN for next Thursday.

Adaptez la requête à votre MCP connecté et aux permissions de votre utilisateur de test.

Lors de la première utilisation, Dust vous demande de connecter votre compte au Gateway. Cliquez sur Connect Dust gateway, puis effectuez le sign-in Okta et les étapes d’autorisation requises par votre configuration.

Cela établit la connexion OAuth de l’utilisateur. Elle est distincte de la simple connexion au workspace Dust.

Une fois connecté, Dust appelle le Gateway, qui contacte le serveur MCP sélectionné et renvoie les résultats de l’outil. Ici, ces résultats sont des propositions de vols.

Si votre MCP prend en charge des opérations d’écriture, testez-en une sur des données temporaires de test et vérifiez la demande de confirmation. Dans l’exemple des vols, une requête de suivi pourrait être :

Book the first flight, departing at 06:30.

Pour un autre MCP, remplacez-la par une action adaptée, comme créer une issue de test dans GitHub.

Cette requête de suivi a réutilisé la connexion établie sans nouveau sign-in OAuth. Cela ne signifie pas que l’accès est permanent : l’expiration des tokens, le comportement du refresh, la révocation et les changements de policies peuvent nécessiter une nouvelle connexion ou provoquer l’échec d’un appel ultérieur.

Adaptez les tests suivants aux opérations prises en charge par votre MCP. L’exemple des vols permet aussi de consulter, modifier et annuler des réservations ; les captures illustrent uniquement la recherche et la réservation, pas tous les outils ni toutes les intégrations downstream.

Visibilité et application des policies

#

Tracer l’agent et l’utilisateur dans Okta

#

La vérification finale utile consiste à corréler la conversation avec l’activité enregistrée dans Okta.

Ouvrez le System Log et examinez les événements autour de l’heure de votre test. La configuration présentée ici a enregistré les appels d’outils avec l’event type agent_gateway.mcp.tool.call.

Voici un extrait abrégé et anonymisé de l’événement de réservation d’exemple. Votre serveur MCP produira des noms d’outils et de cibles différents :

{
  "actor": {
    "id": "wlpEXAMPLE",
    "type": "Agent",
    "displayName": "Dust Agent #1"
  },
  "displayMessage": "Call MCP tool",
  "eventType": "agent_gateway.mcp.tool.call",
  "outcome": {
    "result": "SUCCESS"
  },
  "gatewayContext": {
    "capabilityName": "AtkoTravelMCP_book",
    "clientId": "wlpEXAMPLE",
    "subject": {
      "type": "User",
      "id": "00uEXAMPLE",
      "alternateId": "traveler@example.com"
    }
  },
  "target": [
    {
      "type": "VIRTUAL_MCP_SERVER",
      "displayName": "dust-gateway"
    },
    {
      "type": "TARGET_MCP_SERVER",
      "displayName": "AtkoTravel MCP"
    }
  ]
}

L’événement associe la requête à son contexte d’identité et d’exécution :

• Quel agent ? actor.displayName identifie Dust Agent #1.
• Pour le compte de qui ? gatewayContext.subject identifie l’utilisateur.
• Quelle opération ? capabilityName identifie l’outil de réservation.
• Via quelle connexion ? Les cibles identifient le Gateway et le serveur MCP downstream.
• Que s’est-il passé ? L’événement enregistre le résultat de l’appel.

Pour une vue centrée sur le Gateway, ouvrez Security → Agent Gateway → Dust Gateway → Recent Activity.

La documentation d’Okta sur l’activité du Gateway décrit cette vue et renvoie au System Log pour les événements associés d’authentification et de token exchange.¹⁴ L’exemple ci-dessus montre l’attribution et les métadonnées des appels ; il ne garantit pas que les payloads complets des requêtes et réponses de chaque outil sont enregistrés.

Policies d’accès aux outils

#

Une connexion fonctionnelle n’est que le point de départ. Déterminez qui peut utiliser l’agent, quel agent peut atteindre le Gateway et quels outils le Gateway expose. Ces contrôles se complètent, tandis que le service downstream continue d’appliquer ses propres permissions.

Par exemple, un assistant documentaire peut avoir besoin d’outils de recherche et de lecture sans pouvoir supprimer des documents. Voici comment j’appliquerais cette limite à la configuration :

1. Restreignez l’accès des utilisateurs. Affectez uniquement les utilisateurs ou groupes prévus à l’application OIDC liée. Dans son onglet Sign On, vérifiez l’app sign-in policy affectée et ses exigences d’authentification. Configurez MFA et les autres conditions adaptées à vos utilisateurs.¹⁶ Cela régit l’authentification de l’utilisateur ; cela ne sélectionne pas les outils MCP individuellement.
2. Autorisez l’agent prévu. Dans Security → Agent Gateway → Dust Gateway → AI Agents, ne conservez que les agents qui doivent utiliser cet endpoint. La connexion est également visible dans l’onglet Resource connections de chaque agent.²
3. Réduisez l’ensemble des outils exposés. Ouvrez Tool customization → Manage tools pour chaque serveur MCP connecté. Conservez les opérations de recherche et de lecture nécessaires, désélectionnez les opérations d’écriture ou de suppression inutiles et enregistrez.¹¹ Cela modifie les outils exposés via le Gateway, indépendamment des instructions du chatbot.
4. Testez les deux résultats. Actualisez la liste des outils dans Dust si nécessaire, puis confirmez qu’une requête autorisée fonctionne et qu’un outil retiré n’est plus disponible. Répétez avec un utilisateur de test non affecté pour vérifier la limite d’accès des utilisateurs. Utilisez l’activité du Gateway et le System Log pour analyser les résultats inattendus.

Kill Switch et révocation d’accès en urgence

#

Désactiver un agent constitue déjà un Kill Switch : cela empêche l’agent d’obtenir de nouveaux tokens via Okta et d’établir de nouvelles sessions.¹⁷¹⁸ Si un agent commence à effectuer des appels inattendus, les administrateurs disposent ainsi d’un moyen centralisé de contenir son activité sur ses connexions gérées.

Pour cette configuration, choisissez le contrôle adapté au périmètre de l’incident :

1. Désactivez l’agent. Ouvrez Directory → AI Agents → Dust Agent #1 et sélectionnez Actions → Deactivate.¹⁷
2. Limitez le confinement à une connexion si nécessaire. Dans l’onglet Resource connections de l’agent, sélectionnez Deactivate connection pour le Gateway. Cela refuse les futures demandes d’accès via cette connexion.¹⁹ Pour suspendre l’ensemble du Gateway, utilisez plutôt Security → Agent Gateway → Dust Gateway → Actions → Deactivate. Cela concerne tous les agents qui utilisent cet endpoint.¹¹
3. Vérifiez le résultat et conservez les éléments de preuve. Confirmez que l’agent désactivé ne peut plus obtenir de nouveau token. Réessayez une requête sans conséquence depuis une conversation Dust existante pour vérifier l’effet sur les tokens déjà émis. Consignez la modification administrative et examinez l’activité suivante dans le System Log et dans l’activité du Gateway. Pour un compte utilisateur compromis, suivez également votre procédure de gestion des sessions utilisateur et de récupération des credentials.
4. Rétablissez l’accès après l’investigation. Vérifiez le compte concerné, les credentials de l’agent, les resource connections et la sélection des outils. Ne réactivez que les composants nécessaires, puis répétez les vérifications d’accès.

Les tokens déjà émis peuvent rester utilisables jusqu’à leur expiration effective.²⁰ L’extension prévue du Kill Switch à Agent Gateway rendra le confinement plus efficace en ajoutant la révocation des tokens actifs et la terminaison des sessions en cours.¹⁸

Le Gateway est un point utile pour appliquer ces contrôles, car il se trouve sur le chemin des requêtes vers plusieurs services MCP. Conservez les procédures de réponse côté fournisseur pour les credentials ou les connexions directes en dehors de ce chemin ; couper l’accès ne peut pas annuler une opération déjà réalisée downstream.

Pour aller plus loin

#

Nous disposons maintenant d’une intégration concrète : Dust fournit l’expérience conversationnelle, vos serveurs MCP fournissent les outils et Okta Agent Gateway se place sur le chemin d’accès avec un agent identifiable, le contexte de l’utilisateur et une activité des outils observable.

Ce que j’apprécie dans cet exemple, c’est le peu de code personnalisé nécessaire à la connexion. Une fois le serveur MCP prêt, le travail consiste surtout à configurer : enregistrer l’agent, affecter les accès, sélectionner les outils et connecter Dust avec les bonnes métadonnées OAuth.

Dans les prochains jours, je consacrerai un article plus général à Okta Agent Gateway, à son architecture et à la manière dont cette approche s’applique à d’autres plateformes d’agents.

Utilisez-vous déjà Dust avec des outils d’entreprise ? Quelle intégration MCP placeriez-vous en premier derrière un Gateway ?

Partagez votre expérience ou vos questions dans les commentaires.