Le contexte technique
J'apprécie ces cas non pas pour le drame, mais pour la mécanique transparente de l'attaque. Le scénario est bien trop familier pour quiconque intègre l'IA dans des entreprises réelles : un service d'IA tiers, des permissions OAuth étendues, un compte compromis, et puis l'effet domino.
Selon Vercel, le point d'entrée n'était pas chez eux, mais chez Context.ai, utilisé par un employé. En compromettant cet outil tiers, l'attaquant a piraté le compte Google Workspace de l'employé de Vercel et, de là, a accédé à une partie des environnements internes et des variables d'environnement qui n'étaient pas marquées comme sensibles.
Le détail crucial est que, d'après Vercel, les variables marquées comme sensibles n'étaient pas accessibles en format lisible. C'est là que j'ai vraiment marqué une pause : toute la différence entre un 'incident désagréable' et un 'cauchemar total' reposait sur la simple discipline de classification des secrets.
Le contexte supplémentaire dresse un tableau encore plus sombre. Il semble que les jetons OAuth de Context.ai aient été volés après que la machine d'un employé a été infectée par un infostealer. L'attaquant a ensuite utilisé ces accès existants pour contourner le périmètre via une intégration de confiance. C'est une attaque de la chaîne d'approvisionnement d'école, simplement avec une étiquette IA.
Ce qui me frappe le plus ici, ce n'est pas la faille elle-même, mais la facilité avec laquelle les équipes considèrent encore les outils d'IA comme 'un simple SaaS pratique'. Non, cela fait désormais partie de votre plan d'identité et de votre architecture IA, surtout si le service demande l'accès à Workspace, aux e-mails, aux documents, aux logs ou aux jetons de déploiement.
Qu'est-ce que cela change pour les entreprises et l'automatisation ?
Premièrement, OAuth pour les services d'IA doit être traité comme un accès de production, pas comme un simple bouton inoffensif 'Se connecter avec Google'. Si vous construisez une automatisation IA et connectez des outils externes à Workspace, Slack, GitHub ou Vercel, vous avez déjà une surface d'attaque sur votre chaîne d'approvisionnement.
Deuxièmement, les variables d'environnement sans classification appropriée sont comme une mine oubliée. Peu importe si vous les considérez 'peu sensibles' si elles peuvent être utilisées pour un mouvement latéral, pour collecter des clés API ou des jetons de déploiement.
Troisièmement, les équipes qui adoptent une approche 'zéro confiance' (zero-trust) envers tout agent IA et toute intégration tierce gagneront. Celles qui accordent des permissions larges, n'auditent pas les jetons émis et gèrent les secrets en se disant 'on verra plus tard' perdront.
Je vois constamment la même erreur chez mes clients : ils veulent une mise en œuvre rapide de l'intelligence artificielle, mais considèrent la sécurité des connexions comme une tâche secondaire. Et c'est précisément cela qui détermine si vous obtiendrez une accélération des processus ou un incident coûteux.
Si vous avez déjà un zoo croissant d'outils d'IA, je vous conseille de revoir immédiatement vos autorisations OAuth, la classification des secrets et les accès des agents. Si nécessaire, chez Nahornyi AI Lab, nous pouvons analyser votre configuration et construire une automatisation IA qui vous fait gagner du temps, au lieu d'ouvrir une porte dérobée pour le prochain piratage.