Gouvernance du connecteur MCP via une passerelle API AI : jetons OAuth, étendues d'outils et attribution par utilisateur

Lorsqu'un agent appelle Gmail, Drive, Stripe, un système interne ou un serveur MCP distant, la requête de modèle n'est qu'une partie de l'événement de sécurité. La véritable question opérationnelle est la suivante : qui a autorisé le connecteur, quelles OAuth étendues ont été accordées, quel outil a été invoqué, quelles données ont quitté les limites du fournisseur de modèles et comment l'accès peut-il être révoqué lors d'un incident ?

Une passerelle IA API qui ne peut répondre qu'aux appels de modèles proxy pour répondre à ces questions. Il peut connaître le locataire, le modèle, la clé API, la taille de l'invite et le coût. Il ne sait peut-être pas que le modèle a délégué le travail à un connecteur fonctionnant sous le jeton OAuth d'un utilisateur humain. Cette lacune affaiblit l'attribution, la politique d'approbation, la révocation et la réponse à l'audit.

Le modèle pratique consiste à traiter l'autorisation du connecteur MCP comme un objet de plan de contrôle de passerelle de première classe. Ne réduisez pas la gouvernance des connecteurs à une liste blanche de noms d’outils. Gérez l'inscription des connecteurs, la provenance des OAuth jetons, la classification de la portée des outils, la politique d'approbation, l'état de révocation et la journalisation d'audit dans le cadre de la même couche de gouvernance qui gère déjà la API gestion des clés, l'accès aux modèles, la politique des locataires et l'analyse de l'utilisation.

Faits, recommandations et prédictions

Faits : OpenAI documente le MCP distant en tant que catégorie d'outils Réponses API et permet aux applications de fournir un jeton d'accès OAuth pour un serveur MCP distant. OpenAI identifie également les connecteurs de services hébergés tels que Gmail, Google Drive, Google Calendar, Dropbox et Microsoft Teams. La documentation de contrôle des données de OpenAI indique que les serveurs MCP utilisés avec l'outil de serveur distant MCP sont des services tiers et que les données qui leur sont envoyées sont soumises aux politiques de conservation de ces services. La documentation des connecteurs Anthropic décrit les connecteurs personnalisés utilisant des serveurs MCP distants et note que les utilisateurs autorisent généralement les connecteurs via OAuth, avec des autorisations qui peuvent être révoquées ultérieurement. La spécification d'autorisation MCP utilise une autorisation de style OAuth pour les transports HTTP basés sur MCP. OAuth Les directives de sécurité de la RFC 9700 concernent la gestion des jetons, les flux de codes d'autorisation et la sécurité des clients.

Recommandations : Une passerelle doit enregistrer les connecteurs avant utilisation en production, lier chaque appel de connecteur au locataire, à la clé, à l'utilisateur, au sujet du jeton et à l'identité du serveur, classer les outils par risque de lecture/écriture, appliquer la politique d'approbation avant l'envoi et maintenir l'état de révocation de manière centralisée.

Prédictions : L'adoption à distance MCP poussera les passerelles IA au-delà du routage des modèles et de la mesure des jetons. Les passerelles qui ne peuvent pas voir l'identité du connecteur, OAuth la portée, les décisions d'approbation et les limites de rétention en aval seront plus difficiles à utiliser dans les environnements réglementés, d'entreprise et exploités par des partenaires.

Le problème de gouvernance est le fractionnement de l'identité

Les appels de connecteur impliquent au moins trois identités et ne doivent pas être fusionnés dans les journaux ou les vérifications de stratégie.

• Appelant de la passerelle : la clé API, le compte de service, la charge de travail ou l'application partenaire qui a soumis la demande de modèle.
• Utilisateur délégué : l'utilisateur humain ou final qui a autorisé l'accès à Gmail, Drive, CRM, l'agenda, les paiements, les données internes ou une autre ressource protégée.
• Cible du connecteur : le serveur MCP distant ou le connecteur de service hébergé qui reçoit l'appel de l'outil et peut le transmettre à un autre système.

Si ces identités sont réduites à un seul champ appelé user, la piste d'audit devient ambiguë. Un compte de service de production peut soumettre une demande au nom de 20 000 utilisateurs finaux. Un seul humain peut autoriser plusieurs connecteurs avec des portées différentes. Un serveur MCP distant peut exposer des outils soutenus par plusieurs services en aval. La passerelle a besoin de champs distincts pour les trois.

Un modèle d'événement utile commence par des champs tels que :

