Cet article s'inspire de la conversation entre Mackenzie et Abdel Sghiouar dans le podcast « The Secure Disclosure ». Écoutez l'épisode dans son intégralité ou regardez-le ci-dessous.
Si vous donnez à un agent libre accès à votre cluster, il peut remonter la piste d’un problème à travers toutes les couches de la pile plus rapidement que n’importe quel ingénieur de garde. Mais c’est précisément cette portée qui rend l’agent susceptible d’être piraté. Lui retirer ses droits d’écriture l’empêche de perturber le cluster, mais un agent en lecture seule peut toujours lire toutes les informations confidentielles que le cluster lui dévoile, et un agent piraté peut être contraint de les divulguer.
Abdel Sghiouar a passé 13 ans chez Google et occupe désormais le poste de « Senior cloud Developer Advocate », spécialisé dans Kubernetes et les applications natives sur l’ cloud . Il estime que le terme « injection de prompt » ne rend pas pleinement compte de l’étendue de la vulnérabilité des agents. Il préfère parler d’« empoisonnement de prompt ». Mackenzie s’est entretenue avec lui pour discuter de la sécurité des agents IA dans Kubernetes, et des changements qui interviennent lorsqu’un agent prend les commandes.
La réponse d'Abdel consiste à « faire confiance, mais vérifier », même s'il admet que la question de la confiance reste un problème non résolu.
À quoi un agent IA a-t-il accès dans votre cluster ?
Dès qu’un agent entre en jeu, la première question à se poser est de savoir s’il dispose du niveau d’autorisation adéquat. Dans Kubernetes, cela relève du contrôle d’accès basé sur les rôles (RBAC). Un agent d’exploitation se voit généralement attribuer un accès en lecture étendu, car il a besoin de signaux provenant de l’ensemble du cluster pour remplir sa mission, et c’est précisément cet accès que convoite un attaquant.
Selon Abdel, un attaquant dispose de deux moyens pour retourner cet accès contre vous. Le premier consiste à corrompre les données lues par l'agent. Les journaux d'application font partie des signaux que reçoit un agent d'exploitation ; ainsi, un attaquant capable d'injecter du texte dans ces journaux peut également en insérer dans l'invite de l'agent. « L'application recevrait les données, elle les enregistrerait sur le disque, puis l'agent les lirait. »
C’est pourquoi Abdel préfère le terme « empoisonnement de la ligne de commande ». L’expression « injection de ligne de commande » invite à la comparaison avec l’injection SQL, un problème qui peut être résolu grâce à des requêtes paramétrées ; or, un grand modèle linguistique ne dispose d’aucun moyen équivalent pour distinguer les instructions des données d’entrée. Il traite simultanément la ligne de commande du système, les instructions de l’utilisateur, l’historique de la conversation et tout ce qu’il a intégré au contexte à ce moment-là ; ainsi, une ligne de journal rédigée par un attaquant peut avoir le même poids qu’une instruction donnée par l’opérateur.
Le deuxième risque concerne les informations que l'agent peut lire une fois qu'il a été compromis. Si ses autorisations couvrent tout ce que le pod peut voir, « il peut lire les secrets, il peut lire les variables d'environnement », et tout est exposé dès que l'agent suit une instruction erronée. L'empoisonnement permet à l'attaquant de s'introduire dans l'agent, et un accès en lecture trop large détermine la quantité d'informations qu'il parvient à emporter.
Pourquoi un accès en lecture seule ne suffit pas
La plupart des équipes qu’Abdel a vues utiliser Kubernetes avec des agents les lancent en mode lecture seule. Cela protège le cluster, car un agent en lecture seule ne peut ni supprimer un déploiement ni vider un nœud. Et, comme l’a souligné Mackenzie, sans accès en lecture, l’agent n’est pratiquement d’aucune utilité. Plus important encore, un agent en lecture seule lit tout de même les secrets et continue d’enregistrer tout élément malveillant qui se serait glissé dans les journaux.
Mackenzie a mis en évidence le même schéma en dehors du cluster. Aikido Security a découvert une injection de ligne de commande (ou « prompt poisoning ») dans le workflow GitHub utilisé par Google pour trier les tickets de son dépôt CLI Gemini, où un ticket spécialement conçu pouvait amener l’agent à divulguer les variables d’environnement auxquelles il avait accès. Le correctif de Google a empêché l’agent de transmettre ces variables, ce qui a comblé cette faille particulière, mais a laissé la porte ouverte à l’empoisonnement de la ligne de commande.
Selon Abdel, les mécanismes de sécurité sur lesquels s'appuient déjà les équipes « s'appliquent toujours aux agents ». Ce qui change, c’est qu’il existe désormais un composant qui prend des décisions qu’on ne peut pas prendre pour argent comptant. Un modèle linguistique peut avoir des « hallucinations », de sorte qu’« on ne peut pas se fier entièrement à l’exactitude du raisonnement de l’agent ». Sa solution consiste à « faire confiance, mais vérifier », en faisant intervenir un humain pour contrôler les actions de l’agent, même s’il reconnaît franchement qu’il s’agit là de « l’un des plus grands problèmes à venir » et d’un défi que le secteur n’a pas encore résolu.
Le rôle de la sécurité « Aikido »
Aikido pentest IA permet de tester les capacités de l'IA. Il injecte des données malveillantes dans les documents récupérés et les résultats des outils afin de vérifier si celles-ci prennent le pas sur les instructions de l'agent, et si un agent compromis peut être poussé à appeler des outils ou à accéder à des systèmes auxquels il ne devrait pas avoir accès. Il vous indique également si votre agent peut être amené à travailler pour quelqu'un d'autre.
Le reste dépend de l'étendue de l'accès dont dispose cet agent s'il a été compromis. Les contrôles « Infrastructure as Code » détectent les rôles ClusterRole ou les rôles de gestion des identités et des accès d'cloud trop généraux dans la pull request, y compris ceux proposés par l'agent lui-même, et analyse des secrets détectent les identifiants codés en dur avant qu’ils ne se retrouvent dans une variable d’environnement que l’agent peut lire. analyse d’images de conteneurs couvre les charges de travail auxquelles votre agent fait confiance ainsi que l’image de l’agent lui-même, en signalant les paquets vulnérables et les logiciels malveillants présents dans les deux.
Une fois que l'agent est en cours d'exécution, Aikido Cloud il vérifie les autorisations dont il dispose, qui ne correspondent pas toujours à celles accordées par la pull request. Il signale les liaisons RBAC de Kubernetes qui confèrent à l’agent un accès plus étendu que ne l’exige sa tâche, et les contrôles de posture détectent les cas où l’identité de charge de travail de l’agent correspond à un rôle « cloud » doté de droits d’administrateur. L’analyse de l’accessibilité et des chemins d’attaque relie ensuite ces résultats entre eux, en indiquant ceux qu’un agent pourrait enchaîner pour passer de son pod à un élément critique, tel qu’une base de données de production ou des identifiants d’administrateur « cloud ».
{{cta}}
