Vertex AI sous menace un agent mal configuré peut devenir un agent double et voler des identifiants dans le cloud

Une équipe de chercheurs en sécurité a exposé une zone aveugle dans Vertex AI de Google Cloud qui mérite l'attention immédiate de toute équipe qui déploie des agents d'intelligence artificielle dans le nuage. Le problème n'est pas un échec anecdotique : il permet à un agent mal configuré ou compromis d'agir comme un « double agent », tout en conservant son apparence légitime puisqu'il extrait des lettres de créances, des données et des vecteurs d'attaque dans l'environnement nuageux.

La découverte, publiée par des spécialistes de Unité 42 des réseaux Palo Alto, souligne le modèle de permissions que Google applique aux agents déployés avec Vertex AI, en particulier au service « Par-Project, Per-Product Service Agent » (P4SA). Par défaut, cet agent reçoit des permissions assez étendues, qui ouvrent une porte dangereuse : si un attaquant parvient à exécuter un code qui consulte le service de métadonnées Google Cloud à partir du contexte de l'agent, il peut obtenir des identifiants associés et, de là, se déplacer latéralement dans le projet.

Techniquement, en lançant un agent avec l'Agent Engine de Vertex AI, tout appel que l'agent fait au service de métadonnées peut révéler non seulement le jeton du service, mais aussi les informations du projet GCP qui abrite l'agent, l'identité de l'agent lui-même et les champs d'application de l'hôte où il est exécuté. Avec ces références, les chercheurs ont réussi à passer du contexte isolé de l'agent aux ressources du projet client. Dans la pratique, cela signifiait un accès illimité à la lecture des données stockées dans Google Cloud Storage dans le cadre de ce projet, rendant un outil d'aide à un risque de type initié.

L'exposition n'était pas limitée au projet du client. Comme l'Agent Engine peut fonctionner dans le cadre de projets de locataires gérés par Google, les références ont également montré des métadonnées et des références à des seaux qui font partie de l'infrastructure interne de la plateforme. Bien que, dans certains cas, de telles références n'aient pas la permission de télécharger ces seaux directement, elles ont permis la découverte d'itinéraires et de dépôts protégés.

Une conséquence particulièrement inquiétante a été la possibilité d'accéder aux dispositifs privés de registre des artefacts qui avaient été enregistrés dans les registres pendant le déploiement du moteur Agent. Avec cette visibilité, un attaquant pourrait télécharger des images conteneur qui font partie du cœur du moteur de raisonnement Vertex AI, et jusqu'à ce qu'ils aient accès au contenu d'autres dépôts privés. L'accès à ce code propriétaire implique non seulement la perte de propriété intellectuelle, mais permet aussi à un attaquant de cartographier la chaîne d'approvisionnement logicielle de la plateforme et de localiser des images obsolètes ou vulnérables pour une exploitation ultérieure.

Google a réagi en mettant à jour sa documentation officielle pour expliquer plus clairement comment Vertex AI utilise les comptes, les ressources et les agents, et indique les mesures que les clients devraient appliquer. Les recommandations comprennent le remplacement de l'agent par défaut par un compte en libre-service (Appliquez votre propre compte de service, BYOSA) et l'application stricte du principe du privilège inférieur de sorte que l'agent n'a que les capacités nécessaires à sa tâche. Des détails sur les agents et le moteur sont disponibles dans la documentation Vertex AI, et le guide de bonnes pratiques de l'IAM fournit les lignes directrices pour limiter les autorisations et les champs d'application: Vertex AI - Agents et Bonnes pratiques IAM dans Google Cloud.

Du point de vue de la sécurité opérationnelle, cette affaire offre des leçons claires. La première est qu'il ne suffit pas de traiter un agent IA comme un objet inoffensif : son déploiement doit être soumis aux mêmes contrôles que tout nouveau microservice ou application en production. Limiter les champs d'application OAuth, les interactions de vérification avec les métadonnées, examiner les autorisations attribuées aux comptes de service et tester le comportement de l'agent dans des conditions contrôlées sont des étapes indispensables avant de prendre un agent à la production.

Une autre recommandation pratique est d'utiliser les comptes de service gérés par l'équipe elle-même, configurés avec des permissions minimales et la rotation des clés; cela évite de compter sur des agents avec des privilèges trop larges par défaut. Il est également conseillé de surveiller et d'alerter les utilisations inhabituelles des métadonnées et des blocs de lecture de masse dans le stockage en nuage ou l'accès à des dépôts privés qui ne sont pas justifiés.

Cet incident souligne également l'importance de protéger la chaîne d'approvisionnement des logiciels dans les environnements nuageux. L'accès aux images de conteneurs et aux artefacts privés peut servir d'avion à un attaquant pour reproduire l'environnement, rechercher des défauts et préparer des attaques plus profondes. La documentation du registre des artéfacts et des contrôles d'accès plus stricts peuvent atténuer certains de ces risques : Registre des artéfacts - documentation.

Bref, l'apparition de ce vecteur montre que la sécurité dans l'ère A dans le cloud n'est pas seulement une question de modèles et de données : elle dépend également de la façon dont les identités, les permissions et les déploiements sont gérés. Les recommandations des chercheurs peuvent être résumées dans un conseil pratique pour les équipes de sécurité et d'exploitation : traiter chaque agent comme s'il s'agissait d'une nouvelle infrastructure de production, vérifier leurs permis et supprimer les privilèges qui ne sont pas nécessaires.

Si vous souhaitez approfondir le rapport technique et la recherche originale, l'analyse des experts est disponible sur le web de Unité 42, et c'est une bonne idée d'examiner la documentation officielle de Google Cloud sur les agents et la gestion de l'identité pour appliquer l'atténuation recommandée.