Gouvernance MCP d'entreprise : Comment contrôler, auditer et sécuriser l'accès aux serveurs MCP à grande échelle

Demandez à votre équipe de sécurité combien de serveurs MCP sont en cours d'exécution dans votre organisation en ce moment. S'ils peuvent répondre avec confiance, vous avez une longueur d'avance sur la plupart des entreprises. S'ils ne le peuvent pas, vous avez un problème de gouvernance qui est déjà en production.

L'adoption du MCP a été rapide. Les équipes ont connecté des agents à GitHub, Slack, des bases de données internes et des API tierces via des serveurs MCP, souvent sans examen informatique, sans politique de gestion des identifiants et sans aucun moyen pour l'équipe de sécurité de voir à quoi ces serveurs pouvaient accéder. Le protocole est utile précisément parce qu'il facilite les connexions d'outils. Cette facilité est aussi ce qui fait des déploiements MCP non gouvernés une réelle exposition à la sécurité.

Les serveurs MCP ne sont pas des API passives. Ils donnent aux agents d'IA un accès direct et programmatique aux systèmes sensibles. Ces agents agissent sur la base d'un raisonnement autonome, et non de chemins de code examinés. Comme l'a dit un responsable de la sécurité d'entreprise chez Medtronic : « Le MCP ouvre de nombreuses opportunités de causer beaucoup de dégâts très rapidement. » Gartner prévoit que 70 % des équipes d'ingénierie logicielle développant des applications multimodales utiliseront des passerelles d'IA d'ici 2028, contre 25 % en 2025. Les équipes qui mettent en place la gouvernance maintenant sont celles qui pourront évoluer en toute sécurité.

Ce guide couvre ce que la gouvernance MCP d'entreprise exige, pourquoi les outils de sécurité standard sont insuffisants, comment construire le cadre à quatre piliers sur lequel les équipes de conformité peuvent s'appuyer, et comment TrueFoundry met tout cela en œuvre dans votre propre cloud.

Ce que la gouvernance MCP d'entreprise exige

La gouvernance MCP d'entreprise est le cadre opérationnel complet pour gérer quels serveurs MCP existent dans votre organisation, qui peut y accéder, ce qu'ils sont autorisés à faire, et ce qui est enregistré lorsqu'ils sont utilisés. Ce n'est pas un document de politique. C'est une infrastructure appliquée.

La plupart des équipes sous-estiment la portée. La gouvernance couvre chaque serveur MCP dans l'environnement : les outils tiers connectés par les développeurs sans examen informatique, les outils internes construits et déployés par les équipes produit, et les serveurs MCP intégrés dans les configurations d'IDE dans Cursor, Claude Code et des outils similaires. Si un serveur MCP peut atteindre un système de production, il est inclus dans le périmètre.

La gouvernance MCP est également différente de la gouvernance API standard d'une manière qui est importante pour la façon dont vous la construisez. Un appel d'API REST exécute un chemin de code déterministe qu'un développeur a écrit et examiné. L'invocation d'un outil MCP est une décision autonome prise par un agent d'IA à l'exécution, basée sur son raisonnement. Le modèle de menace, les exigences d'audit et les contrôles nécessaires pour maintenir la responsabilité sont tous différents. Traiter le MCP comme une intégration d'API conventionnelle est la façon dont les organisations se retrouvent avec des lacunes d'audit qu'elles ne peuvent pas expliquer à un régulateur.

• Périmètre : Tous les serveurs MCP. Cela inclut les serveurs internes construits par les équipes produit, les serveurs exécutés dans les pipelines CI/CD, et tout ce qu'un développeur a configuré localement dans son IDE.

• Mécanisme : Une passerelle centralisée entre tous les clients et tous les serveurs MCP. La passerelle applique les politiques. Les serveurs MCP individuels n'implémentent pas leurs propres contrôles d'accès, ce qui rend cette approche évolutive sur des centaines de serveurs.