{
  "request_id": "req_01J...",
  "tenant_id": "tenant_acme",
  "gateway_key_id": "key_support_bot_prod",
  "workload_id": "support_agent",
  "end_user_id": "user_7421",
  "connector_id": "conn_google_drive_support",
  "mcp_server_url_hash": "sha256:...",
  "oauth_subject": "google-oauth-sub:...",
  "tool_name": "drive.files.search",
  "tool_action_class": "read",
  "approval_decision": "auto_allowed",
  "retention_class": "third_party_standard",
  "downstream_request_id": "optional_provider_or_connector_id"
}

Cette structure permet aux équipes de sécurité, de finance et de plate-forme de répondre à différentes questions à partir du même enregistrement. Quel locataire a invoqué l’outil ? Quelle clé d'application l'a fait ? Quel accès délégué à l'utilisateur final ? Quel connecteur a reçu des données ? L'action était-elle en lecture seule ou destructrice ? L'approbation était-elle requise ?

Modèle de connecteurs en tant que ressources de passerelle

Un connecteur doit être inscrit avant d'être utilisé en production. L'inscription n'a pas besoin d'être lente, mais elle doit produire un objet durable auquel la politique peut faire référence.

Une ressource de connecteur minimale peut inclure :

• tenant_id : le locataire ou l'organisation autorisé à utiliser le connecteur.
• connector_id : un identifiant interne stable, indépendant des noms d'affichage du serveur.
• server_url : l'URL du serveur MCP distant ou l'identifiant du connecteur hébergé.
• owner_user_id : l'administrateur ou l'utilisateur qui l'a inscrit.
• authorization_server : métadonnées de l'émetteur ou du serveur d'autorisation si disponibles.
• allowed_tools : noms et versions d'outils examinés ou empreintes digitales.
• tool_classes : lecture, écriture, exportation, administration, paiement, messagerie ou inconnu.
• approved_scopes : OAuth étendues approuvées pour le connecteur.
• retention_class : norme interne, fournisseur de modèles, tierce ou interdite pour les charges de travail sensibles.
• revocation_status : actif, user_revoked, tenant_disabled, expiré, mis en quarantaine ou refusé.

Ceci est similaire dans son esprit à un profil de modèle ou à un enregistrement d'informations d'identification de fournisseur, mais l'autorisation de connecteur n'est pas le même objet qu'une clé de modèle en amont. Les informations d’identification d’exécution du fournisseur permettent à la passerelle d’appeler les API du modèle. Les jetons de connecteur représentent une autorité déléguée dans des systèmes tiers ou internes. Ils méritent une provenance, des contrôles de stockage et une politique d'audit distincts.

Courtier ou valider OAuth jetons délibérément

Il existe deux modèles de mise en œuvre courants.

Gateway-négocié OAuth

Dans ce modèle, la passerelle initie ou coordonne le flux OAuth, stocke les jetons d'actualisation ou le matériel de jeton d'accès dans un coffre-fort, crée des sessions de connecteur de courte durée et attache des jetons d'accès lors de l'envoi d'appels MCP à distance. Cela donne à la passerelle un contrôle strict sur le consentement, la durée de vie du jeton, la révocation et les jointures d'audit.

Le compromis est la complexité. La passerelle doit gérer les écrans de consentement, la sécurité du flux de code d'autorisation, l'actualisation des jetons, la rotation des jetons, le stockage chiffré, la gestion des URI de redirection, la validation de l'émetteur et la configuration de l'application OAuth spécifique au locataire. La RFC 9700 est importante ici car ce modèle rapproche la passerelle des OAuth responsabilités du client.

Géré par les applications OAuth

Dans ce modèle, l'application obtient le jeton OAuth et le transmet via le chemin du modèle ou de la passerelle lors de l'appel d'un connecteur MCP distant. Cela peut être plus rapide à expédier, car les produits existants peuvent déjà disposer de flux d'autorisation de connecteur.

Le compromis est une gouvernance fragmentée. Si la passerelle ne voit qu'un jeton opaque, il se peut qu'elle ne connaisse pas le sujet, les portées, l'émetteur, la fraîcheur, le statut de révocation ou la provenance du consentement du jeton. Une version plus sûre de ce modèle nécessite que l'application fournisse des métadonnées de connecteur signées à chaque appel, et la passerelle doit valider l'émetteur, l'audience, l'expiration, l'inscription du connecteur, la liaison utilisateur et la portée approuvée avant l'envoi.

Pour les connecteurs de données utilisateur tels que la messagerie électronique, l'agenda, le stockage, le CRM et les paiements, préférez les OAuth jetons par utilisateur. Les jetons de support partagés à longue durée de vie doivent être limités aux flux de travail explicites de compte de service limités à un locataire et considérés comme des ressources à plus haut risque.

