La passerelle Cortex AI de Snowflake met le contrôle des agents en jeu

Snowflake a fait son entrée dans google news après le lancement de Cortex AI Gateway, alors que les connexions Model Context Protocol semblaient jusque-là davantage relever des intégrations pour développeurs que de l’infrastructure d’entreprise. Annoncée le 28 juillet, la passerelle centralise les politiques d’accès, l’authentification, les journaux d’activité, le routage des modèles et les contrôles de consommation. Snowflake indique prendre en charge plus de 100 serveurs MCP.

Le changement majeur n’est pas un nouveau catalogue de connecteurs. Snowflake place une couche de contrôle entre les agents IA et les modèles, outils, données et applications auxquels ces agents peuvent accéder. Cette position rappelle le rôle que les passerelles API et les plateformes d’identité ont revendiqué lors des précédentes vagues d’adoption des logiciels d’entreprise.

Snowflake n’est pas seul. Databricks, Cloudflare, des fournisseurs de sécurité et des startups spécialisées développent des points de contrôle similaires. La compétition ne porte plus sur la question de savoir si Model Context Protocol bénéficiera d’un large soutien. Elle concerne désormais la plateforme qui gouvernera le trafic MCP lorsque les agents commenceront à effectuer des actions conséquentes.

Snowflake fait de Cortex AI Gateway un point de contrôle pour les agents

Cortex AI Gateway étend la frontière de gouvernance de Snowflake, des données stockées aux actions effectuées par les agents IA.

Snowflake présente le produit comme une passerelle centralisée destinée aux agents propriétaires et tiers. Le premier groupe comprend Snowflake CoWork et Snowflake CoCo. Le second inclut des agents de programmation externes tels que Claude Code et Cursor.

Model Context Protocol, ou MCP, est un protocole ouvert qui permet aux applications IA de découvrir et d’invoquer des outils externes via une interface cohérente. Un serveur MCP peut exposer une requête de base de données, une recherche documentaire, une action de messagerie ou une application métier comme outil appelable.

Le protocole réduit le travail d’intégration sur mesure nécessaire pour que les agents utilisent ces ressources. Il ne donne pas automatiquement à une entreprise un point unique pour approuver chaque connexion, surveiller chaque action ou attribuer chaque dépense.

Cortex AI Gateway est conçu pour combler ce manque opérationnel. Selon l’annonce de la passerelle, les organisations peuvent l’utiliser pour définir quels agents accèdent à des modèles, serveurs MCP, applications et outils particuliers.

Snowflake indique également que la passerelle crée un journal d’activité de bout en bout. Ce journal vise à montrer ce qu’un agent a fait, les systèmes qu’il a contactés et la séquence de ses actions.

C’est important, car une interaction avec un agent se termine rarement par une seule réponse de modèle. Un agent de programmation peut inspecter un dépôt, récupérer un ticket, modifier un fichier, exécuter un test et contacter un autre service. Chaque étape peut franchir une frontière de sécurité ou de responsabilité différente.

Une passerelle peut fournir un point de contrôle commun pour ces étapes. Elle peut authentifier l’appelant, évaluer les autorisations, enregistrer la requête et transmettre l’action approuvée à sa destination.

Snowflake ajoute des contrôles financiers à ce point de contrôle. L’entreprise affirme que Cortex AI Gateway peut attribuer la consommation IA à des équipes, agents ou charges de travail. Les administrateurs peuvent également fixer des limites de dépenses destinées à empêcher un agent de générer une utilisation non maîtrisée des modèles.

La passerelle promet en outre un routage des requêtes entre des modèles approuvés. Snowflake indique que les décisions de routage peuvent prendre en compte la qualité, la latence, la disponibilité et le coût de consommation. Le produit va donc au-delà d’un proxy MCP, car il gouverne également le trafic des modèles.

La prise en charge par Snowflake de plus de 100 serveurs MCP fournit une première mesure de l’étendue des connexions. Toutefois, ce nombre ne démontre ni l’adoption en production, ni la fiabilité, ni la qualité de la sécurité. La prise en charge peut décrire une compatibilité technique sans révéler combien de clients exploitent ces connexions dans des flux de travail importants.