• Résultat : Chaque invocation d'outil est autorisée par rapport à une identité vérifiée et enregistrée dans un format structuré et interrogeable qui résiste à l'examen de conformité et à l'enquête sur les incidents.

Risques de sécurité MCP que les entreprises ne peuvent ignorer

Les serveurs MCP opèrent au sein de la boucle de raisonnement d'un agent d'IA. Un appel d'API traditionnel est déclenché de manière déterministe par le code de l'application. Une invocation d'outil MCP, en revanche, est déclenchée lorsqu'un agent détermine à l'exécution qu'un outil est approprié pour une tâche donnée. Cette décision est influencée par le raisonnement du modèle plutôt que par un flux de contrôle explicitement défini, ce qui réduit la visibilité que les développeurs ont généralement sur la manière et la raison pour lesquelles un outil est invoqué. Dans ce modèle, le raisonnement fait effectivement partie du chemin de contrôle, mais il n'est pas directement observable via les outils de sécurité d'application standard.

Les chercheurs en sécurité ont documenté cela en production. Les attaques par injection de prompt, délivrées via les descriptions d'outils MCP, redirigent le comportement de l'agent sans toucher une ligne de code. L'exposition des identifiants via des serveurs MCP mal configurés crée des chemins d'accès que les contrôles périmétriques n'ont jamais été conçus pour surveiller. Ce ne sont pas des scénarios d'attaque théoriques issus de documents de recherche. Ce sont des incidents documentés provenant de déploiements d'entreprise réels.

Les déploiements de serveurs MCP fantômes peuvent contourner le contrôle d'accès standard

Lorsque les développeurs déploient des serveurs MCP ou s'y connectent sans examen par l'IT, ils contournent tous les contrôles qui s'appliquent normalement à une nouvelle intégration de système : évaluation de la sécurité des fournisseurs, classification de l'accès aux données et flux de travail de provisionnement d'accès. Le serveur entre en production sans aucune de la documentation, de la surveillance ou des restrictions que tout autre système d'entreprise comporte.

Sans registre centralisé, les questions de sécurité fondamentales n'ont pas de réponses fiables. Quels serveurs MCP sont en cours d'exécution ? Quels identifiants détiennent-ils ? Quelles bases de données peuvent-ils interroger ? Quels services externes peuvent-ils appeler ? Cette invisibilité exclut totalement ces serveurs des évaluations des vulnérabilités, des examens des risques fournisseurs et du périmètre des tests d'intrusion.

Un seul serveur MCP non approuvé avec un accès en lecture à un CRM interne ou à un dépôt de code est un chemin de données non audité que les contrôles périmétriques ne détecteront pas. Le trafic provient de l'intérieur du réseau, d'une machine de développeur qui est censée s'y trouver.

L'empoisonnement des descriptions d'outils contourne les défenses de la couche réseau

Lorsqu'un agent se connecte à un serveur MCP et appelle tools/list, le serveur répond avec les noms d'outils, leurs descriptions et les schémas de paramètres. L'agent utilise ces métadonnées pour décider quels outils invoquer et comment les appeler. Manipulez ces métadonnées et vous redirigerez le comportement de l'agent sans exploiter la moindre vulnérabilité de code.

L'empoisonnement des descriptions d'outils intègre des instructions malveillantes dans les métadonnées des outils qui amènent l'agent à effectuer des actions non intentionnelles : exfiltration de données, invocation d'outils en dehors de son périmètre prévu, ou contournement des contrôles de sécurité tout en semblant exécuter sa tâche assignée. Le contenu malveillant transite dans le corps de la réponse HTTP du serveur MCP, spécifiquement dans la charge utile tools/list. Les pare-feu d'applications web standard et les outils de sécurité API ont une visibilité sur les corps de réponse HTTP, mais ils ne peuvent pas détecter cette attaque car le contenu malveillant est un langage naturel sémantiquement intégré, et non une anomalie syntaxique comme une signature d'exploit connue ou un en-tête malformé. L'attaque réussit au niveau de la couche de raisonnement, où l'agent interprète les descriptions d'outils comme des instructions légitimes et agit en conséquence.

