Un agent IA de GitHub vulnérable à une attaque par injection de prompt

Selon une dernière étude de Noma Security, une attaque par injection de prompt peut tromper la version beta d’Agentic Workflows de Github pour l’amener à extraire du contenu de dépôts privés et à le publier publiquement. Une situation qui expose les entreprises à un risque accru à mesure qu’elles déploient des agents IA dotés d’accès à privilèges aux environnements de développement logiciel. L’attaque baptisée « GitLost » a été détaillée dans un billet de blog de l’entreprise spécialisée dans la sécurité de l’IA. Noma explique qu’un attaquant non authentifié pouvait exploiter la version preview des Agentic Workflows de GitHub en soumettant un ticket GitHub spécialement conçu à un dépôt public. « Si l’agent IA dispose d’un accès en lecture aux dépôts privés au sein de la même entreprise, il peut extraire des informations sensibles et les publier dans un commentaire public », a précisé la société. Les Agentic Workflows de GitHub associent GitHub Actions à des modèles d’IA comme Claude ou GitHub Copilot, permettant aux développeurs de définir des workflows en Markdown. Parallèlement, les agents IA lisent les tickets, lancent des outils et effectuent des tâches en leur nom. « Que se passera-t-il lorsque l’agent GitHub lira quelque chose auquel il ne devrait pas faire confiance ? », a écrit Sasi Levi, chercheur chez Noma. « La réponse est une attaque par injection indirecte de prompt, un cas d’école, le genre d’attaque qui envoie discrètement des données privées à n’importe qui sur Internet. »

Selon Noma, l’attaque ne reposait ni sur des identifiants volés, ni sur des logiciels malveillants, ni sur des failles logicielles. Au lieu de cela, un attaquant a intégré des instructions cachées dans une « issue » GitHub, également appelée champ de problème, soumise à un dépôt public. « Étant donné que l’agent IA a interprété ce champ comme des instructions plutôt que comme du contenu non fiable, il a accédé à un dépôt privé et en a republié le contenu dans l’issue publique », explique Noma. « Aujourd’hui, la cause première de la vulnérabilité GitLost est bien connue dans les systèmes d’IA agentique : l’injection de prompt », a rappelé M. Levi. « Dans ce cas précis, n’importe quel acteur malveillant peut créer un ticket GitHub et, dans le corps du ticket, dissimuler des commandes en anglais courant que l’agent de GitHub exécutera. » Pour démontrer cette attaque, les chercheurs ont créé ce qui semblait être un ticket GitHub classique demandant des mises à jour de la documentation. Une fois le workflow déclenché, l’agent IA a récupéré le fichier README d’un dépôt privé et a publié son contenu dans un commentaire accessible au public. Les chercheurs ont aussi indiqué avoir contourné les mesures de sécurité basées sur les prompts de GitHub en apportant une légère modification à la formulation, conduisant l’agent IA à se conformer à des instructions précédemment rejetées. GitHub n’a pas immédiatement répondu à une demande de commentaire.

Un risque plus général lié aux agents IA

Selon Noma, GitLost illustre un défi architectural plus large pour les agents IA plutôt qu’une faille propre à GitHub. « Le problème n’est pas que l’agent IA de GitHub soit particulièrement vulnérable », a déclaré M. Levi. « Le problème est que tout agent IA ayant accès à la fois à du contenu externe non fiable et à des ressources internes sensibles peut devenir un pont involontaire entre les deux si les limites de confiance ne sont pas respectées. » Vibhum Dubey, chercheur indépendant en cybersécurité et membre d’une red team, pense pour sa part que ces découvertes mettent en lumière un problème plus fondamental que la simple injection de prompt. « Il ne s’agit pas d’une injection de prompt dans l’abstrait, mais du fait que GitHub accorde des autorisations à ses agents avant d’assurer leur sécurité », a ajouté M. Dubey. « Cette vulnérabilité révèle que les agents IA fonctionnent selon un modèle d’autorisations de compte de service, et non selon un modèle d’autorisations utilisateur. C’est une hypothèse architecturale que les équipes de sécurité avaient formulée avant de considérer les grands modèles de langage (LLM) comme un vecteur d’attaque. » Selon M. Dubey, l’injection de prompt en elle-même est presque secondaire. « Ce qui est dangereux, c’est que les limites de confiance existent dans le modèle de données de GitHub, mais nulle part dans le contexte d’exécution de l’agent », a-t-il expliqué. « L’agent ne ‘sait’ pas qu’un dépôt est privé. Il le perçoit simplement comme ‘accessible’. Alors que de plus en plus d’organisations déploient des agents, nous accumulons ces failles d’autorisations invisibles. »

M. Dubey estime que les entreprises devraient repenser la manière dont les autorisations sont accordées aux agents IA, plutôt que de considérer cette question essentiellement comme un défi de surveillance. Celui-ci préconise trois mesures concrètes : mettre à la disposition des agents des listes blanches explicites pour les dépôts, et non un accès général via un compte de service ; valider toutes les entrées utilisateur, y compris les messages de commit, les descriptions de requêtes pull et les tickets, avant d’atteindre le LLM ; et prévoir un dispositif d’arrêt d’urgence. « La plupart des équipes peuvent désactiver une clé API compromise, mais peut-on désactiver un agent malveillant ? », a-t-il demandé. Selon lui, GitLost montre comment les agents IA peuvent effectivement devenir une menace interne dès lors qu’on leur accorde un accès étendu. « Le génie de GitLost ne réside pas dans le fait qu’il ait trompé une IA, mais dans le fait qu’il a exploité à des fins malveillantes l’hypothèse de GitHub selon laquelle les comptes de service sont dignes de confiance », a-t-il souligné. « Les agents ont été explicitement conçus pour contourner le jugement humain et fonctionner de manière autonome. C’est précisément pour cela qu’ils sont dangereux : nous avons normalisé les opérations cross-border dès l’instant où nous les avons automatisées. » Noma a également recommandé d’appliquer des contrôles d’accès basés sur le principe du moindre privilège, de limiter l’accès des agents IA d’un dépôt à l’autre, et de traiter les tickets GitHub, les requêtes pull et les commentaires comme des données non fiables.