Snowflake verrouille CoCo avant l’action : budgets IA, MCP et SQL passent sous contrôle enterprise
Snowflake franchit une étape importante dans la gouvernance des agents IA. Dans une annonce publiée le 18 août 2026 sur son Engineering Blog, l’entreprise détaille de nouveaux contrôles pour Snowflake CoCo, son environnement agentique destiné notamment au travail sur les données et au développement.
La nouveauté la plus concrète est déjà disponible : des quotas de crédits IA par utilisateur capables de bloquer automatiquement de nouvelles requêtes lorsque les limites fixées sont atteintes.
Mais l’annonce va plus loin. Snowflake prépare aussi des règles imposées au niveau de l’organisation, des Agent Profiles, un Restricted Session Scope pour réduire les droits SQL d’un agent et une gouvernance plus fine des serveurs et outils MCP. L’objectif est clair : empêcher qu’un agent hérite simplement de tous les pouvoirs techniques de l’utilisateur humain qui l’exécute.
C’est un changement stratégique. À mesure que les agents IA accèdent aux bases de données, API, outils métiers et serveurs MCP, les entreprises ne peuvent plus se contenter d’observer les logs après une erreur. Les règles doivent être définies avant l’action et appliquées au moment où l’agent tente réellement d’utiliser un outil.
Qu’annonce exactement Snowflake pour la gouvernance de CoCo ?
Snowflake ajoute à CoCo une combinaison de contrôle des coûts, des modèles, des outils, des serveurs MCP et de la portée SQL des agents. Une partie est disponible maintenant, tandis que plusieurs fonctions restent annoncées pour plus tard.
La fonction immédiatement disponible concerne les quotas par utilisateur. Snowflake indique qu’ils sont désormais en disponibilité générale pour CoCo dans Snowsight, CoCo CLI et CoCo Desktop. L’entreprise permet de définir des plafonds de consommation et de bloquer les nouvelles requêtes IA lorsqu’un utilisateur atteint sa limite.
La documentation officielle sur les quotas par utilisateur confirme la possibilité de définir un plafond mensuel et, pour les fonctionnalités IA, un plafond quotidien. Le cycle mensuel est aligné sur le calendrier UTC et le cycle quotidien redémarre à minuit UTC. Snowflake CoCo, identifié dans la documentation sous le domaine CORTEX CODE, fait partie des domaines sur lesquels le blocage peut être appliqué.
En parallèle, Snowflake annonce trois couches supplémentaires de gouvernance autour de CoCo : les paramètres gérés au niveau de l’organisation, les Agent Profiles et le Restricted Session Scope. Le billet du 18 août les présente collectivement comme “generally available soon”. Elles ne doivent donc pas être décrites comme déjà disponibles en production pour tous les clients.
Comment Snowflake peut-il bloquer automatiquement le budget IA d’un utilisateur ?
Le principe est celui d’un hard budget : lorsqu’un utilisateur atteint sa limite quotidienne ou mensuelle, Snowflake enregistre le dépassement puis refuse les nouvelles requêtes IA jusqu’au prochain cycle ou jusqu’à une modification du quota.
C’est plus contraignant qu’une simple alerte FinOps. Un tableau de bord vous indique qu’une équipe a trop dépensé après coup ; un quota bloquant empêche directement la poursuite de la consommation.
La documentation apporte toutefois une nuance importante. L’évaluation du dépassement n’est pas instantanée. Le pipeline Snowflake peut prendre quelques minutes pour constater la dépense et appliquer le blocage. Un utilisateur peut donc dépasser légèrement sa limite pendant cette fenêtre, notamment si une requête importante est engagée juste avant que le blocage ne soit effectif.
C’est un détail essentiel pour les responsables Agent FinOps. Un plafond de 100 crédits ne doit pas être interprété comme une barrière transactionnelle garantissant mathématiquement que la consommation s’arrêtera à 100,000 crédits.
Snowflake permet également d’analyser la consommation dans ses données d’usage. Le billet officiel indique que l’activité CoCo peut être interrogée dans SNOWFLAKE.ACCOUNT_USAGE, avec des détails par requête, utilisateur, modèle et type de tokens.
Pour les entreprises qui multiplient les agents IA, c’est probablement l’un des aspects les plus immédiatement utiles de l’annonce : le coût devient une politique applicable, et non plus seulement un indicateur comptable.
Pourquoi la gouvernance MCP de Snowflake devient-elle stratégique pour les agents IA ?
Parce que MCP transforme un agent en acteur capable d’interagir avec des systèmes réels. Le problème de sécurité n’est donc plus seulement ce que le modèle peut répondre, mais ce qu’il est autorisé à faire.
Le Model Context Protocol (MCP) permet à un agent de se connecter à des outils et services externes. Snowflake cite notamment Jira, Slack, Google Workspace et des API internes parmi les systèmes qui peuvent enrichir le contexte et les capacités d’un agent.
Cette évolution rejoint directement le passage du chatbot vers l’IA agentique. Un chatbot produit une réponse. Un véritable agent IA peut sélectionner un outil, lancer une action, interroger des données et enchaîner plusieurs étapes.
CritiquePlus expliquait déjà cette différence dans son guide sur l’IA agentique et dans son analyse consacrée aux agents IA. L’enjeu devient beaucoup plus sérieux lorsque l’assistant ne se contente plus de conseiller l’utilisateur mais agit réellement dans son environnement numérique.
Snowflake cherche précisément à déplacer la gouvernance vers cette couche d’action.
Quelles règles Snowflake veut-il imposer avant le démarrage d’une session CoCo ?
Snowflake veut permettre aux administrateurs de déterminer à l’avance les modèles, serveurs MCP, outils et droits SQL auxquels une session CoCo pourra accéder.
Les Managed Settings sont la première couche. Snowflake documente un fichier de configuration géré par l’organisation que les utilisateurs ordinaires ne peuvent pas modifier. Les paramètres administratifs prennent la priorité sur les configurations locales et peuvent notamment limiter les outils ou les serveurs MCP utilisables.
Le billet du 18 août précise qu’une organisation pourra déterminer quels serveurs MCP peuvent être utilisés, quels modèles sont disponibles et quelles actions d’outils nécessitent une approbation. Ces politiques doivent s’appliquer de manière cohérente aux différentes surfaces CoCo et ne pourront pas simplement être désactivées par l’utilisateur.
Les Agent Profiles ajoutent ensuite une logique d’équipe ou de rôle. Une équipe data engineering pourra recevoir automatiquement un modèle, des skills et des accès différents d’une équipe finance. L’idée est d’éviter que chaque utilisateur configure lui-même son environnement agentique.
Enfin, le Restricted Session Scope (RSS) cherche à limiter le rayon d’action SQL. Snowflake explique qu’un agent ne doit plus être implicitement considéré comme autorisé à utiliser tout ce que les identifiants de l’utilisateur humain permettent. Un rôle adapté doit être actif avant que certaines opérations SQL deviennent accessibles.
C’est probablement le changement conceptuel le plus important : identité humaine et autorité agentique ne devraient plus être confondues.
Les politiques MCP de Snowflake sont-elles réellement exécutées avant la session ?
Pas toutes, et la distinction est importante. Certaines limites sont imposées avant la session, tandis que les politiques portant sur les appels d’outils sont évaluées au niveau du tool call.
Snowflake affirme que ses trois couches de gouvernance — organisation, profil et portée de session — sont imposées avant le démarrage d’une session plutôt que simplement surveillées après coup.
Mais les politiques de Cortex AI Gateway fonctionnent aussi à un niveau différent. Snowflake précise que les règles de gouvernance sont définies dans Horizon Catalog puis appliquées au niveau de l’appel d’outil. L’administrateur peut autoriser certains serveurs MCP, désactiver un outil particulier, imposer des limites de débit et conserver un historique d’audit.
Il serait donc excessif d’écrire que « toutes les politiques MCP sont exécutées avant la session ».
La formulation plus exacte est la suivante : Snowflake prépare les frontières de l’agent avant sa session, puis applique des décisions de sécurité supplémentaires lorsque l’agent appelle effectivement un outil MCP.
Cette architecture est plus intéressante qu’un simple système de logs, car elle combine prévention et audit.
Que change Cortex AI Gateway pour les serveurs MCP et les outils externes ?
Cortex AI Gateway veut devenir un point central de contrôle entre les agents et les outils auxquels ils accèdent.
Snowflake prévoit quatre contrôles particulièrement importants : une allowlist de serveurs MCP, des politiques au niveau de chaque outil, des rate limits par serveur et une piste d’audit enregistrant l’auteur de la demande, ses permissions, la décision d’autorisation et le résultat de l’action.
Un administrateur pourrait ainsi conserver un outil Salesforce de lecture tout en interdisant un outil de suppression exposé par le même serveur. C’est beaucoup plus précis que le modèle binaire « serveur autorisé ou serveur interdit ».
La documentation actuelle de CoCo confirme déjà l’existence de mécanismes permettant d’interdire les serveurs MCP configurés par les utilisateurs, d’imposer certains serveurs et de restreindre les URL autorisées. Les outils MCP participent également au système de permissions CoCo, avec des règles allow, deny ou ask.
Cette logique rejoint les questions déjà analysées par CritiquePlus dans n8n, MCP et agents IA : connecter un agent à davantage d’outils n’est intéressant que si l’architecture prévoit dès le départ permissions minimales, journalisation et validation des opérations sensibles.
Que ne dit pas clairement Snowflake sur ces nouveaux contrôles ?
La principale faiblesse de l’annonce est que plusieurs briques stratégiques ne sont pas encore en disponibilité générale et que Snowflake ne peut pas garantir à lui seul la sécurité d’un écosystème MCP externe.
Première limite : les Managed Settings annoncés dans cette nouvelle architecture, les Agent Profiles et le Restricted Session Scope sont présentés comme GA soon. Snowflake accompagne d’ailleurs son annonce d’un avertissement indiquant que les produits futurs mentionnés ne constituent pas un engagement de livraison et peuvent évoluer.
Deuxième nuance : Tools by Cortex AI Gateway est marqué dans le billet “PuPr soon”, c’est-à-dire annoncé pour une future public preview, et non comme une fonction déjà pleinement GA.
Troisième limite : une allowlist ne garantit pas qu’un serveur MCP restera sûr éternellement. Un serveur approuvé aujourd’hui peut changer de comportement après une mise à jour, ajouter un nouvel outil ou devenir vulnérable. La gouvernance doit donc intégrer une réévaluation régulière, pas seulement une autorisation initiale.
Quatrième limite : un hard budget protège la dépense, pas la qualité du travail. Un agent peut consommer exactement son quota tout en travaillant sur une mauvaise hypothèse, en répétant une stratégie inefficace ou en lançant des actions sans réelle valeur métier.
Un agent compromis peut-il contourner les règles en combinant plusieurs outils autorisés ?
C’est précisément l’un des scénarios que les entreprises devraient tester avant de considérer leur architecture agentique comme sûre.
Prenons un cas hypothétique : les outils A, B et C sont individuellement autorisés. Aucun ne permet directement une opération interdite. Mais l’agent peut-il combiner la donnée récupérée par A, une transformation réalisée via B et une action déclenchée par C pour produire un résultat qui aurait été interdit s’il avait existé sous la forme d’un seul outil ?
L’annonce de Snowflake décrit des politiques fines, de l’audit et du contrôle au niveau des tools. Elle ne démontre pas que toutes les compositions possibles de plusieurs outils autorisés sont automatiquement sûres. Cette question nécessite des tests adversariaux et des politiques tenant compte non seulement de chaque appel individuel, mais aussi de la séquence d’actions et du contexte de la session.
Pour CritiquePlus, c’est l’un des tests les plus intéressants à mener sur cette architecture.
Qui peut vraiment profiter de Snowflake CoCo et de cette gouvernance MCP ?
Les premiers bénéficiaires sont les grandes organisations qui veulent déployer des agents sur des données sensibles sans donner aux utilisateurs ou aux agents un accès incontrôlé.
Pour les équipes data engineering, les quotas et profils peuvent éviter qu’un usage expérimental de CoCo se transforme en consommation imprévisible.
Pour les équipes finance et FinOps, les limites quotidiennes et mensuelles rendent la dépense IA plus facilement attribuable et plafonnable.
Pour les équipes cybersécurité, le principal intérêt est ailleurs : limiter les serveurs MCP, contrôler les tools, restreindre la portée SQL et conserver une piste d’audit des actions.
Pour les développeurs, la gouvernance peut paradoxalement faciliter l’accès. Snowflake explique que l’objectif de ces garde-fous est de permettre aux équipes plateforme d’ouvrir CoCo plus largement, plutôt que de cantonner les développeurs à des environnements sandbox faute de garanties suffisantes.
Pour les PME, agences web, blogueurs ou créateurs indépendants, l’annonce est moins directement exploitable si leur infrastructure ne repose pas sur Snowflake. Le principe mérite néanmoins d’être retenu : un agent IA devrait disposer de son propre périmètre d’autorité, même lorsqu’il agit pour le compte d’un utilisateur disposant de droits beaucoup plus larges.
C’est exactement le type de précaution qui devient nécessaire pour les agents connectés à un CMS, comme l’explique notre guide WordPress MCP.
Quels risques faut-il encore surveiller avec Snowflake CoCo ?
Le premier risque reste la dépendance à une plateforme. Plus l’entreprise centralise modèles, données, permissions MCP, audit et contrôle des coûts dans Snowflake, plus le coût organisationnel d’un changement de fournisseur augmente.
Le deuxième concerne la configuration. Une bonne technologie de gouvernance ne protège pas contre une mauvaise politique. Si l’administrateur autorise trop de serveurs, trop d’outils ou des rôles SQL trop larges, l’agent restera surprivilégié malgré l’existence du control plane.
Le troisième est celui des agents composables. Un contrôle par outil ne suffit pas nécessairement à détecter une chaîne d’actions légitimes individuellement mais dangereuses collectivement.
Enfin, il faudra surveiller la disponibilité réelle de toutes les fonctions annoncées, leur comportement en production et la granularité des règles lorsque des milliers d’utilisateurs, agents, modèles et serveurs MCP coexistent.
Quel est l’avis CritiquePlus sur la nouvelle gouvernance Snowflake CoCo ?
CritiquePlus considère cette annonce moins comme une révolution produit que comme un signal de maturité majeur pour les agents IA d’entreprise.
La partie la plus immédiatement utile est le budget bloquant par utilisateur. Ce n’est pas spectaculaire, mais c’est exactement le type de fonction dont les entreprises ont besoin lorsque l’usage de l’IA passe du prototype à une consommation quotidienne mesurable.
Le vrai signal stratégique se trouve cependant dans l’association de quatre dimensions : coût, identité, portée des données et permissions tools.
Snowflake ne cherche plus seulement à proposer un agent capable d’accéder aux données de l’entreprise. Il construit progressivement un control plane d’autorité agentique chargé de déterminer combien l’agent peut consommer, quelles données il peut atteindre, quels modèles il peut utiliser et quelles actions externes il peut déclencher.
C’est probablement le bon modèle architectural pour l’entreprise : ne pas faire confiance à un agent simplement parce que l’utilisateur qui l’a lancé est autorisé.
Mais il faut éviter de présenter l’ensemble comme déjà livré. Les quotas sont disponibles ; plusieurs contrôles stratégiques sont encore annoncés GA soon, et la couche Tools by Cortex AI Gateway est annoncée en public preview prochainement.
La recommandation CritiquePlus est donc simple : tester immédiatement les quotas et les contrôles CoCo déjà disponibles, préparer les politiques MCP et SQL dès maintenant, mais attendre les versions effectivement livrées avant de construire une architecture critique autour des fonctions encore annoncées.
Que faut-il retenir de Snowflake CoCo en août 2026 ?
Snowflake fait passer la gouvernance des agents IA d’une logique de surveillance à une logique de contraintes exécutables.
Les quotas quotidiens et mensuels permettent de plafonner la consommation IA et de bloquer automatiquement les utilisateurs ayant atteint leur limite, avec toutefois un délai possible de quelques minutes avant l’application du blocage.
Les prochaines couches de gouvernance doivent contrôler les modèles disponibles, les serveurs MCP, les outils autorisés, les profils appliqués aux équipes et la portée SQL d’une session.
Le point le plus important dépasse finalement Snowflake : dans une entreprise, un agent IA ne devrait pas hériter automatiquement de toute l’autorité de l’humain qu’il représente.
C’est cette séparation entre identité, permissions, budget et capacité d’action qui pourrait devenir l’un des standards de fait du déploiement des agents en production.
Sources officielles Snowflake consultées ?
- Snowflake Engineering Blog, Governed AI for Every Builder: Enterprise Controls in Snowflake CoCo, publié le 18 août 2026.
- Snowflake Documentation, Per-user quotas, pour les limites quotidiennes et mensuelles, le blocage et ses délais d’application.
- Snowflake Documentation, Managed settings (organization policy), pour les règles administratives imposées à CoCo.
- Snowflake Documentation, CoCo CLI Model Context Protocol (MCP) support, pour les allowlists, serveurs MCP imposés et permissions au niveau des tools.
- Snowflake Engineering Blog, Snowflake Launches Cortex AI Gateway and Advanced AI Security at Black Hat 2026, publié le 28 juillet 2026.