Les garde-fous MCP Pre Tool de TrueFoundry inspectent les paramètres d'outils et les arguments d'appel avant l'exécution en utilisant la détection d'injection de prompt basée sur un modèle. Si les arguments d'appel d'outil contiennent des instructions redirigées, l'exécution est bloquée avant que l'outil ne s'exécute et la détection est enregistrée dans la trace de la requête.

Les identifiants de serveur MCP partagés éliminent la responsabilité en matière de conformité

Les serveurs MCP utilisant des clés API partagées ou des jetons de compte de service ne peuvent pas produire les enregistrements d'audit attribuables que les cadres de conformité exigent. Si dix agents partagent un ensemble d'identifiants, il n'y a aucun moyen de lier un appel d'outil spécifique à un utilisateur, une instance d'agent ou une équipe spécifique. Dans un environnement réglementé, cette lacune n'est pas un inconvénient. C'est un manquement direct à la conformité.

La HIPAA exige des pistes d'audit attribuables à un utilisateur ou un service identifiable pour chaque accès aux informations de santé protégées. SOC2 CC6 exige des contrôles d'accès avec preuve de leur application. Le principe de responsabilité du RGPD exige des organisations qu'elles démontrent que le traitement des données a été autorisé et documenté. Les déploiements MCP à identifiants partagés ne peuvent satisfaire aucune de ces exigences. TrueFoundry remplace les identifiants partagés par des jetons d'accès personnels (PAT) liés à des utilisateurs individuels et des jetons de compte virtuel (VAT) pour l'accès au niveau de l'application, ainsi chaque appel d'outil porte une identité vérifiable.

Les quatre piliers de la gouvernance MCP d'entreprise

Un cadre complet de gouvernance MCP d'entreprise nécessite quatre capacités qui fonctionnent ensemble : un catalogue centralisé, des contrôles d'accès basés sur l'identité, une journalisation d'audit structurée et une application des politiques en temps réel. Chacune dépend des autres. Vous ne pouvez pas appliquer de politiques d'accès avant de savoir quels serveurs existent. Vous ne pouvez pas construire une piste d'audit sans attribution d'identité. Et les journaux d'audit post-mortem sans application en temps réel sont des enregistrements forensiques, pas des contrôles de sécurité.

Quatre piliers : Fonctionnalité principale, implémentation TrueFoundry et couverture de conformité

Pilier 1 : Un catalogue centralisé de serveurs MCP

Le catalogue est le registre faisant autorité de chaque serveur MCP approuvé dans votre organisation. Chaque entrée contient les informations dont les équipes de sécurité ont besoin pour évaluer les risques : nom du serveur, équipe propriétaire, périmètre d'accès aux données, méthode d'authentification, statut d'approbation, paramètres de connexion et toutes restrictions d'utilisation telles que les groupes d'utilisateurs approuvés ou les limites de débit.

Les nouveaux serveurs passent par un flux de travail de validation. L'examen des descriptions d'outils détecte les risques d'empoisonnement avant que le serveur n'atteigne les environnements de développement. L'évaluation de l'accès aux données détermine ce que le serveur peut atteindre. Une approbation explicite autorise la distribution. Rien de tout cela ne nécessite de modifications du serveur MCP lui-même. Cela se passe au niveau de la couche du catalogue, et les implémentations individuelles des serveurs restent inchangées.

