Sécuriser l'entreprise agentique sur Google Cloud

Les principales préoccupations citées par les entreprises concernent l'exposition des données sensibles (52 %) et la conformité réglementaire (50 %) (source : Cloud Security Alliance, déc. 2025). Cependant, la transition des entreprises vers l'IA agentique autonome introduit de nouveaux vecteurs critiques :

• Le délai moyen d'exploitation des failles a chuté à moins sept jours, ce qui signifie que les failles zero-day sont régulièrement exploitées avant la publication des correctifs logiciels (source : rapport "Mandiant M-Trends").
• Dans les environnements cloud modernes, les identités de charge de travail non humaines sont 82 fois plus nombreuses que les identités humaines (source : Google Cloud NEXT 2026).
• 42 % des agents IA d'entreprise actifs disposent actuellement de droits sensibles et trop permissifs (source : Google Cloud NEXT 2026).
• Pour se défendre contre ces attaques à la vitesse de la machine, il est indispensable de sécuriser simultanément l'ensemble de la pile d'IA : l'infrastructure, les données, les modèles et les agents autonomes.

L'IA fantôme se produit lorsque des développeurs ou des unités commerciales déploient des modèles non autorisés, des API externes ou des compétences d'agent tierces sans l'aval du service informatique :

• Plus de 15 % des compétences d'agent disponibles sur les places de marché publiques sont connues pour être malveillantes (source : Google Cloud NEXT 2026).
• 68 % des organisations exécutent des modèles auto-hébergés intégrés au cœur de logiciels tiers, souvent sans s'en rendre compte (source : Wiz, L'état de l'IA dans le cloud en 2026).
• Pour détecter l'IA fantôme, les organisations utilisent la solution Wiz AI-APP, qui se connecte via une API en 15 minutes pour générer une nomenclature d'IA (AI-BOM). En complément, Gemini propose un catalogue Agent Registry centralisé permettant de classer et de gérer l'ensemble des agents actifs, des serveurs MCP personnalisés et des outils externes.

Non. Bien que le manque de compétences soit un défi reconnu, les organisations dotées d'une gouvernance formelle de l'IA sont trois fois plus susceptibles de former leur personnel aux outils de sécurité de l'IA (source : Cloud Security Alliance, déc. 2025). Par ailleurs, les équipes de sécurité sont désormais responsables de la protection de l'IA dans 53 % des organisations (source : Cloud Security Alliance, déc. 2025). Google Cloud intègre directement la sécurité dans le maillage de la plate-forme : les configurations de base sont automatisées via le plan de base de l'entreprise, les interactions d'exécution sont régies de manière native par Model Armor, et des agents autonomes de détection et de correction comme CodeMender et Wiz Green Agent testent et génèrent des correctifs de code idiomatiques directement dans les workflows des développeurs.

La sécurisation des agents autonomes nécessite d'aller au-delà des comptes de service statiques. Les identités non humaines sont 82 fois plus nombreuses que les identités humaines, et 42 % des agents actifs possèdent des droits d'accès trop permissifs (source : Google Cloud NEXT 2026). C'est pourquoi Google Cloud établit une pile de sécurité axée sur l'identité :

• Agent Identity : type de principal dédié et de premier ordre, distinct des utilisateurs humains, qui provisionne des identifiants d'exécution cryptographiques, fortement attestés et liés au cycle de vie.
• Contrôles basés sur le principe du moindre privilège : les fonctionnalités sont limitées à l'aide de Privileged Access Manager (PAM) pour l'accès Just-in-Time (JIT), ce qui élimine les privilèges permanents.
• Limite d'accès des principaux (PAB) : impose des limites de ressources strictes et protectrices pour limiter le potentiel néfaste maximal des identités d'agents en cours d'exécution.

Le framework d'IA sécurisé (SAIF) est l'architecture conceptuelle de Google pour un déploiement sécurisé et responsable de l'IA. Il traduit les principes de sécurité zéro confiance en systèmes d'IA en imposant une traçabilité de la provenance des builds conforme au niveau SLSA 3 validée par l'autorisation binaire, des contrôles automatisés de type policy as code dans Cloud Build et une détection continue des menaces. Dans les environnements agentiques, le SAIF se décline en un cycle de vie en quatre étapes : Architecture, Inventaire, Interception et Défense (source : e-book "Secure AI Innovation", chapitre 6).

Le protocole MCP (Model Context Protocol) est une norme ouverte qui permet aux agents IA autonomes de se connecter à des sources de données externes, des outils d'entreprise et des API métier. Cependant, les intégrations MCP personnalisées non gérées introduisent des points de terminaison risqués et non validés en production. Google Cloud sécurise les outils agentiques via les serveurs MCP gérés par Google Cloud (comme le serveur MCP pour BigQuery). Cela permet de standardiser la façon dont les agents interagissent avec les bases de données d'entreprise, en appliquant des autorisations IAM strictement délimitées et auditables, et en remplaçant les wrappers d'API personnalisés par des connexions renforcées et gérées par l'entreprise (source : Google Cloud NEXT 2026).

