Vertex AI « Double Agents » : des service agents sur-privilégiés comme voie d'escalade cloud

De quoi s’agit-il ?

Le 31 mars 2026, Unit 42 (Palo Alto Networks) a divulgué un angle mort de sécurité dans Google Cloud Vertex AI : un agent IA mal configuré ou compromis peut être transformé en ce que le chercheur Ofir Shaty appelle un « double agent » — un agent qui semble faire son travail tout en exfiltrant discrètement des données, en atteignant des ressources internes et en pivotant à travers un projet cloud. Il n’y a ici aucune attaque inédite contre le modèle. Le problème est d’identité et de cadrage des permissions : l’identité de service provisionnée pour un agent déployé porte bien plus de droits que la tâche de l’agent n’en requiert, et ces droits sont accessibles depuis le contexte d’exécution même de l’agent.

C’est une classe de défaut, pas un bug isolé. Le même schéma — un service agent IA qui hérite de credentials de niveau plateforme sans cadrage au moindre privilège — se répète partout où des agents sont déployés comme des charges de travail cloud à part entière. Google a depuis mis à jour sa documentation et changé ses recommandations (voir Statut), ce qui permet d’en parler ouvertement.

Comment ça marche

Lorsque vous construisez un agent avec l’Agent Development Kit (ADK) de Vertex AI et le déployez via Agent Engine, Google provisionne pour lui un Per-Project, Per-Product Service Agent (P4SA). Unit 42 a constaté que ce P4SA disposait de permissions excessives par défaut et — surtout — que ces credentials sont accessibles depuis l’agent en cours d’exécution :

• Le service de métadonnées délivre le credential. Après déploiement, tout appel à l’agent déclenche une requête vers le service de métadonnées interne de Google, qui expose les credentials du service agent ainsi que le projet GCP hôte, l’identité de l’agent et les scopes de la machine. C’est le schéma cloud classique du vol de credentials via IMDS — voir Prise de contrôle cloud via IMDS — appliqué cette fois à un runtime d’agent.
• Le credential s’échappe de son bac à sable. Avec le credential récupéré, les chercheurs ont pivoté du contexte d’exécution de l’agent vers le projet client, mettant à mal la garantie d’isolation et obtenant un accès en lecture sans restriction à tous les buckets Google Cloud Storage de ce projet.
• Il a aussi atteint le tenant de Google. Comme Agent Engine s’exécute dans un projet tenant géré par Google, le même credential a révélé des détails de l’infrastructure interne de la plateforme et — plus notable — donné un accès en lecture à des dépôts Artifact Registry restreints, dont des images de conteneurs constituant le Reasoning Engine de Vertex AI. Unit 42 souligne que cela expose du code propriétaire et fournit à un attaquant une cartographie de la chaîne d’approvisionnement logicielle interne.

La condition de déclenchement est un agent qui traite des entrées non fiables ou exécute du code influencé par l’attaquant — par exemple via l’injection de prompt indirecte ou une charge sérialisée malveillante. Le dégât, lui, provient du credential permanent et trop large, à un appel de métadonnées de distance.

Pourquoi c’est important

Les agents sont de plus en plus déployés comme des charges de travail cloud ordinaires, et ils héritent de la plus ancienne faiblesse du cloud : des identités de service trop larges par défaut. La leçon d’Unit 42 est nette : accorder des permissions larges aux agents par défaut viole le moindre privilège et constitue « une faille de sécurité dangereuse, par conception ».

C’est le rayon d’action qui rend ce sujet sérieux plutôt qu’anecdotique. Un seul credential « lecture totale » transforme un agent utile en menace interne : exfiltration depuis n’importe quel bucket, reconnaissance de l’infrastructure interne, accès à des images privées qui peuvent amorcer l’attaque suivante. La limite honnête sur la gravité est que l’exploitation suppose un agent d’abord mal configuré ou compromis — ce n’est pas une prise de contrôle distante non authentifiée. Mais dans les déploiements d’agents, « compromis par une entrée injectée » n’est pas un scénario distant : c’est le scénario attendu. C’est exactement le couplage décrit par le trifecta létal : accès aux données privées, entrée non fiable et voie d’exfiltration.

Défenses

Les mitigations relèvent de l’IAM cloud et de l’hygiène de déploiement, et se généralisent au-delà de Vertex AI :

• Remplacez le service agent par défaut. Le correctif recommandé par Google est Bring Your Own Service Account (BYOSA), à la place du P4SA par défaut, cadré au moindre privilège pour que l’agent ne détienne que les permissions requises par sa tâche. Si votre plateforme provisionne une identité par défaut, considérez-la comme non fiable tant que vous ne l’avez pas restreinte.
• Restreignez les scopes OAuth au moindre privilège. La consigne de Shaty est explicite : validez les frontières de permissions et réduisez les scopes OAuth au minimum. Un droit permanent « lecture de tous les buckets » est la précondition dont dépend toute la chaîne.
• Traitez le déploiement d’un agent comme du code de production. Vérifiez l’intégrité du code source, validez les frontières et menez des tests de sécurité contrôlés avant la mise en production — pas une fois l’agent en ligne et joignable.
• Verrouillez l’accès aux métadonnées. Là où la plateforme le permet, limitez quelles charges de travail peuvent joindre le service de métadonnées et ce qu’il renvoie ; le credential qui n’atteint jamais le runtime de l’agent ne peut pas y être volé.
• Segmentez le projet. Ne laissez pas le rayon d’action d’un agent être « le projet entier ». Utilisez des projets séparés, VPC Service Controls et un IAM par ressource pour qu’un credential fuité lise un bucket, pas tous.
• Surveillez les appels aux API cloud initiés par l’agent. Une énumération soudaine de buckets ou des pulls de registre depuis une identité d’agent sont un signal fort que le credential a été retourné contre vous.

Statut

Élément	Détail
Divulgué par	Palo Alto Networks Unit 42 (chercheur Ofir Shaty)
Date	31 mars 2026
Surface affectée	Vertex AI Agent Engine + ADK ; Per-Project, Per-Product Service Agent (P4SA) par défaut
Mécanisme	Le service de métadonnées expose au runtime de l’agent un credential de service trop large
Impact	Lecture de tous les buckets GCS du projet client ; accès aux détails d’infrastructure du tenant et à des images Artifact Registry restreintes
Réponse éditeur	Google a mis à jour sa documentation de contrôle d’accès ; recommande BYOSA + moindre privilège
Nature	Défaut de cadrage des permissions / d’identité, pas une attaque inédite contre le modèle

Ceci est une analyse défensive, au niveau de la conception : aucun payload d’exploitation, aucune chaîne d’attaque actionnable. L’enseignement durable précède de loin les LLM et s’y applique désormais : un agent ne vaut, en sécurité, que l’identité sous laquelle il s’exécute — et un credential par défaut capable de tout lire est une compromission qui n’attend qu’un déclencheur.