Le catalogue gère également la distribution. Les développeurs intègrent directement les configurations de serveurs pré-approuvées dans leurs intégrations IDE plutôt que de configurer les serveurs manuellement. Seuls les serveurs approuvés par le catalogue atteignent les machines des développeurs. La fonctionnalité de serveur MCP virtuel de TrueFoundry étend cela : les équipes de plateforme composent des sous-ensembles d'outils sélectionnés à partir de plusieurs serveurs enregistrés, n'exposant que ce qu'une équipe ou un cas d'utilisation spécifique requiert, sans déployer de nouvelle infrastructure.

Pilier 2 : SSO et contrôle d'accès aux serveurs MCP au niveau de la couche passerelle

L'accès MCP doit passer par le même fournisseur d'identité qui régit tout le reste dans l'organisation. TrueFoundry prend en charge les flux OAuth2 à deux et trois étapes, SAML 2.0, et l'intégration directe avec Okta, Azure Active Directory, Auth0, Cognito, et tout IdP compatible JWKS. L'accès MCP est provisionné et déprovisionné via les mêmes flux de travail d'intégration et de désintégration qui couvrent les e-mails, les dépôts et les consoles cloud. Lorsqu'un développeur quitte l'entreprise, l'accès MCP est automatiquement révoqué.

La passerelle prend en charge trois méthodes d'authentification entrantes selon l'appelant. Les jetons d'accès personnels (PAT) sont générés depuis Paramètres > Clés API dans l'interface utilisateur de TrueFoundry, sont liés à des utilisateurs individuels et constituent le choix standard pour les flux de travail de développement. Les jetons de compte virtuel (VAT) sont des comptes de service avec des permissions définies, appropriés pour les agents de production et les flux de travail de serveur à serveur. Les jetons IdP externes permettent aux utilisateurs sans compte TrueFoundry de s'authentifier en utilisant leur propre fournisseur d'identité, couvrant les déploiements SaaS B2B et les agents orientés client.

Pour l'authentification sortante vers les serveurs MCP en aval, TrueFoundry gère le cycle de vie complet des identifiants selon six modèles. Les flux de code d'autorisation OAuth gèrent l'accès par utilisateur à des services comme GitHub et Slack, la passerelle gérant le consentement, le stockage des jetons et le rafraîchissement automatique. Les flux d'identifiants client OAuth gèrent l'accès de serveur à serveur. Les modes de clés API partagées et individuelles couvrent les cas plus simples où la passerelle injecte l'identifiant approprié par requête. La transmission directe du jeton (Token Passthrough) transmet le jeton entrant sans modification lorsque le serveur MCP peut le valider directement. La transmission du jeton via l'en-tête x-tfy-mcp-headers gère les scénarios où le serveur MCP utilise un système d'identifiants distinct.

Contrôle d'accès aux serveurs MCP : Modèles d'authentification dans les scénarios d'entreprise courants

Les politiques RBAC déterminent quelles équipes ou quels individus peuvent invoquer quels serveurs et outils. Ces politiques résident au niveau de la passerelle, et non au sein des serveurs MCP individuels, de sorte qu'une mise à jour de politique prend effet immédiatement pour tous les clients sans redéploiement de serveur. Une équipe de science des données a accès aux outils d'analyse mais pas aux serveurs de déploiement. Une équipe de sécurité obtient un accès en lecture seule à tous les serveurs à des fins d'audit.

Pilier 3 : Journalisation d'audit structurée liée à chaque appel d'outil

Chaque appel d'outil MCP nécessite une entrée de journal qui capture le contexte d'invocation complet : horodatage, identité de l'appelant, identifiant du serveur MCP, nom de l'outil, paramètres d'entrée, résumé de la réponse, décision de politique avec motif, résultats des garde-fous par hook montrant le temps d'exécution et les découvertes, et latence totale. Ces champs doivent être au format JSON structuré afin que les systèmes SIEM et les outils de reporting de conformité puissent les interroger.