La fuite de contexte entre sessions se produit dans les environnements mutualisés ou multi-agents lorsque le contexte d'une conversation privée, des jetons utilisateur ou des données d'entreprise sensibles de la session d'un utilisateur sont divulgués par inadvertance à un autre utilisateur. Google Cloud élimine ce type de fuite grâce à Agent Development Kit (ADK) (source : e-book "Secure AI Innovation", chapitre 2) :

• Isolation des locataires : ADK garantit une séparation stricte entre les utilisateurs et une isolation des environnements d'exécution à l'aide des primitives natives session_id et user_id.
• Séparation des identifiants : les jetons d'authentification en aval sont isolés afin qu'un agent ne puisse pas transférer d'identifiants ni d'état de conversation entre différentes sessions utilisateur.

Oui. Les organisations adoptent des stratégies multimodèles et exécutent en moyenne 2,6 modèles différents (source : Cloud Security Alliance, déc. 2025). Google Cloud est compatible avec la gouvernance multimodèle en s'appuyant sur Gemini comme plan de contrôle d'exécution centralisé. Les garde-fous d'exécution unifiés, y compris Model Armor pour le nettoyage des prompts et les règles de gouvernance sémantique, s'appliquent de manière cohérente aux modèles Gemini propriétaires, aux modèles Open Source et aux modèles tiers. Dans les environnements multicloud (y compris AWS Bedrock, Databricks et les solutions Open Source non gérées), le graphe de sécurité Wiz mappe les failles et les chemins d'attaque pour l'ensemble des fournisseurs de services cloud (source : Google Cloud NEXT 2026).

Non. CodeMender repose sur une architecture d'exécution locale axée sur la confidentialité (source : e-book "Secure AI Innovation", chapitre 4) :

• Traitement via une CLI locale : le moteur d'analyse CodeMender fonctionne via une interface de ligne de commande locale directement dans l'environnement sécurisé du développeur.
• Bac à sable isolé : les builds d'application et les vérifications du code d'exploitation actif s'exécutent dans un bac à sable isolé sur votre propre infrastructure.
• Aucun entraînement de modèle : votre code source propriétaire et votre propriété intellectuelle restent strictement protégés, et ne sont jamais utilisés pour entraîner les modèles de fondation de Google. Les développeurs conservent un contrôle total grâce aux workflows standards dans leur IDE ou leur CLI, ainsi qu'aux points d'approbation human-in-the-loop (avec intervention humaine) avant toute intégration d'un correctif dans le code.

Pour exécuter une logique métier à haut risque sans exposer l'infrastructure principale, les entreprises utilisent l'architecture de référence Bring Your Own Container (BYOC) :

• Exécution des conteneurs en bac à sable : les agents autonomes à haut risque, tels que ceux chargés de la gestion de l'inventaire ou de la coordination logistique, sont déployés dans des conteneurs isolés sur Cloud Run.
• Séparation stricte des autorisations : les autorisations d'infrastructure intervenant au moment du déploiement sont strictement séparées des autorisations d'exécution.
• Points de contrôle human-in-the-loop (avec intervention humaine) : Agent Development Kit (ADK) introduit des points de suspension programmés où les actions à haut risque (initialisation d'API de traitement ou versement de fonds, par exemple) nécessitent une approbation humaine explicite avant d'être effectuées.

Google Cloud applique une solution d'exécution à double garde-fou pour nettoyer les charges utiles sans ajouter de latence :

1. Contrôle des accès (limites IAM) : appliqué de manière native au niveau d'Agent Gateway à l'aide d'Identity-Aware Proxy (IAP) pour vérifier de manière cryptographique les ID numériques des appelants avant de router les connexions.
2. Contrôle de l'intention (limites sémantiques) : Model Armor fonctionne comme un proxy intégré qui analyse les interactions entre l'utilisateur, l'agent et le modèle en temps réel pour neutraliser les injections de prompts, empêcher le jailbreaking et masquer les informations sensibles permettant d'identifier personnellement l'utilisateur. Au niveau de la couche d'application, Agent Development Kit (ADK) applique la validation des entrées (comme BeforeToolCallback) pour empêcher les injections SQL indirectes dans les tables BigQuery.

Pour éviter les fuites de données, il est nécessaire d'implémenter une défense en profondeur au niveau des couches du réseau, de l'application et du modèle :

• Topologies privées : les charges de travail d'IA s'exécutent sur des VPC partagés gérés de manière centralisée et isolés par VPC Service Controls (VPC-SC), ce qui crée un macro-périmètre autour de l'ensemble de l'écosystème agentique.
• Nettoyage intégré : Model Armor nettoie et masque automatiquement les données client sensibles et les informations permettant d'identifier personnellement l'utilisateur dans les entrées de prompt et les sorties du modèle.
• Authentification sans jeton : le gestionnaire d'authentification Agent Identity gère les handshakes OAuth complexes en aval pour le compte des utilisateurs, en transmettant les jetons de manière sécurisée sans exposer les identifiants bruts à l'agent.
• Informatique confidentielle : protège les données utilisées en chiffrant la mémoire lors du traitement actif du modèle.