La pile de gouvernance des agents IA de Google Cloud : « Gérez les agents comme une organisation d’ingénierie »

La pile de gouvernance du Gemini Enterprise Agent Platform, annoncée par Google Cloud lors de Cloud Next 26, présente un cadre structuré pour la gestion de la sécurité des agents IA. Sa philosophie centrale est simple : il faut traiter une flotte d’agents comme une organisation d’ingénierie. Il faut leur attribuer une identité, contrôler leurs droits d’accès, appliquer des politiques, surveiller leurs comportements et tout auditer.

Contexte

• Un outil SaaS mal configuré expose passivement des données, mais un agent IA mal configuré agit activement de manière incorrecte. Google Cloud avertit que le problème du shadow IT (usage de l’IT non autorisé et non maîtrisé par l’organisation), déjà identifié en 2015, est en train de se répéter dans le domaine des agents IA.

Résumé de la pile de gouvernance en 5 couches

• Couche 1 - Identité des agents (Agent Identity) : chaque agent reçoit un identifiant chiffré unique. Cela corrige une architecture où l’ensemble des agents fonctionnaient auparavant avec un seul compte de service, rendant impossible le suivi des problèmes. Le principe du moindre privilège (Principle of Least Privilege) est appliqué, avec une définition fine, agent par agent, des tables, buckets et endpoints d’API accessibles.
• Couche 2 - Registre des agents (Agent Registry) : un catalogue centralisé qui gère tous les agents, outils MCP et endpoints de l’organisation. Le concept est comparable à un dépôt npm interne à l’entreprise : seuls les outils approuvés par l’équipe plateforme peuvent être utilisés par les agents en production. Le registre inclut aussi des métadonnées telles que le périmètre d’accès aux données, les permissions requises et la liste des agents qui utilisent chaque outil, ce qui permet d’identifier immédiatement l’étendue d’impact lors d’un patch de vulnérabilité.
• Couche 3 - Passerelle des agents (Agent Gateway) : un point central d’exécution des politiques de sécurité. Lorsqu’une politique est rédigée en langage naturel, elle est immédiatement appliquée à tous les agents qui passent par la passerelle. Il n’est plus nécessaire de modifier individuellement 50 agents : une seule politique suffit pour un déploiement global. L’intégration de Model Armor permet aussi de se protéger contre la prompt injection (injection de commandes malveillantes) et les fuites de données sensibles.
• Couche 4 - Détection d’anomalies et des menaces (Anomaly & Threat Detection) : des modèles statistiques établissent une base de référence du comportement normal de chaque agent et déclenchent des alertes en cas d’écart. Un LLM distinct joue le rôle de juge (judge) pour détecter, dans le processus de raisonnement d’un agent, les sauts logiques ou les jugements hors périmètre. La couche de détection des menaces surveille les attaques intentionnelles, comme les reverse shells, les connexions vers des IP malveillantes ou les tentatives d’élévation de privilèges.
• Couche 5 - Tableau de bord de sécurité des agents (Agent Security Dashboard) : basé sur Security Command Center, il visualise de manière unifiée les informations des quatre couches précédentes. Il fournit sur un seul écran la cartographie des relations agent-modèle, la découverte automatique des actifs, le scan de vulnérabilités et l’analyse de corrélation des signaux entre couches.

Différenciation

• Ce qui ressort, c’est la manière dont les agents sont mis en correspondance avec un modèle mental familier d’« exploitation d’une organisation d’ingénierie », afin de structurer la gouvernance de sécurité en cinq couches. En particulier, la rédaction de politiques en langage naturel avec application globale immédiate, ainsi que l’audit du raisonnement via l’approche LLM-as-a-judge, distinguent cette proposition des approches classiques de sécurité cloud.

Implications

• Les organisations qui mettent en place cette pile de gouvernance dès les premières étapes du déploiement d’agents bénéficieront d’un effet cumulatif où le coût marginal tend presque vers zéro à mesure que le nombre d’agents augmente. À l’inverse, celles qui multiplient les agents sans gouvernance risquent de faire face, comme à l’époque du shadow IT, à un élargissement de la surface d’attaque et à une complexité croissante des audits. Dans les secteurs réglementés comme la finance ou la santé, l’identité unique par agent et la traçabilité d’audit relèvent pratiquement d’exigences réglementaires, ce qui en fait probablement les premiers domaines où la pression d’adoption de ce cadre se fera sentir.