TrueFoundry contrôle la journalisation à deux niveaux. Au niveau de la requête, l'en-tête X-TFY-LOGGING-CONFIG avec enabled: true capture la requête complète. Au niveau de la passerelle sur les déploiements auto-hébergés, la variable d'environnement REQUEST_LOGGING_MODE définit le comportement global : ALWAYS journalise chaque requête quels que soient les en-têtes, ce qui est le bon réglage pour les environnements de production réglementés. HEADER_CONTROLLED s'appuie sur les paramètres par requête. NEVER supprime toute journalisation pour les environnements où cela est approprié.

Les journaux de requêtes sont visibles dans l'interface utilisateur de TrueFoundry sous AI Gateway > Monitor > Requests. Les étendues d'exécution individuelles des garde-fous apparaissent dans AI Gateway > Monitor > Request Traces, montrant quels garde-fous ont été exécutés sur quel hook, leur statut de réussite/échec, le temps d'exécution et les mutations appliquées. Pour les organisations acheminant les journaux vers leur propre infrastructure, TrueFoundry exporte via OpenTelemetry vers Grafana, Datadog, Splunk et toute destination compatible OTLP. Sur les déploiements auto-hébergés, les données de journal sont écrites dans votre propre stockage AWS S3, GCS ou Azure Blob au format Parquet, interrogeables via Spark, DuckDB ou Athena.

La HIPAA exige la conservation de la documentation liée à la sécurité pendant six ans. En pratique, les journaux d'audit sont souvent conservés pendant une durée similaire pour soutenir la conformité et l'enquête sur les incidents. De nombreux dossiers financiers suivent une norme de conservation de sept ans. Les journaux doivent être infalsifiables, avec des contrôles d'accès qui empêchent leur modification par les équipes qui les génèrent. Les options de déploiement auto-hébergé de TrueFoundry conservent toutes les données de journal au sein du compte cloud du client, prenant en charge les exigences de conservation et d'infalsifiabilité.

Pilier 4 : Application des politiques MCP en temps réel avant l'exécution de l'outil

Journaliser ce qui s'est passé n'est pas la même chose que l'empêcher. L'application des politiques doit agir au moment de l'invocation, avant que l'appel de l'outil n'atteigne le serveur MCP, afin que l'accès non autorisé soit bloqué plutôt que documenté après coup.

Le système de garde-fous de TrueFoundry implémente deux hooks par appel d'outil. Les garde-fous MCP Pre Tool s'exécutent avant l'exécution de l'outil. Si l'un d'eux échoue, l'outil ne s'exécute jamais, évitant entièrement le coût, les effets secondaires et l'exposition des données d'un mauvais appel. Les garde-fous pré-outil intégrés incluent : SQL Sanitizer, détectant les commandes DROP, TRUNCATE, DELETE et UPDATE sans clause WHERE, et les modèles d'interpolation de chaînes indiquant un risque d'injection ; la détection d'injection de prompt utilisant une analyse basée sur un modèle pour les tentatives de jailbreak et d'injection dans les paramètres d'appel d'outil ; la détection de secrets, interceptant les clés API, les identifiants AWS, les jetons JWT et les clés privées avant qu'ils n'atteignent les services backend ; et les garde-fous de politique Cedar et OPA pour un contrôle d'accès déclaratif et granulaire jusqu'aux arguments spécifiques de l'outil.

Les garde-fous MCP Post Tool s'exécutent après le retour de l'outil, avant que le résultat n'atteigne l'agent. Les garde-fous post-outil intégrés incluent : Code Safety Linter, signalant les appels eval, exec, os.system, subprocess et les commandes shell dangereuses dans la sortie de l'outil ; la détection des informations personnelles identifiables (PII), trouvant et masquant les informations personnelles avec des catégories d'entités configurables ; et la correspondance de motifs Regex pour les modèles personnalisés couvrant les cartes de paiement, les identifiants internes et les données sensibles spécifiques au domaine. Les fournisseurs externes, y compris AWS Bedrock Guardrail, Azure Content Safety, Azure Prompt Shield, CrowdStrike et Google Model Armor, s'intègrent tous via le même système de hooks.

