Les agents IA de GitHub peuvent faire fuiter un dépôt privé via une injection de prompt
En postant un simple message d’erreur dans un dépôt public GitHub, des chercheurs en sécurité ont montré qu’il était possible de pousser les agents IA de GitHub pilotant les « workflows » d’un projet de développement à livrer des informations provenant d’un autre dépôt privé d’une même organisation. Un simple ticket rapportant une erreur dans […].
En février 2024, GitHub, une plateforme en ligne dédiée au partage de code source et à la collaboration entre développeurs, a lancé une fonctionnalité expérimentale appelée GitHub Agentic Workflows (flux de travail agentiques GitHub). Ces agents IA sont conçus pour automatiser des tâches comme la gestion de la documentation, le traitement des erreurs signalées dans les tickets (demandes d’assistance) ou l’amélioration du code. Ils peuvent utiliser des outils externes comme Copilot CLI, Claude Code ou OpenAI Codex pour accomplir ces missions. Le 11 juin 2024, cette fonctionnalité est passée en préversion publique, accessible à un plus grand nombre d’utilisateurs. GitHub affirmait alors que ces agents étaient protégés par plusieurs niveaux de sécurité, comme un sandbox (environnement isolé) et des autorisations en lecture seule, limitant ainsi les risques d’accès non autorisé aux données.
Des chercheurs en sécurité de l’entreprise Noma ont identifié une faille majeure dans ces agents IA, nommée GitLost. Cette faille permet de contourner les protections mises en place par GitHub en utilisant une technique appelée injection de prompt. Concrètement, il suffit d’ajouter une question malveillante dans un ticket public, par exemple en se faisant passer pour un responsable d’entreprise. Dans leur test, les chercheurs ont écrit un message simulant un vice-président des ventes demandant le contenu d’un fichier README (documentation d’un projet) situé dans un dépôt privé. L’agent IA, en traitant cette demande, a accédé aux données sensibles et les a rendues publiques en les intégrant à sa réponse.
L’attaque repose sur l’utilisation d’un mot-clé simple, Additionally, qui a suffi à tromper les contrôles de sécurité de GitHub. Les chercheurs ont montré que l’agent IA, en analysant le ticket public, a interprété cette demande comme une tâche légitime à exécuter. Malgré les protections annoncées par GitHub (sandbox, autorisations restreintes, validation des résultats), l’agent a accédé à un dépôt privé lié à l’organisation et a partagé son contenu. Cette faille illustre un problème récurrent avec les agents IA : leur sensibilité aux injections de prompts, où une formulation habile peut les inciter à réaliser des actions non prévues.
Cette faille soulève des inquiétudes majeures quant à la sécurité des données sensibles hébergées sur GitHub. En effet, les agents IA, conçus pour automatiser des tâches, peuvent involontairement exposer des informations confidentielles (comme des fichiers README, des codes sources ou des configurations) si une demande malveillante est formulée de manière suffisamment convaincante. Les chercheurs de Noma qualifient ce trio de vulnérabilités de « trio mortel pour les agents IA » : l’accès à des données sensibles, le traitement de contenus non fiables et la communication externe non contrôlée par l’agent lui-même. GitHub, de son côté, reconnaît dans sa documentation que les agents IA peuvent être manipulés par des injections de prompts ou des outils compromis.
GitHub a mis en avant ses multiples couches de protection, comme le *sandboxing* (exécution du code dans un environnement isolé), les autorisations en lecture seule et un processus de validation des résultats. Cependant, l’exemple de *GitLost* montre que ces mesures ne sont pas infaillibles face à des attaques ciblées utilisant des *injections de prompts*. L’entreprise admet elle-même que ses agents peuvent être vulnérables à ce type de manipulation, malgré les contrôles mis en place. Cette faille intervient dans un contexte où la confiance des développeurs envers GitHub est déjà fragilisée, comme en témoigne un autre article publié le 29 avril 2026 évoquant une *« perte de fiabilité et de développeurs »* pour la plateforme.