Le lancement modifie néanmoins la posture de Snowflake. Cortex AI permettait déjà d’appeler des modèles et de créer des agents de données. Cortex AI Gateway cherche désormais à exercer une autorité sur des agents développés ailleurs, y compris ceux dont l’interface principale se trouve hors de Snowflake.

C’est le signal infrastructurel. Snowflake souhaite contrôler le chemin entre la requête d’un agent et une action d’entreprise, même lorsqu’il n’a pas créé cet agent.

Pourquoi Cortex AI Gateway a atteint Google News maintenant

Snowflake répond à un problème de gouvernance créé par le succès de MCP comme norme d’intégration.

MCP a commencé comme un moyen de rendre les connexions aux outils portables. Un développeur pouvait exposer une capacité une seule fois et permettre à plusieurs clients IA compatibles de l’utiliser. Ce modèle devient plus difficile à gérer lorsque des dizaines d’agents se connectent à des centaines d’outils répartis entre différentes équipes.

Le protocole lui-même définit les messages et les modèles d’interaction. Sa spécification d’autorisation fournit un cadre fondé sur les normes OAuth pour les serveurs distants restreints. Toutefois, la gouvernance d’entreprise va au-delà de l’autorisation de transport.

Une équipe de sécurité doit savoir quel humain ou service un agent représente. Elle doit décider si cette identité peut invoquer un outil particulier avec des paramètres précis. Elle peut également avoir besoin de règles d’approbation, de contrôles contre les fuites de données, de conservation des audits et de révocation d’urgence.

Les équipes financières font face à un problème parallèle. Un flux de travail peut invoquer plusieurs modèles et outils avant de renvoyer un résultat. La facturation cloud classique identifie le service consommé, mais elle peut ne pas expliquer quel agent a initié la chaîne ni quel service a bénéficié du résultat.

Ces problèmes créent un marché pour un intermédiaire. La passerelle voit le trafic avant qu’il n’atteigne les modèles ou les serveurs MCP. Cette visibilité lui permet d’appliquer des politiques et d’enregistrer les coûts plus près du point d’action.

Snowflake a préparé cette évolution avec Natoma. Le 27 mai, l’entreprise a signé un accord définitif pour acquérir cette société, qui avait développé une plateforme MCP d’entreprise pour les agents IA. Snowflake a indiqué que l’opération étendrait la gouvernance des actifs de données aux actions et interactions de l’IA.

L’acquisition de Natoma promettait également une bibliothèque vérifiée de serveurs MCP. Snowflake a spécifiquement identifié les e-mails, Slack et d’autres applications connectées comme des sources susceptibles d’enrichir les données déjà détenues dans sa plateforme.

Le court délai entre cet accord et l’annonce de Cortex AI Gateway montre la priorité stratégique. Snowflake intègre les capacités MCP acquises dans le récit plus large de sa plateforme, plutôt que de les conserver comme un produit de connecteurs isolé.

Ce calendrier suit également les travaux antérieurs de Snowflake sur la gouvernance de l’IA. Lors de son sommet de 2025, l’entreprise a décrit une AI Governance Gateway pour l’accès aux modèles, le suivi de l’utilisation, le contrôle basé sur les rôles et l’application des budgets. Elle a annoncé séparément la prise en charge des serveurs MCP pour Cortex Analyst et Cortex Search.

Cortex AI Gateway combine ces préoccupations auparavant adjacentes. Il gouverne la sélection des modèles, l’accès MCP, l’activité des agents et la consommation via un même plan de contrôle proposé.

Cette consolidation reflète l’évolution des agents d’entreprise. Un chatbot conventionnel produit du texte qu’un utilisateur peut examiner. Un agent peut récupérer des informations privées, appeler un système métier ou initier un changement avant que l’utilisateur n’en voie le résultat.