Les stratégies d'application sont configurables par garde-fou. "Enforce" bloque en cas de violation et d'erreur de garde-fou. "Enforce But Ignore On Error" bloque en cas de violation mais laisse passer les requêtes si le fournisseur de garde-fou est indisponible, ce qui est le comportement par défaut recommandé pour la production. "Audit" journalise les violations sans bloquer, le mode approprié lors du déploiement initial. La séquence recommandée est "Audit" d'abord, puis "Enforce But Ignore On Error", puis "Enforce" complet à mesure que la confiance augmente.

Déploiement d'une passerelle MCP d'entreprise : Un plan de mise en œuvre en quatre étapes

La gouvernance MCP est un programme séquencé. Chaque étape s'appuie sur la précédente. Vous ne pouvez pas appliquer de politiques d'accès avant de savoir quels serveurs existent. Vous ne pouvez pas construire une piste d'audit significative avant que l'attribution d'identité ne soit en place.

Étape 1 : Inventorier tous les déploiements MCP existants

Commencez par un audit complet de chaque serveur MCP en cours d'exécution dans les environnements de développement, les pipelines CI/CD, les déploiements d'agents de production et les configurations d'IDE. Cela inclut les serveurs configurés localement par les développeurs dans Cursor ou Claude Code sans implication informatique. La combinaison de l'analyse automatisée des environnements cloud avec un processus d'auto-déclaration pour les configurations de développeurs locaux offre l'image la plus complète pour les grandes organisations.

Enregistrez pour chaque serveur : nom et objectif, équipe propriétaire, portée d'accès aux données, méthode d'authentification le cas échéant, et durée de fonctionnement. L'objectif est d'obtenir une image précise de ce qui existe avant la mise en place de la gouvernance, et non une liste organisée de choses déjà approuvées.

Étape 2 : Construire le catalogue de serveurs MCP approuvés

Avant de migrer des serveurs, définissez le schéma de métadonnées et le flux de travail d'approbation. Décisions clés : qui a l'autorité d'approbation pour les différents niveaux de risque, ce que couvre la liste de contrôle d'examen, et quelles constatations bloquent l'enregistrement au catalogue. Établissez ces critères avant de catégoriser les serveurs afin qu'ils s'appliquent de manière cohérente.

Parcourez l'inventaire et classez chaque serveur comme approuvé pour le catalogue, en attente de révision ou bloqué en attente de correction. Fixez une date butoir à laquelle tous les serveurs de production doivent être enregistrés dans le catalogue et communiquez clairement que les serveurs non catalogués seront bloqués au niveau de la passerelle après cette date. La date limite crée l'urgence qui pousse les équipes à s'impliquer.

Étape 3 : Déployer la passerelle MCP et appliquer le SSO

Acheminez tout le trafic MCP via la passerelle avant d'appliquer les politiques de blocage. Commencez avec REQUEST_LOGGING_MODE défini sur ALWAYS. Tout le trafic passe, toutes les invocations sont enregistrées, rien n'est encore bloqué. L'exécution dans ce mode pendant deux à quatre semaines vous donne une base de référence des modèles de trafic réels avant le début de l'application.

Intégrez la passerelle à votre IdP d'entreprise via Accès > Authentification externe > Fournisseur d'identité dans l'interface utilisateur de TrueFoundry. Pour Okta utilisant le serveur d'autorisation par défaut, l'URI JWKS est https://your-org.okta.com/oauth2/v1/keys. Les organisations utilisant un serveur d'autorisation Okta personnalisé doivent utiliser https://your-org.okta.com/oauth2/{authServerId}/v1/keys à la place. Pour Azure AD, c'est https://login.microsoftonline.com/your-tenant-id/discovery/v2.0/keys, avec l'ID de locataire et l'ID client configurés comme émetteur et audience. Vérifiez que chaque invocation dans le journal d'audit affiche une identité d'utilisateur ou d'agent spécifique avant de passer à l'application. Les identités de comptes de service partagés dans les journaux signifient que l'attribution d'identité est incomplète.

