Nous l’avons déjà évoqué sur Solutions Numériques, notamment dans nos articles sur la sécurité des agents et leur niveau de risque en entreprise. Mais au-delà du constat, un cas récent analysé par Unit 42 apporte un éclairage concret. Sur Vertex AI, un agent mal configuré peut devenir un point d’accès à des ressources cloud sensibles, sans exploiter de faille classique.
Un risque déjà identifié, mais encore abstrait
Ces dernières semaines, plusieurs travaux ont mis en avant un point commun dans les architectures d’IA agentique. Le risque ne vient pas uniquement des modèles eux-mêmes, mais de leur intégration dans le système d’information. Nous avions déjà abordé cette question dans nos précédents articles, notamment « La sécurité des agents ne repose pas sur les prompts, mais sur les permissions et l’identité » et « Agents IA : deux tiers des entreprises les jugent plus dangereux que les humains », en soulignant le rôle central des permissions et des identités dans les dérives potentielles. Mais ces analyses restaient encore largement théoriques.
Vertex AI, un scénario concret d’escalade
Les chercheurs de Unit 42 ont récemment documenté un cas précis sur la plateforme Vertex AI de Google Cloud. Dans leur démonstration, un agent déployé avec un compte de service disposant de permissions étendues a pu accéder à des ressources au-delà de son périmètre initial, notamment des données stockées dans des buckets cloud et des artefacts internes.
Le point critique tient au modèle d’attribution des droits. L’agent ne dispose pas de permissions strictement limitées à sa fonction. Il hérite des droits associés à son compte de service, souvent définis de manière large pour simplifier les déploiements. Une mauvaise configuration suffit à lui ouvrir un accès à des ressources sensibles, sans exploitation de vulnérabilité technique.
Un enchaînement simple mais difficile à détecter
Le scénario décrit par Unit 42 repose sur un enchaînement relativement simple. Un agent est déployé pour interagir avec certains services. Il utilise pour cela un compte de service disposant de droits étendus, par exemple sur le stockage ou certaines API. S’il est manipulé ou détourné, cet agent peut alors utiliser ces permissions pour explorer l’environnement, récupérer des données ou interagir avec d’autres composants du cloud. Ce type d’activité est difficile à détecter, car elle s’effectue dans le cadre d’une identité légitime. Elle ne contourne pas les mécanismes de sécurité, elle s’y inscrit.
Un agent qui agit comme un utilisateur interne
Dans ce scénario, l’agent devient une forme d’utilisateur interne automatisé. Il ne force pas l’accès aux systèmes. Il agit avec des droits valides, souvent plus larges que nécessaire. Cela modifie profondément la nature du risque. Il ne s’agit plus d’une intrusion externe visible, mais d’un usage détourné de permissions existantes, beaucoup plus difficile à identifier dans les journaux d’activité.
Ce que cela implique pour les équipes IT
Ce cas met en lumière des implications très concrètes pour les entreprises. D’abord, la nécessité de limiter strictement les permissions des comptes de service utilisés par les agents, en appliquant des principes de moindre privilège. Ensuite, la mise en place de mécanismes de supervision adaptés, capables de suivre les actions réalisées par ces agents au même titre que celles des utilisateurs humains. Enfin, une revue des architectures existantes s’impose. Dans de nombreux cas, les agents sont déployés rapidement, avec des droits larges pour faciliter les usages. Ce compromis devient aujourd’hui un point de fragilité.
