Vertex AI : quand l'agent IA de Google devient un agent double

Ofir Shaty, chercheur senior en sécurité chez Palo Alto Networks, a construit un agent IA malveillant à l'aide du Google Cloud Application Development Kit (ADK), l'a packageé comme un fichier pickle Python sérialisé, et l'a déployé sur le Vertex AI Agent Engine. Au premier appel à l'agent, le code a interrogé le service de métadonnées interne de Google et extrait les credentials du service agent P4SA (Per-Project, Per-Product Service Agent) — le compte de service géré par Google qui est automatiquement assigné à chaque agent IA déployé sur la plateforme.

« A misconfigured or compromised agent can become a 'double agent' that appears to serve its intended purpose, while secretly exfiltrating sensitive data, compromising infrastructure, and creating backdoors into an organization's most critical systems. »

Les credentials volés ont permis de pivoter depuis le contexte d'exécution de l'agent vers le projet Google Cloud du client. Accès obtenu : lecture non restreinte de tous les buckets Google Cloud Storage du projet. Pour une entreprise qui utilise GCP comme infrastructure principale, c'est l'équivalent d'un accès en lecture à l'ensemble de ses données stockées dans le cloud.

Le code propriétaire de Google

Les chercheurs ne se sont pas arrêtés au projet client. Les mêmes credentials P4SA ont donné accès aux dépôts Artifact Registry restreints de Google — les dépôts internes qui hébergent les images conteneurs et les packages constituant l'infrastructure de Vertex AI. Unit 42 a téléchargé les images conteneurs des dépôts privés suivants : us-docker.pkg.dev/cloud-aiplatform-private/reasoning-engine et cloud-aiplatform-private/llm-extension/reasoning-engine-py310:prod.

Ces images forment le cœur du Vertex AI Reasoning Engine. Y accéder expose la propriété intellectuelle de Google et fournit à un attaquant un blueprint pour identifier d'autres vulnérabilités. Les credentials compromis n'ont pas seulement permis de télécharger les images connues — ils ont aussi révélé le contenu de dépôts Artifact Registry restreints, exposant l'existence de nombreuses autres images auxquelles les chercheurs n'avaient pas connaissance.

Shaty : « An attacker could potentially leverage this unintended visibility to map Google's internal software supply chain, identify deprecated or vulnerable images, and plan further attacks. »

Pickle : le fichier code.pkl

Parmi les fichiers découverts dans l'environnement du tenant, la présence d'un fichier code.pkl a immédiatement attiré l'attention. Le module pickle de Python est notoirement non sécurisé pour la désérialisation de données provenant de sources non fiables — il exécute du code arbitraire au moment de la désérialisation. La documentation Python elle-même affiche un avertissement explicite à ce sujet.

Un attaquant qui parvient à manipuler ce fichier pourrait obtenir une exécution de code à distance dans l'environnement d'exécution de l'agent, créant un backdoor persistant et puissant. Les chercheurs n'ont pas testé cette exploitation — elle était hors scope de l'investigation. Mais ils l'ont documentée comme un risque significatif lié à l'utilisation de formats de sérialisation non sécurisés dans les systèmes IA modernes.

OAuth 2.0

La cause racine sous-jacente à l'ensemble des failles, selon Shaty, n'est pas spécifique à Google. C'est un problème systémique lié aux éléments trop permissifs dans OAuth 2.0, le protocole d'autorisation standard de l'industrie. Les scopes définis par défaut sur le Agent Engine pouvaient potentiellement étendre l'accès au-delà de l'environnement GCP et jusque dans le Google Workspace de l'organisation — Gmail, Google Calendar, Google Drive.

IAM fournit une autorisation granulaire par principal et par ressource. Mais les scopes OAuth introduisent une couche de contrôle d'accès supplémentaire au niveau de l'API. Quand les scopes par défaut sont trop larges — ce qui était le cas ici — un attaquant qui compromet un agent dispose d'un périmètre d'action qui dépasse largement le contexte de l'agent.

Surface d'attaque

La réponse de Google

Google a collaboré avec les chercheurs de Unit 42 sur la divulgation. L'entreprise a confirmé que des contrôles non contournables empêchent le service agent de modifier les images de production dans l'Artifact Registry — ce qui bloque les scénarios de poisoning cross-tenant. Google a mis à jour sa documentation pour expliciter comment Vertex AI utilise les ressources, comptes et agents. La recommandation principale : remplacer le service agent par défaut par un BYOSA (Bring Your Own Service Account) et appliquer le principe du moindre privilège.

Ce que Google n'a pas fait : changer les permissions par défaut. La documentation a été mise à jour. Le comportement par défaut du P4SA, lui, reste le même pour les déploiements qui ne suivent pas activement les nouvelles recommandations. Chaque organisation qui déploie un agent Vertex AI sans configurer un BYOSA opère avec les mêmes permissions excessives que celles exploitées par Unit 42.

Pas la première fois

En novembre 2024, les mêmes chercheurs de Unit 42 avaient déjà publié « ModeLeak » — deux vulnérabilités dans Vertex AI permettant l'escalade de privilèges et l'exfiltration de modèles LLM via des jobs personnalisés ou des modèles malveillants. Le pattern se répète : les plateformes IA cloud héritent des modèles de permissions conçus pour des workloads traditionnels, mais les agents IA ont un profil de risque fondamentalement différent. Un agent peut exécuter du code arbitraire, interroger des APIs, accéder à des services — il n'est pas un conteneur statique. Le traiter comme tel dans le modèle de permissions est le problème structurel.

Ian Swanson, VP de la sécurité IA chez Palo Alto Networks : les organisations doivent prêter attention aux risques de sécurité que les agents IA introduisent involontairement. La question de savoir si des permissions par défaut similairement excessives existent sur les plateformes IA d'autres hyperscalers n'a pas reçu de réponse.

Le fichier pickle dans le tenant — code.pkl — est un objet Python sérialisé qui contient la logique de l'agent. En le désérialisant dans un environnement contrôlé, les chercheurs ont pu inspecter sa structure et révéler davantage de l'architecture propriétaire interne de Google. La documentation Python elle-même dit qu'il ne faut jamais désérialiser de pickle provenant de sources non fiables. Google utilise pickle pour sérialiser les agents de son propre Reasoning Engine.