Étape 4 : Activer l'application et configurer les alertes

Après la période de référence, activez l'application des politiques : bloquez les serveurs MCP non catalogués, activez les politiques RBAC et appliquez des limites de débit. Communiquez la date d'application aux équipes de développement avec suffisamment de préavis pour accélérer l'enregistrement des outils légitimes dans le catalogue.

Configurez des alertes sur les données OpenTelemetry exportées pour les modèles anormaux : volumes d'appels inhabituels provenant d'une seule identité d'agent, accès à des outils hautement sensibles en dehors des heures approuvées, violations de politique par des identités qui ne devraient pas avoir accès au MCP. Les résultats du garde-fou dans Passerelle IA > Moniteur > Traces de requêtes vous donnent les détails nécessaires pour ajuster les seuils au fil du temps. Examinez les règles d'alerte trimestriellement à mesure que votre déploiement MCP se développe.

Exigences de sécurité MCP pour les entreprises par secteur d'activité

Trois exigences apparaissent constamment dans tous les environnements réglementés : des enregistrements d'accès attribuables liés à des identités vérifiées, des contrôles de résidence des données maintenant les données sensibles dans des limites définies, et une documentation sur les risques liés aux fournisseurs pour l'infrastructure de gouvernance elle-même.

• Santé (HIPAA) : Tout serveur MCP pouvant recevoir des informations de santé protégées dans les paramètres ou les réponses nécessite une passerelle isolée par VPC. Les invocations d'outils impliquant des PHI nécessitent des journaux avec les identifiants de patient remplacés par des jetons de référence, et l'accès doit être provisionné via la gestion des identités cliniques. Le déploiement auto-hébergé de TrueFoundry sur AWS GovCloud prend en charge les charges de travail conformes à la HIPAA. Innovaccer traite environ 17 millions de requêtes d'inférence d'IA clinique par mois entièrement au sein de leur périmètre AWS GovCloud en utilisant TrueFoundry, avec OpenTelemetry alimentant les tableaux de bord Grafana et aucune donnée sensible ne quittant leur périmètre cloud.

• Services financiers (SOC2, FINRA) : L'infrastructure de gouvernance MCP est soumise aux audits SOC2 Type II si elle traite des données financières ou a accès à des systèmes d'enregistrement. Les contrôles requis incluent le chiffrement en transit et au repos, des revues d'accès trimestrielles avec preuves documentées, et des procédures de réponse aux incidents couvrant les modes de défaillance spécifiques au MCP. TrueFoundry détient la certification SOC2 Type II et exporte des journaux d'audit MCP structurés dans le format requis par les auditeurs pour produire des preuves de contrôle CC6.

• Assurances et entreprises mondiales (RGPD, Résidence des données) : Les organisations couvertes par le RGPD doivent tenir un Registre des activités de traitement en vertu de l'article 30 qui couvre le traitement assisté par l'IA, y compris les invocations d'outils MCP. Ce registre est un document de conformité structuré décrivant les finalités du traitement, les catégories de données, les transferts et les garanties. Les journaux d'audit de la passerelle MCP fournissent les données d'événements sous-jacentes qui alimentent ce registre, mais le RoPA lui-même doit être tenu séparément par la fonction de protection des données de l'organisation. Les journaux de la passerelle doivent également capturer suffisamment de métadonnées pour prendre en charge les demandes d'accès des personnes concernées et pour documenter tout transfert transfrontalier qui se produit via les invocations d'outils. Les exigences de résidence des données peuvent interdire au trafic MCP de quitter des régions géographiques spécifiques, nécessitant des déploiements de passerelles régionales.

