La passerelle MCP devient une infrastructure indispensable aux agents IA

Rédaction YuSMP Group Équipe éditoriale, YuSMP Group

L’essentiel

Qu'a lancé Snowflake exactement ?

Lors de la conférence de sécurité Black Hat 2026, Snowflake a présenté le Cortex AI Gateway, décrit comme une couche de contrôle centralisée qui encadre l'accès des agents IA aux modèles, aux données, aux serveurs MCP et aux outils de l'entreprise. Point essentiel : il ne se limite pas aux agents de Snowflake, il est conçu pour gouverner aussi des écosystèmes tiers depuis un seul endroit – Amazon Bedrock, Azure AI Foundry, ChatGPT, Claude Code, Cursor et des applications sur mesure bâties avec LangChain ou LlamaIndex. Les fonctions annoncées comprennent des autorisations et un contrôle d'accès fins, des pistes d'audit des actions des agents en temps réel, la prise en charge de plus de 100 serveurs MCP, la détection et la surveillance automatiques de l'« IA fantôme », ainsi qu'un routage des coûts avec plafonds budgétaires. La plupart des fonctions arrivent en préversion privée ; l'identité des agents et une portée de session restreinte sont annoncées comme disponibles ou imminentes.

La technologie vient d'une acquisition. Snowflake a construit la passerelle sur celle de Natoma, start-up spécialisée dans les passerelles MCP centralisées rachetée en mai 2026, dont la raison d'être était justement d'appliquer identité, politiques et audit au niveau de l'appel d'outil. Le cadrage de Mayank Upadhyay, Chief Security and Trust Officer de Snowflake, est révélateur : selon lui, l'IA d'entreprise passe de l'interopérabilité des données à l'interopérabilité des agents, et la sécurité doit être au cœur de ce changement. Autrement dit, le problème difficile n'est plus de faire partager des données aux systèmes, mais de faire agir des agents autonomes à travers ces systèmes en toute sécurité. Quiconque développe de véritables systèmes d'agents IA connaît ce basculement : dès qu'un agent peut agir au lieu de simplement répondre, le contrôle d'accès cesse d'être un détail et devient l'enjeu principal.

Pourquoi un agent a-t-il besoin d'une passerelle ?

Pour comprendre en quoi il s'agit de plus qu'une annonce produit, regardons comment la plupart des équipes branchent leurs premiers agents. Chaque agent reçoit des identifiants et se connecte directement aux outils dont il a besoin : une base de données, une API interne, une application SaaS, un ou deux serveurs MCP. En démo, cela fonctionne. En matière de gouvernance, cela ne tient plus dès qu'une douzaine d'agents tournent, car chacune de ces connexions directes est un chemin distinct avec ses propres clés, son propre rayon d'impact et souvent aucun journal central. Demandez « quel agent a lu la table clients cette nuit, et en avait-il le droit ? » : bien souvent, personne ne peut répondre clairement.

Une passerelle inverse la logique. Au lieu que les agents détiennent des identifiants et appellent directement les outils, chaque appel passe par un point de contrôle unique qui vérifie trois choses à chaque requête : qui a demandé l'action, de quels droits il dispose et si l'action est autorisée – puis l'enregistre. C'est ce goulet unique qui rend possibles le moindre privilège, la révocation propre, l'audit en temps réel et les plafonds de dépenses. C'est aussi lui qui révèle l'IA fantôme : les agents et intégrations non autorisés, mis en place discrètement, qu'on ne peut pas gouverner faute de les voir. Le modèle de la passerelle reprend volontairement une idée que le secteur accepte déjà pour les API et l'identité – une porte d'entrée qui applique des politiques – transposée à une nouvelle réalité : les appelants sont désormais des agents semi-autonomes, et non des applications pilotées par des humains.

Pourquoi est-ce une tendance de fond et pas un simple produit ?

Ce qui fait de ce lancement un changement d'architecture plutôt qu'un titre sur Snowflake, c'est le calendrier. Le Cortex AI Gateway n'est pas arrivé seul : les analystes ont relevé une concentration d'opérations autour de l'identité des agents sur la même période, dont le rachat d'Oasis par Cyera pour environ 1 milliard de dollars et le rachat de Permiso par Okta, tandis que Snowflake présentait autour de son lancement une liste de partenaires identité – 1Password, Aembit, Cyera, Okta, SailPoint, Saviynt et d'autres. Quand plusieurs grands éditeurs investissent la même capacité en quelques jours, c'est généralement qu'une catégorie se cristallise, pas qu'une entreprise a eu une idée astucieuse.