Normaliser les étendues des outils avant l'expédition

MCP serveurs peuvent exposer les noms d'outils et les métadonnées, et certains écosystèmes fournissent des astuces telles que des annotations en lecture seule. Utilisez ces signaux, mais ne considérez pas les métadonnées fournies par le serveur comme étant totalement fiables. Les métadonnées des outils peuvent être erronées, obsolètes, ambiguës ou contradictoires. Les directives MCP de l'OWASP mettent en évidence le moindre privilège, la liste blanche, l'authentification, l'autorisation et la surveillance ; MCP Les 10 travaux les plus importants attirent également l'attention sur les risques d'empoisonnement des outils.

Une passerelle doit conserver ses propres classes d'actions normalisées :

• Lire : rechercher, répertorier, obtenir, récupérer, récupérer, résumer le contenu existant.
• Écrire : créer, mettre à jour, modifier, étiqueter, déplacer, commenter, planifier.
• Envoyer : e-mail, message de chat, webhook, réponse au ticket, notification.
• Supprimer : supprimer, purger, archiver, révoquer.
• Exportation : téléchargement groupé, transfert de fichiers, extraction d'ensembles de données.
• Finance : frais, remboursement, facture, paiement, modification d'abonnement.
• Administrateur : modification d'autorisation, invitation d'utilisateur, mise à jour de rôle, modification de stratégie.
• Inconnu : tout ce qui n'a pas été examiné ou n'est pas classé de manière fiable.

Ensuite, appliquez la stratégie sur les classes normalisées au lieu des noms d'outils bruts. Par exemple :

policy connector_default {
  allow read when tenant.connector_risk in ["low", "medium"]
    and user.authorization_age_days <= 90
    and connector.retention_class != "prohibited";

  require_approval send, write when connector.risk != "low";
  require_approval export, delete, financial, admin;
  deny unknown;
}

Cela maintient la stratégie stable lorsqu'un connecteur renomme gmail.search en mail.messages.query. L'outil brut doit encore être révisé, mais le système d'approbation peut raisonner en catégories opérationnelles.

Exécuter une vérification du connecteur avant expédition

Avant que la passerelle n'autorise un appel de connecteur initié par le modèle, elle doit exécuter une décision compacte de pré-répartition. C'est ici que se rencontrent les analyses d'utilisation de l'IA, la politique de sécurité, le flux de travail d'approbation et la politique de rétention.

Une séquence pratique est la suivante :

1. Résoudre le locataire et la clé : identifiez la clé de passerelle, le locataire, la charge de travail, l'environnement et la demande de modèle.
2. Résoudre l'utilisateur final : nécessite un ID d'utilisateur final stable pour les connecteurs délégués. Rejetez les appels délégués anonymes, sauf autorisation explicite.
3. Résoudre le connecteur : faire correspondre l'URL du serveur ou l'ID du connecteur hébergé à une ressource de connecteur inscrite.
4. Valider le jeton : vérifier l'émetteur, le public le cas échéant, l'expiration, l'objet, la liaison du locataire, l'état de révocation et les étendues requises.
5. Classifier l'action : mapper le nom et les métadonnées de l'outil à lire, écrire, envoyer, supprimer, exporter, financier, administratif ou inconnu.
6. Vérifiez la limite de conservation : déterminez si la charge de travail autorise le traitement et la journalisation par un serveur MCP tiers.
7. Appliquer la politique d'approbation : autoriser automatiquement, exiger l'approbation de l'utilisateur, exiger l'approbation de l'administrateur, bloquer ou mettre en quarantaine.
8. Budget de réserve si facturable : si l'exécution du connecteur entraîne des frais directs ou indirects, réservez le budget avant l'envoi.
9. Écrivez la décision : conservez la décision avant d'appeler le connecteur, pas seulement après le succès.

La rédaction de la décision compte d'abord. Si le connecteur expire, diffuse une sortie partielle ou déclenche une erreur en aval, le journal d'audit doit toujours indiquer que la passerelle a autorisé ou refusé une tentative d'action spécifique.

L'approbation doit tenir compte du flux de travail

L'approbation par appel est simple à raisonner et souvent inutilisable en pratique. Un agent du support client qui a besoin de lire un ticket, de rechercher Drive, de rédiger un e-mail et de mettre à jour un enregistrement CRM ne doit pas forcer l'utilisateur à utiliser un modal pour chaque opération de lecture inoffensive. Dans le même temps, l'envoi d'un e-mail, la suppression d'un fichier, le remboursement d'un paiement ou l'exportation d'un dossier ne doivent pas être délégués silencieusement parce qu'un modèle a sélectionné un outil.