Ces capacités rendent l’accès aux outils aussi important que l’accès aux modèles. Une entreprise peut approuver un LLM tout en s’exposant via un connecteur au périmètre mal défini. Elle peut sécuriser chaque application tout en perdant la visibilité sur l’ensemble de la chaîne d’actions des agents.

Les intégrations de sécurité de Snowflake répondent à certaines parties de ce défi. Le groupe initial inclut 1Password, Aembit, Linx Security, Okta, SailPoint et Saviynt. Leur présence suggère que la gouvernance des identités et des accès des agents devient une préoccupation d’infrastructure partagée.

L’apparition de la passerelle dans les résultats de google news est donc liée à une évolution plus large. La connectivité MCP passe d’une commodité pour développeurs aux domaines des équipes d’identité, des opérations de sécurité, de la finance et de l’ingénierie des plateformes.

Snowflake et Databricks se disputent le même plan de contrôle

La compétition centrale oppose Snowflake et Databricks sur la question de savoir si la plateforme de données existante doit gouverner chaque requête de modèle et MCP.

Databricks a formulé une affirmation étroitement liée avec Unity AI Gateway. Sa documentation décrit le service comme une couche de gouvernance centrale pour les agents, les endpoints de modèles, les serveurs MCP et les outils de programmation.

Les similitudes sont directes. Les deux plateformes veulent acheminer le trafic IA, appliquer les autorisations, observer l’utilisation et gérer la consommation auprès de différents fournisseurs. Elles relient également cette couche d’exécution aux systèmes de gouvernance déjà utilisés pour les données d’entreprise.

Databricks place Unity Catalog au centre de son approche. Le catalogue gouverne des actifs tels que les modèles, les fonctions et les serveurs MCP. Unity AI Gateway applique ensuite ces autorisations et politiques pendant que les requêtes traversent le système.

Le guide actuel sur la gouvernance de l’IA indique que la passerelle peut gouverner des agents de programmation externes, notamment Claude Code, Cursor, Codex et Gemini CLI. Il décrit également des limites de débit, des budgets, le suivi de l’utilisation et des politiques de service au niveau des requêtes.

Snowflake cite Claude Code et Cursor dans sa propre annonce. Ce chevauchement est important. Aucune des deux entreprises ne limite la passerelle aux agents construits au sein de sa plateforme.

Chacune tente de devenir le point de contrôle neutre pour les agents créés ailleurs. Cette neutralité reste relative, car la couche de contrôle renforce toujours la plateforme de données environnante.

Pour les clients, la décision immédiate suivra souvent l’infrastructure existante. Une entreprise disposant de politiques, de données et de connaissances opérationnelles étendues sur Snowflake peut préférer prolonger ces contrôles via Cortex AI Gateway. Un client Databricks peut rencontrer moins de frictions avec une approche soutenue par Unity Catalog.

La compétition à plus long terme est moins prévisible. Les agents travaillent couramment avec des entrepôts de données, des dépôts logiciels, des systèmes de messagerie, des plateformes clients et des services cloud. Aucune plateforme de données unique ne possède toutes ces destinations.

Une passerelle doit donc prouver qu’elle peut gouverner des ressources au-delà de sa plateforme d’origine sans contraindre chaque flux de travail à une pile fermée. Les intégrations de sécurité et les connecteurs Natoma de Snowflake visent à étayer cet argument.

Databricks avance un argument d’interopérabilité similaire en couvrant des fournisseurs externes et des agents de programmation. Sa passerelle restait étiquetée bêta dans une documentation mise à jour en juillet 2026, ce qui laisse place à des changements de disponibilité et d’implémentation.

Aucun des deux fournisseurs n’a établi une avance décisive à travers des données publiques d’adoption. Les listes de fonctionnalités révèlent une convergence stratégique, mais elles ne montrent pas quelle passerelle traite davantage de trafic de production ou empêche davantage de violations de politiques.

La concurrence vient également de l’extérieur de la catégorie des plateformes de données. Cloudflare a introduit des portails de serveurs MCP qui regroupent plusieurs serveurs derrière une couche d’accès. Sa documentation sur les portails décrit la prise en charge d’OAuth et les journaux pour les requêtes d’outils individuelles.