Ce qui se cristallise, c'est la passerelle MCP comme couche horizontale. Il y a un an, on parlait surtout du Model Context Protocol comme d'un moyen de relier un agent à des outils. Le débat est monté d'un cran : puisque les agents seront connectés à de nombreux outils, qui se place au milieu pour faire respecter identité, politiques, audit et coûts ? Cette couche intermédiaire, c'est la passerelle, et elle ressemble de moins en moins à un produit de sécurité optionnel et de plus en plus à l'équivalent d'une passerelle d'API ou d'un fournisseur d'identité : une infrastructure que l'on suppose présente dans tout déploiement sérieux d'agents. C'est pourquoi la leçon vaut même si vous n'utilisez jamais Snowflake : la forme de la pile se stabilise, et la gouvernance y figure comme une brique à part entière.

Qu'est-ce que cela change pour les équipes logicielles en France et en Europe ?

Première conséquence : la gouvernance des agents se décide à la conception, ce n'est pas un chantier de nettoyage. Ajouter après coup identité et audit à des agents qui touchent déjà aux données de production est pénible et rarement complet. Les équipes qui intègrent tôt le modèle de la passerelle – une identité restreinte par agent, des appels d'outils routés vers un point de politique unique, une journalisation intégrale – obtiennent la gouvernance presque gratuitement ; celles qui repoussent héritent d'un maillage de connexions directes intraçable et coûteux à démêler.

Deuxième conséquence : cela recoupe directement des obligations de conformité que vous portez déjà. Une piste d'audit en temps réel au niveau de l'appel d'outil est précisément la preuve qu'attendent les auditeurs SOC 2, ainsi que les exigences de DORA et de l'AI Act européen, qui demandent de plus en plus de montrer qui ou quoi a accédé aux données et si l'action était autorisée. Pour les projets réglementés en FinTech et en e-santé, un agent capable de lire des données réglementées sans identité gouvernée et révocable est une faille de contrôle, pas une commodité. La passerelle transforme l'affirmation « nos agents sont maîtrisés » en élément de preuve.

Troisième conséquence, un point de coût facile à sous-estimer : les agents peuvent dépenser vite. Un agent qui relance ses appels, multiplie les sous-agents ou boucle sur une tâche difficile peut faire grimper les factures de jetons et d'outils sans aucun humain dans le circuit de validation. Plafonds budgétaires et routage des coûts au niveau de la passerelle font la différence entre une alerte et une mauvaise surprise sur la facture. Que vous construisiez votre couche de contrôle en interne ou que vous l'achetiez, la gouvernance visée reste la même : identité, politiques, audit et limites de dépenses, appliqués en un seul endroit dont votre équipe plateforme et DevOps a réellement la charge.

Que faire dès maintenant ?

Inutile d'adopter une passerelle précise ce trimestre. Il faut en revanche cesser de considérer la gouvernance des agents comme une chose à « ajouter plus tard ». Voici la version opérationnelle.

1. Recensez vos agents et intégrations. Listez chaque agent et chaque connexion à un outil, y compris les non officiels : on ne gouverne pas une IA fantôme que l'on ne voit pas.
2. Donnez à chaque agent sa propre identité. Remplacez les clés partagées par des identités restreintes au moindre privilège, par agent, pour que chaque accès soit attribuable et révocable.
3. Faites passer les appels d'outils par un point de contrôle unique. Même une passerelle interne légère vaut mieux qu'une douzaine de connexions directes ; chaque action doit transiter par un endroit capable de l'autoriser, de la refuser et de la journaliser.
4. Activez l'audit et traitez-le comme une preuve de conformité. Conservez des journaux au niveau de l'appel d'outil et rattachez-les dès maintenant à vos obligations SOC 2, DORA, RGPD et AI Act, pas le jour de l'audit.
5. Ajoutez des plafonds de dépenses. Fixez des budgets et des alertes par agent, pour qu'un agent qui boucle déclenche une limite plutôt qu'une facture inattendue.
6. Intégrez-la dès la conception des nouveaux projets. Si vous démarrez, placez la couche de gouvernance dans l'architecture dès le départ ; la rajouter ensuite coûte bien plus cher.

Rien de tout cela n'est un verdict sur le Cortex AI Gateway en particulier ; c'est une mise en œuvre solide d'un modèle qui devient rapidement la norme. L'enseignement durable est architectural : à mesure que les agents passent de la réponse à l'action, la porte d'entrée gouvernée placée devant eux devient une infrastructure – et les équipes qui l'intègrent dès maintenant à leur conception auront beaucoup moins d'efforts à fournir pour prouver leur maîtrise plus tard.

Questions fréquentes

Sources

Snowflake — Enterprise AI security and agentic MCP governance with Cortex AI Gateway
VentureBeat — Snowflake launches Cortex AI Gateway to control AI agents and prevent runaway enterprise costs
Yahoo Tech — Snowflake's Cortex AI Gateway signals MCP gateways are crystallizing as infrastructure
Cybersecurity Magazine — Snowflake launches Cortex AI Gateway to govern agentic AI