Une politique réalisable comporte plusieurs niveaux :

• Autoriser automatiquement les outils en lecture seule examinés pour les locataires à faible risque et les nouvelles autorisations d'utilisateurs.
• Exiger l'approbation pour les actions d'envoi, de création, de mise à jour, de suppression, d'exportation, financières et administratives.
• Autoriser les approbations groupées pour un flux de travail, une portée et une fenêtre temporelle nommés.
• Exiger une nouvelle approbation lorsque les portées s'étendent, que les définitions des outils changent sensiblement ou que le connecteur passe à une classe de risque plus élevée.
• Bloquer les outils inconnus jusqu'à ce qu'ils soient examinés.

Les approbations groupées doivent être explicites. Un utilisateur peut approuver : "Pendant les 30 prochaines minutes, autorisez ce flux de travail d'assistance à rechercher dans Drive et à rédiger des réponses, mais exigez une confirmation avant l'envoi." C'est plus utile qu'un commutateur d'autorisation/refus de connecteur binaire.

Les limites de rétention ont besoin de leur propre champ

Les appels à distance MCP peuvent déplacer les données en dehors des limites de conservation et de traitement du fournisseur de modèles. Ce n’est pas automatiquement faux, mais cela doit être visible. Une charge de travail autorisée à utiliser un point de terminaison de modèle dans le cadre d'un paramètre de conservation des données peut toujours se voir interdire d'envoyer le même contenu à un serveur MCP tiers avec des conditions de conservation différentes.

Ajoutez une classification de rétention aux charges de travail et aux connecteurs. Exemples de classes :

• internal_only : aucun appel de connecteur tiers n'est autorisé.
• approved_processors_only : le connecteur doit figurer sur une liste de fournisseurs approuvés.
• third_party_standard_allowed : le traitement du connecteur SaaS standard est autorisé.
• no_argument_logging : les appels de connecteur sont autorisés, mais les arguments doivent être expurgés ou hachés.
• export_blocked : lecture/recherche autorisée, exportation groupée refusée.

C'est ici que la passerelle protège les équipes d'une erreur subtile : supposer que les contrôles de données du fournisseur de modèle s'appliquent automatiquement à chaque outil utilisé par l'agent. Ils ne s'appliquent pas nécessairement une fois que les données sont envoyées à un serveur MCP distant ou à un connecteur de service externe.

Créer un registre d'audit des connecteurs

Un registre d'audit de connecteur doit joindre les demandes de modèle, l'autorisation de passerelle, la répartition du connecteur et les résultats en aval. Ne vous fiez pas uniquement aux traces brutes du fournisseur, car chaque fournisseur peut exposer les événements de l'outil différemment et les journaux d'application peuvent omettre le jeton ou le contexte d'approbation.

Les champs du grand livre recommandés incluent :

• model_request_id et ID de trace.
• tenant_id, gateway_key_id, charge de travail, environnement et ID de l'utilisateur final.
• connector_id, hachage de l'URL du serveur, identifiant du connecteur hébergé et classe de risque.
• tool_name, version de l'outil ou empreinte digitale des métadonnées et classe d'action normalisée.
• OAuth émetteur, sujet du jeton, hachage de l'ensemble de portées, compartiment d'expiration et provenance du jeton.
• Hash des arguments, arguments expurgés, classe de sensibilité et classe de rétention.
• Décision d'approbation, approbateur, portée de l'approbation et expiration de l'approbation.
• État de distribution, état de réponse, classe d'erreur, latence et ID de requête en aval, le cas échéant.

La journalisation complète des arguments peut faciliter la réponse aux incidents, mais elle augmente également les risques en matière de confidentialité et de rétention. Préférez les champs structurés, le hachage, la rédaction sélective et les balises de sensibilité par défaut. Autoriser la capture complète uniquement dans le cadre d'un incident explicite ou d'une stratégie de débogage avec expiration.

La révocation et la quarantaine sont des exigences relatives au produit

La révocation ne peut pas être une modification manuelle de la base de données. Les utilisateurs et les administrateurs ont besoin de flux de travail qui se transforment en état de stratégie immédiat.

Mettez en œuvre au moins ces actions :

• Déconnexion de l'utilisateur : révoque ou marque comme inactifs tous les jetons pour l'autorisation du connecteur d'un utilisateur.
• Désactivation du locataire : bloque un connecteur pour l'ensemble d'un locataire sans désactiver le trafic de modèle non lié.
• Gestion de l'expiration des jetons : échec de fermeture ou réautorisation lorsque l'actualisation échoue ou que la fraîcheur de l'autorisation dépasse la politique.
• Quarantaine des connecteurs : bloque un connecteur tout en préservant sa configuration et ses journaux pour enquête.
• Liste de refus d'urgence : blocage par hachage d'URL du serveur, ID de connecteur, émetteur ou empreinte digitale de l'outil.
• Rétrogradation de l'étendue : autorisez à nouveau avec moins d'étendues lorsqu'un workflow n'a plus besoin d'un accès large.