Cloudflare aborde le problème depuis l’infrastructure réseau et d’accès. Les fournisseurs d’identité l’abordent par les identifiants et l’autorisation. Les entreprises spécialisées dans les passerelles se concentrent sur la découverte, l’inspection et l’application des politiques MCP.

Ces approches peuvent coexister au sein d’une même entreprise, mais le chevauchement des contrôles crée des frictions opérationnelles. Les équipes peuvent devoir décider où réside la politique faisant autorité et quel système conserve la piste d’audit complète.

La multiplication des passerelles peut également brouiller les responsabilités. Une requête peut transiter par une plateforme d’agents, une passerelle de modèles, une passerelle MCP, un proxy réseau et une couche d’autorisation applicative. Chaque système peut enregistrer une identité ou une décision différente.

L’ambition de Snowflake est de réduire cette fragmentation en combinant les contrôles. Le risque est que les clients remplacent de nombreux outils déconnectés par un point de contrôle étroitement lié à un seul fournisseur.

Cette tension influencera les décisions d’achat. Les entreprises recherchent une gouvernance cohérente, tout en voulant garder la liberté de changer de modèles, d’agents et de systèmes de données. La passerelle gagnante devra offrir un contrôle centralisé sans transformer l’interopérabilité en dépendance.

Le mécanisme de passerelle fait de MCP une infrastructure

Les passerelles MCP s’imposent comme une infrastructure, car chaque connexion d’agent utile génère des besoins récurrents en matière d’identité, de politiques, de routage, d’observabilité et d’attribution des coûts.

Une connexion MCP basique répond à une question technique : comment un agent peut-il découvrir et invoquer un outil ? Une passerelle d’entreprise répond à une question opérationnelle : dans quelles conditions cette invocation doit-elle être autorisée ?

Prenons le cas d’un employé qui demande à un agent de programmation d’enquêter sur un incident de production. L’agent peut rechercher des documents techniques, examiner un dépôt, interroger des journaux, ouvrir un ticket et préparer une modification.

Chaque appel d’outil hérite du contexte des étapes précédentes. L’agent transporte également une certaine représentation de l’identité, des autorisations et de l’intention de l’employé. Une erreur dans cette chaîne peut exposer des données ou autoriser une action que l’employé n’a jamais demandée.

Une passerelle peut évaluer l’appel avant son exécution. Elle peut refuser un outil auquel l’utilisateur n’a pas accès, restreindre les paramètres ou exiger une approbation pour une opération d’écriture. Elle peut aussi conserver un enregistrement reliant l’action à l’utilisateur et à l’agent à l’origine de la demande.

Il s’agit du point d’application des politiques : l’endroit où une règle abstraite devient une décision d’autorisation, de refus ou d’approbation. Le concept est familier dans la gestion des API, l’accès zero trust et les systèmes d’identité cloud.

Le trafic des agents rend la décision plus complexe. Les requêtes sont souvent générées de manière probabiliste, et l’outil suivant peut dépendre de contenus non fiables récupérés à une étape antérieure.

Un document contenant des instructions malveillantes pourrait inciter un agent à invoquer un autre outil. Un serveur MCP compromis pourrait renvoyer du contenu destiné à modifier le comportement ultérieur. Un jeton aux droits trop étendus pourrait alors permettre à l’agent d’accéder à des données dépassant le cadre de la tâche initiale.

Des registres d’activité centralisés aident les enquêteurs à reconstituer ces chaînes. Ils ne préviennent pas toutes les attaques. La prévention exige également des identifiants aux droits limités, une conception sûre des outils, une validation des entrées, de l’isolation et des flux d’approbation rigoureux.

Le routage ajoute une autre fonction d’infrastructure. Une organisation peut approuver plusieurs modèles de langage pour différentes charges de travail. Un modèle peut convenir au raisonnement complexe, tandis qu’un autre traite les extractions de routine avec une latence plus faible.

