Vertex AI Vulnerability Exposes Private Data in Google Cloud
Les faits
En mars 2026, une équipe de chercheurs de Palo Alto Networks, Unit 42, a publié une analyse révélant une faille dans le modèle d'autorisation de Vertex AI, le service de déploiement et d'exécution de modèles d'IA sur Google Cloud¹. La vulnérabilité permettait, dans certains scénarios de configuration, à des agents d'IA liés à des comptes de service Vertex AI d'accéder à des artefacts et données privées et, potentiellement, d'exfiltrer ou de modifier ces éléments¹².
Concrètement, le problème tient à des permissions implicites et à des liaisons IAM (Identity and Access Management) mal réglées entre les comptes de service Vertex AI, les espaces de stockage (Cloud Storage), les registres d'artefacts et d'autres ressources du projet. Autrement dit, un agent d'IA autorisé à exécuter un modèle pouvait aussi, suivant la configuration, lire des fichiers sensibles, interroger d'autres services et appeler des API qui n'étaient pas nécessaires pour sa mission initiale¹.
La découverte et la publication par Unit 42 ont provoqué une réaction rapide des équipes de sécurité de Google Cloud, qui ont diffusé des recommandations et des ajustements de configuration destinés à réduire l'exposition des comptes de service³. Les médias spécialisés ont relayé l'alerte et détaillé les risques associés².
Contexte
Vertex AI s'est imposé comme une brique centrale des architectures de machine learning dans le cloud. Son intérêt tient à la facilité de déploiement des modèles, à la gestion des pipelines et à l'orchestration des ressources. Mais cette centralisation ajoute un point de concentration de risques quand la gouvernance des comptes de service et des permissions n'est pas assez stricte.
Plusieurs facteurs opérationnels ont favorisé l'apparition de la vulnérabilité observée par Unit 42 :
- comptes de service partagés entre environnements de développement et de production, brouillant les frontières d'accès;
- attribution de permissions larges pour accélérer les déploiements, au détriment du principe du moindre privilège;
- absence d'outils automatisés et de contrôles réguliers pour vérifier que les comptes de service ne peuvent pas accéder à des artefacts sensibles en production.
Les équipes MLOps et sécurité font face à un dilemme pratique : accélérer l'innovation tout en maintenant une gouvernance fine des accès. Quand on laisse des comptes de service « tout faire », on obtient une surface d'attaque étendue. Des incidents antérieurs, dans d'autres contextes d'orchestration et d'exécution dans le cloud, ont montré que ce type d'erreur de configuration peut déboucher sur des exfiltrations et des manipulations d'artefacts.
Réactions et conséquences
Google Cloud a publié un bulletin technique avec des recommandations et des mesures correctrices pour limiter l'exposition des comptes de service et renforcer le modèle d'autorisation³. Ces mesures incluent des modifications de configuration IAM, des guides pour isoler les artefacts sensibles et des conseils pour activer la journalisation et l'alerte sur les appels API critiques³.
Unit 42 a fourni une analyse technique du vecteur d'attaque et des recommandations pratiques à intégrer dans les pratiques MLOps, notamment autour de la séparation des environnements et du renforcement des permissions¹.
Pour les entreprises, les impacts potentiels sont concrets :
- risque de violation de confidentialité et perte de propriété intellectuelle si des ensembles de données d'entraînement ou des modèles propriétaires sont exposés;
- compromission de la chaîne logistique ML, par exemple modification d'un modèle avant redéploiement, avec des conséquences commerciales ou opérationnelles graves;
- risques réglementaires en cas d'exfiltration de données personnelles, entraînant des enquêtes et des sanctions potentielles;
- coûts opérationnels significatifs pour mener des audits, effectuer des rotations de clés et restaurer des environnements impactés.
Un exemple hypothétique mais représentatif : une startup de santé qui héberge ses modèles et ses données sur Vertex AI pourrait voir un agent mal configuré accéder à des modèles propriétaires et modifier les prédictions, ce qui mettrait en danger la qualité des décisions cliniques et exposerait l'entreprise à des risques légaux et réputationnels.
Bonnes pratiques et actions immédiates
Les recommandations à court terme à appliquer sans délai :
- auditer toutes les liaisons IAM qui impliquent des comptes de service Vertex AI et identifier les permissions excessives;
- appliquer le principe du moindre privilège avec des rôles personnalisés lorsque nécessaire;
- isoler les artefacts sensibles (modèles, datasets, images de conteneurs) dans des projets ou des buckets séparés avec des politiques IAM dédiées;
- activer et surveiller la journalisation des appels API, définir des alertes sur les actions sensibles et conserver les logs pour enquête;
- procéder à une rotation des clés et secrets associés aux comptes de service à risques, et limiter l'accès aux secrets via Secret Manager en contrôlant strictement les bindings IAM.
Sur le plan organisationnel et processus :
- séparer nettement les environnements de développement, de préproduction et de production pour éviter le partage involontaire de comptes de service;
- intégrer des contrôles automatisés dans la CI/CD et les pipelines MLOps pour vérifier les permissions avant déploiement;
- simuler des scénarios d'attaque internes visant les agents IA pour valider que les comptes de service n'ont pas d'accès non justifié.
Ces mesures reprennent et complètent les recommandations publiées par Unit 42 et Google Cloud³¹.
Fermeture
Cet incident rappelle que la sécurité des déploiements IA repose autant sur une solide gouvernance des identités que sur la robustesse des modèles. Les outils d'orchestration comme Vertex AI apportent de la valeur, mais ils concentrent aussi des risques si les permissions et la séparation des responsabilités ne sont pas strictement gérées. Appliquer des contrôles IAM granulaires, isoler les artefacts sensibles et automatiser la vérification des comptes de service dans les pipelines sont des étapes opérationnelles et pragmatiques pour réduire l'exposition.
Pour aller plus loin, il faut ancrer ces pratiques dans les processus MLOps et former les équipes qui manipulent les comptes de service afin qu'elles comprennent les conséquences d'une permission trop large. Les recommandations techniques publiées par Unit 42 et Google Cloud constituent un point de départ que toute organisation utilisant Vertex AI devrait intégrer immédiatement¹³.