Le détail important de la mise en œuvre est que le statut de révocation doit être vérifié au moment de l'envoi. Une synchronisation nocturne est utile pour la réconciliation, mais elle n'est pas suffisante pour la réponse aux incidents.

Sondes de conformité pour les MCP connecteurs distants

Avant qu'un connecteur soit disponible pour les locataires de production, testez-le en tant que dépendance gouvernée. Une courte suite de sondes détecte de nombreux échecs d'intégration et de stratégie.

• La découverte de métadonnées renvoie une identité de serveur stable et les définitions d'outils attendues.
• Les métadonnées des ressources protégées et le comportement d'autorisation correspondent aux hypothèses documentées, le cas échéant.
• Les exigences d'enregistrement des clients dynamiques sont comprises, prises en charge ou explicitement désactivées.
• Les requêtes sans jetons échouent en toute sécurité.
• Les jetons expirés échouent de manière prévisible et ne déclenchent pas de tentatives incontrôlées.
• La classification en lecture/écriture correspond au comportement observé, pas seulement aux descriptions.
• Les métadonnées d'outils mal formées sont rejetées ou marquées comme inconnues.
• Les modifications de la liste d'outils déclenchent un examen lorsque les noms, les étendues, les descriptions ou les classes de risque changent.
• Les erreurs de connecteur sont enregistrées sans fuite d'arguments sensibles dans des champs d'erreur génériques.

Ces sondes ne remplacent pas l'examen de sécurité, mais elles donnent à la passerelle un moyen reproductible de détecter la dérive. Les MCP serveurs distants peuvent changer indépendamment du fournisseur de modèle et indépendamment du cycle de publication de votre application.

Liste de contrôle de mise en œuvre

• Créez un registre de connecteurs avec les champs locataire, serveur, autorisation, portée, outil, risque, rétention et révocation.
• Identité de clé de passerelle distincte, identité d'utilisateur final déléguée et identité de connecteur dans chaque décision politique.
• Stockez les jetons de connecteur dans un coffre-fort d'informations d'identification, mais conservez-les distincts des informations d'identification d'exécution du fournisseur de modèles.
• Préférer par utilisateur OAuth pour les connecteurs de données utilisateur ; limiter les jetons de service partagé aux workflows explicites de compte de service.
• Normalisez les actions de l'outil en lecture, écriture, envoi, suppression, exportation, finances, administration et inconnu.
• Exécutez des vérifications avant expédition pour l'inscription du connecteur, la validité des jetons, la correspondance de portée, la compatibilité de rétention, l'état d'approbation et la réservation de budget.
• Enregistrer les décisions du connecteur avant l'envoi et régler le statut final après une réponse ou une erreur.
• Créez des workflows de déconnexion d'utilisateur, de désactivation de locataire, de quarantaine de connecteurs et de liste de refus d'urgence.
• Sondez les métadonnées du connecteur, le comportement des jetons, la dérive des outils et les métadonnées mal formées avant utilisation en production.

Conclusion exploitable

MCP et les connecteurs de services rendent les agents utiles car ils permettent aux modèles d'agir sur des systèmes réels. Cette même utilité transforme l'autorisation du connecteur en un problème de plan de contrôle, et non en un détail d'ingénierie rapide.

La passerelle doit en savoir plus que le modèle, le nombre de jetons et la clé API. Il doit savoir quel connecteur a été appelé, quel utilisateur l'a autorisé, quelles étendues ont été accordées, quelle classe d'action d'outil a été demandée, si une approbation était requise, si la limite de rétention était compatible et comment l'accès peut être révoqué. Commencez par un registre de connecteurs, une vérification de la politique avant expédition et un registre d'audit joint. Ajoutez ensuite OAuth courtage, approbations groupées, vérifications de conformité et quarantaine d'urgence à mesure que l'utilisation du connecteur augmente.

L'objectif n'est pas de bloquer l'adoption à distance MCP. L'objectif est de rendre l'accès au connecteur attribuable, révocable, révisable et compatible avec les mêmes attentes de gouvernance que les équipes appliquent déjà à l'accès aux modèles et à une passerelle OpenAIcompatible API.

Lecture connexe

• modèles de gouvernance des outils d'agent plus larges