Une passerelle peut sélectionner parmi les options approuvées sans obliger chaque application à implémenter une logique distincte selon le fournisseur. Elle peut aussi rediriger le trafic lorsqu’un point de terminaison devient indisponible.

Cette flexibilité peut réduire le couplage entre applications. Toutefois, la qualité du routage dépend de données d’évaluation et de politiques claires pour les charges de travail. Une passerelle ne peut pas déduire de manière fiable les priorités métier si l’organisation ne définit pas les compromis acceptables.

L’attribution des coûts est tout aussi utile, mais difficile. Compter les jetons est simple pour une requête unique. Attribuer le coût total d’un workflow en plusieurs étapes à un service, un projet ou un utilisateur exige une identité cohérente à chaque saut.

Snowflake affirme que Cortex AI Gateway peut attribuer la consommation aux équipes, agents ou charges de travail responsables. Les acheteurs devraient examiner le comportement de cette attribution lorsqu’un agent externe appelle plusieurs outils et modèles répartis entre des systèmes distincts.

Ils devraient également vérifier si l’application des budgets interrompt un workflow en toute sécurité. Arrêter un agent à mi-chemin peut laisser des modifications partielles, des transactions ouvertes ou des enregistrements incomplets.

L’analogie avec l’infrastructure est la plus forte lorsque ces contrôles disparaissent des applications individuelles. Les développeurs ne devraient pas avoir à recréer l’authentification, la journalisation, le routage et la logique budgétaire pour chaque nouvel agent.

La standardisation de ces fonctions peut accélérer le déploiement. Elle peut aussi faire de la passerelle une cible de grande valeur et une dépendance critique.

C’est pourquoi le marché converge vers une architecture de passerelle. Plus MCP rend l’accès aux outils portable, plus les entreprises ont besoin d’une couche cohérente pour encadrer cette portabilité.

Les promesses de sécurité doivent encore être étayées en production

Une passerelle centralisée améliore le contrôle, mais elle ne sécurise pas par défaut les connexions MCP et n’élimine pas les risques présents dans les outils eux-mêmes.

L’annonce de Snowflake présente la sécurité et la confiance comme le fondement de l’interopérabilité des agents. C’est un objectif raisonnable, mais l’entreprise n’a pas publié suffisamment d’éléments pour considérer cette affirmation comme établie de manière indépendante.

L’annonce ne fournit pas de chiffres d’adoption en production pour Cortex AI Gateway. Elle ne quantifie ni les attaques bloquées, ni les violations de politiques, ni la précision du routage, ni les économies générées par ses contrôles de consommation.

Sa prise en charge de plus de 100 serveurs MCP mesure la compatibilité plutôt que la fiabilité. Une passerelle a toujours besoin d’informations précises sur chaque serveur, ses outils, sa version et les privilèges requis.

Le défi de sécurité s’étend au-delà de la passerelle. Un serveur approuvé peut contenir du code vulnérable. Un outil légitime peut exposer des paramètres dangereux. Un agent peut aussi mal utiliser une capacité autorisée après avoir traité un contexte malveillant.

Les recommandations gouvernementales soulignent ces limites. Les recommandations de sécurité MCP de la NSA publiées en mai 2026 décrivent MCP comme une norme de communication de facto, tout en indiquant que sa posture de sécurité demeure inégale.

Le rapport identifie l’invocation dynamique d’outils, la confiance implicite, le partage de contexte, la faiblesse des contrôles d’accès, l’injection de prompts et les lacunes dans le cycle de vie des jetons. Il précise que de nombreuses protections dépendent de la rigueur de mise en œuvre plutôt que de garanties du protocole.

Cette distinction est importante pour évaluer Cortex AI Gateway. Une passerelle peut centraliser l’authentification et l’autorisation, mais elle ne peut pas rendre rétroactivement sûr chaque serveur connecté.

Elle ne peut pas non plus garantir qu’un agent a correctement interprété la demande d’un utilisateur. L’autorisation d’effectuer une action ne prouve pas que cette action correspond à l’intention de l’utilisateur.