Comment TrueFoundry assure la gouvernance MCP d'entreprise

La passerelle MCP de TrueFoundry offre les quatre piliers de la gouvernance à partir d'un plan de contrôle unique déployé au sein du propre compte cloud du client. Les équipes de plateforme gèrent l'ensemble de la pile de gouvernance via une seule interface sans modifier les implémentations individuelles des serveurs MCP. Aucun trafic MCP ne quitte le périmètre de l'entreprise.

Des entreprises telles que NVIDIA, Zscaler, Siemens Healthineers et Automation Anywhere utilisent TrueFoundry pour passer de déploiements MCP ad hoc à des environnements contrôlés et gouvernés. Pour les entreprises exécutant des charges de travail d'agents IA à grande échelle, les contrôles de coûts appliqués par politique, les limites budgétaires et la couche de mise en cache de TrueFoundry ont permis des réductions significatives des dépenses mensuelles d'inférence et d'invocation d'outils. Contactez TrueFoundry pour obtenir des chiffres spécifiques à votre cas, basés sur votre volume d'invocation réel et votre mix de modèles.

• Catalogue MCP centralisé avec flux de travail de validation : Le plan de contrôle TrueFoundry maintient le registre faisant autorité des serveurs MCP approuvés avec les métadonnées, le statut d'approbation et les paramètres de connexion. Les nouveaux serveurs passent par un processus de validation qui inclut l'examen de la description de l'outil pour les risques d'empoisonnement avant leur distribution aux configurations d'IDE des développeurs. La fonctionnalité de serveur MCP virtuel permet aux équipes de plateforme de composer des sous-ensembles d'outils sélectionnés à partir de plusieurs serveurs enregistrés, n'exposant que ce dont une équipe spécifique a besoin sans déployer de nouvelle infrastructure.

• OAuth2 et RBAC sur chaque appel d'outil : Chaque invocation MCP est authentifiée via OAuth2 avec l'identité d'entreprise de l'appelant. La passerelle gère les six modèles d'authentification sortante et gère le cycle de vie complet des jetons pour les flux de code d'autorisation, les flux d'informations d'identification client et l'injection de clés API. Les politiques RBAC appliquées au niveau de la passerelle s'appliquent immédiatement à tous les clients lors des mises à jour, sans nécessiter de redéploiement de serveur.

• Politiques de métadonnées configurables par invocation : TrueFoundry applique le masquage des données via la détection des informations personnelles identifiables (PII) et les garde-fous Regex, des limites de débit par équipe, des plafonds de coûts par session d'agent et des règles de blocage pour les catégories d'outils restreintes via les politiques Cedar ou OPA. Le tout est configuré dans l'interface de gestion. Aucune modification du code du serveur MCP n'est requise.

• Journaux d'audit diffusés vers votre SIEM : Les journaux d'audit JSON structurés pour chaque invocation MCP sont exportés via OpenTelemetry vers Grafana, Datadog, Splunk ou toute destination compatible OTLP. Dans les déploiements auto-hébergés, les journaux sont écrits dans votre propre stockage AWS S3, GCS ou Azure Blob au format Parquet, interrogeables via Spark, DuckDB ou Athena. REQUEST_LOGGING_MODE: ALWAYS assure une capture complète pour les environnements réglementés.

• Déploiement isolé VPC avec quatre options : SaaS entièrement géré sans frais d'infrastructure supplémentaires ; passerelle SaaS avec stockage de données appartenant au client ; plan de passerelle auto-hébergé avec plan de contrôle TrueFoundry pour un coût d'infrastructure d'environ 600 $ par mois ; plan de contrôle entièrement auto-hébergé plus passerelle pour environ 800 $ à 1 000 $ par mois. Les deux dernières options garantissent qu'aucun trafic d'invocation MCP ne quitte votre périmètre pour atteindre l'infrastructure TrueFoundry.

‍