Les workflows d’approbation peuvent réduire cet écart. Les modifications à haut risque devraient obliger une personne à examiner l’action exacte proposée, ses paramètres et son effet attendu. Les demandes d’autorisation génériques offrent peu de protection lorsque les utilisateurs ne peuvent pas voir ce qu’un agent va faire.

Les acheteurs devraient demander comment Snowflake gère l’identité déléguée. Un agent agissant pour le compte d’un employé ne devrait recevoir que les autorisations nécessaires à cette tâche. Il ne devrait pas hériter d’un identifiant de service aux droits étendus simplement parce que le workflow traverse plusieurs systèmes.

Ils devraient également examiner la révocation. Si un utilisateur change de rôle ou qu’un jeton est compromis, la passerelle doit interrompre rapidement tout accès ultérieur. Les identifiants mis en cache et les sessions d’agents de longue durée peuvent compliquer cette réponse.

La journalisation crée son propre compromis. Des enregistrements détaillés facilitent les audits et la réponse aux incidents, mais les prompts et paramètres d’outils peuvent contenir des informations sensibles. Les organisations ont besoin de règles de conservation, de masquage et d’accès pour les journaux eux-mêmes.

Le routage de modèles de la passerelle mérite le même niveau d’examen. Optimiser simultanément la qualité, la latence, la disponibilité et la consommation semble utile. Ces objectifs peuvent entrer en conflit, et un choix automatisé peut affecter la qualité de sortie ou les obligations de traitement des données.

Les entreprises devraient vérifier si le routage conserve les données dans les régions et chez les fournisseurs approuvés. Elles devraient aussi déterminer si les changements de modèle sont visibles pour les propriétaires d’applications et reproductibles lors des audits.

La concentration chez un fournisseur présente un autre risque. Placer le trafic des agents, les autorisations d’outils, le routage de modèles et les contrôles de coûts dans un seul système crée une vaste dépendance opérationnelle. Une panne ou une erreur de politique à cette couche peut interrompre simultanément de nombreux workflows.

Cela n’invalide pas le modèle de passerelle. Cela signifie que la passerelle doit être évaluée comme une infrastructure d’identité, de réseau et d’API, et non comme une simple fonctionnalité pratique.

La position de Snowflake peut aider les clients déjà engagés dans son modèle de gouvernance. Les acheteurs ont néanmoins toujours besoin de tests indépendants, d’une conception fondée sur le moindre privilège, d’inventaires de serveurs, d’une exécution isolée et de procédures de réponse aux incidents.

Une lecture responsable du titre de Google News est donc plus nuancée que le langage marketing de Snowflake. Cortex AI Gateway indique la direction prise par le marché, mais ne tranche pas la question de savoir si une seule plateforme peut sécuriser l’ensemble du cycle de vie des agents.

Ce que les lecteurs de Google News devraient surveiller ensuite

La thèse de la passerelle ne deviendra crédible que lorsque l’adoption, les preuves d’application des politiques et le comportement multiplateforme dépasseront les promesses de lancement.

Le premier indicateur est l’utilisation en production. Snowflake devrait divulguer combien de clients font transiter des agents tiers actifs par Cortex AI Gateway, et non simplement combien de serveurs MCP elle prend en charge.

Des éléments utiles incluraient le nombre d’appels d’outils gouvernés, l’éventail des systèmes externes et la part des workflows utilisant des politiques appliquées. Les études de cas clients devraient identifier des actions concrètes plutôt que répéter des déclarations générales sur la confiance.

Meltwater figurait dans l’annonce de Snowflake comme une organisation intéressée par la connexion sécurisée d’agents aux données et aux outils. Le texte décrivait Cortex AI Gateway comme une étape vers ce résultat. Il n’établissait pas l’existence d’un déploiement achevé assorti de résultats mesurés.

Cette différence mérite d’être suivie. Les partenaires de conception peuvent valider l’orientation d’un produit, tandis qu’un trafic de production soutenu met à l’épreuve la fiabilité, le mappage des identités et le coût opérationnel.

Le deuxième indicateur est la qualité de l’application des politiques. Snowflake doit démontrer que les politiques fonctionnent pour les agents internes comme tiers, sans perte de l’identité utilisateur ni du contexte de la tâche.

Les acheteurs devraient rechercher des contrôles granulaires sur les outils individuels et leurs paramètres. Ils devraient également surveiller les politiques d’approbation, la révocation des jetons, la prévention des fuites de données et les intégrations avec les systèmes existants de surveillance de sécurité.

Des rapports d’incident publiés offriraient des éléments précieux. Un plan de contrôle crédible devrait expliquer comment il a détecté un comportement dangereux, ce qu’il a bloqué et comment les administrateurs ont reconstitué l’événement.

Le troisième indicateur est la réponse concurrentielle. Databricks, Cloudflare, les fournisseurs d’identité et les fournisseurs indépendants de passerelles continueront d’étendre leurs propres contrôles pour les agents.

Si ces produits convergent vers des formats de politiques portables et des normes d’audit partagées, les entreprises pourraient changer de passerelle sans reconstruire chaque règle. Cette évolution renforcerait MCP en tant qu’infrastructure ouverte.

Si chaque plateforme crée des identités, des modèles de politiques et des journaux propriétaires, MCP pourrait rester ouvert au niveau de la connexion tandis que la gouvernance deviendrait fragmentée. Cela affaiblirait la promesse d’outils d’agents interchangeables.

Les développeurs devraient suivre la manière dont les passerelles exposent les informations de débogage. Une requête refusée doit recevoir une explication compréhensible, et une requête routée doit fournir une trace montrant quel modèle et quelle politique l’ont influencée.

Les équipes de sécurité devraient évaluer si une seule passerelle peut voir la chaîne d’actions complète. Une visibilité partielle peut produire un faux sentiment d’assurance lorsqu’un agent traverse un système non surveillé.

Les acheteurs d’entreprise devraient également comparer les modes de défaillance du plan de contrôle. Ils doivent savoir si les agents s’arrêtent en toute sécurité lorsqu’une passerelle tombe en panne, si les actions de lecture et d’écriture se comportent différemment et comment fonctionne l’accès d’urgence.

Les travailleurs du savoir ont un intérêt direct dans ces choix, car les politiques de passerelle déterminent les informations auxquelles leurs assistants peuvent accéder. De meilleurs contrôles peuvent favoriser des connexions utiles sans accorder à chaque agent un accès permanent aux e-mails, documents et systèmes de messagerie.

Les équipes qui créent un contexte technique consultable devraient maintenir les autorisations associées aux documents sources. Une base de connaissances d’ingénierie bien conçue réduit la nécessité d’exposer de vastes dépôts lorsqu’un agent n’a besoin que d’informations ciblées.

Les un à trois prochains mois devraient permettre de déterminer si Cortex AI Gateway devient un véritable point de contrôle ou reste une annonce stratégique. Surveillez l’apparition de déploiements de production nommés, de résultats d’application mesurables et d’intégrations plus poussées au-delà de l’environnement propre à Snowflake.

Snowflake a clairement exprimé son pari sur l’infrastructure. L’entreprise estime que les organisations géreront les agents via une couche centralisée combinant routage des modèles, gouvernance MCP, journaux d’activité et contrôles de consommation.

Ce pari semble aller dans la bonne direction, car les outils portables créent un besoin de contrôle portable. La question non résolue est de savoir qui gagnera le droit d’exploiter ce plan de contrôle.

La couverture de l’actualité Google a saisi le moment du lancement. Le test le plus important commencera lorsque les entreprises connecteront des agents capables de lire des données sensibles, de consommer de véritables ressources et de modifier des systèmes de production. Demandez-vous si votre organisation peut identifier chaque agent, limiter chaque outil et reconstituer chaque action avant de considérer toute passerelle MCP comme une infrastructure de confiance.