Les résultats soulèvent de nouvelles inquiétudes quant à la sécurité des agents d’IA disposant d’un accès privilégié au code de l’entreprise.
Selon une nouvelle étude de Noma Security, une attaque par injection rapide peut inciter les flux de travail agents d’avant-première de GitHub à récupérer le contenu de référentiels privés et à le publier publiquement, exposant ainsi un risque plus large à mesure que les entreprises déploient des agents d’IA avec un accès privilégié aux environnements de développement logiciel.
La société de sécurité IA a détaillé l’attaque, baptisée GitLost, dans un article de blog, affirmant qu’un attaquant non authentifié pourrait exploiter l’aperçu des flux de travail agentiques de GitHub en soumettant un problème GitHub contrefait à un référentiel public. Si l’agent IA dispose d’un accès en lecture aux référentiels privés au sein de la même organisation, il peut récupérer des informations sensibles et les publier dans un commentaire public, a indiqué la société.
Les workflows agentiques GitHub combinent les actions GitHub avec des modèles d’IA tels que Claude ou GitHub Copilot, permettant aux développeurs de définir des workflows dans Markdown. Dans le même temps, les agents IA lisent les problèmes, invoquent des outils et effectuent des tâches en leur nom.
« Que se passera-t-il lorsque l’agent GitHub lit quelque chose auquel il ne devrait pas faire confiance ? » » a écrit Sasi Levi, chercheur au Noma. « La réponse est une attaque par injection indirecte classique, le type d’attaque qui envoie discrètement des données privées à n’importe qui sur Internet. »
Le problème public de GitHub est devenu le vecteur d’attaque
Selon Noma, l’attaque ne reposait pas sur des informations d’identification volées, des logiciels malveillants ou des vulnérabilités logicielles. Au lieu de cela, un attaquant a intégré des instructions cachées dans un problème GitHub soumis à un référentiel public.
Parce que l’agent d’IA a interprété le problème comme des instructions plutôt que comme un contenu non fiable, il a accédé à un référentiel privé et a publié son contenu dans le problème public, ajoute le blog.
« La cause première de la vulnérabilité GitLost est désormais familière dans les systèmes d’IA agentique : l’injection rapide », a écrit Levi. « Dans ce cas précis, tout acteur malveillant peut créer un problème GitHub et, dans le corps du problème, masquer les commandes en anglais simple que l’agent GitHub suivra. »
Pour démontrer l’attaque, les chercheurs ont créé ce qui semblait être un problème GitHub de routine demandant des mises à jour de la documentation. Une fois le workflow déclenché, l’agent IA a récupéré le fichier README dans un référentiel privé et a publié son contenu dans un commentaire visible publiquement.
Les chercheurs ont également déclaré qu’ils avaient contourné les garde-fous basés sur les invites de GitHub en apportant une modification mineure à la formulation qui obligeait l’agent IA à se conformer aux instructions qu’il avait précédemment rejetées.
GitHub n’a pas immédiatement répondu à une demande de commentaire.
La recherche souligne un risque plus large lié aux agents d’IA
Noma a déclaré que GitLost illustre un défi architectural plus large pour les agents d’IA plutôt qu’une faille unique à GitHub.
« Le problème n’est pas que l’agent IA de GitHub soit particulièrement peu sécurisé », a écrit Levi. « Le problème est que tout agent d’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 appliquées. »
Vibhum Dubey, chercheur indépendant en cybersécurité et membre de l’équipe rouge, a déclaré que les résultats exposent un problème plus fondamental que la seule injection rapide.
« Il ne s’agit pas d’une injection rapide dans l’abstrait : il s’agit des autorisations des agents d’expédition GitHub avant la sécurité des agents d’expédition », a déclaré Dubey. « La vulnérabilité révèle que les agents IA fonctionnent sur un modèle d’autorisation de compte de service, et non sur un modèle d’autorisation d’utilisateur. Il s’agit d’une hypothèse architecturale que les équipes de sécurité ont formulée avant de considérer les LLM comme vecteur d’attaque. »
Selon Dubey, l’injection rapide elle-même est presque secondaire.
« Ce qui est dangereux, c’est que des 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 déclaré. » L’agent ne » sait » pas qu’un référentiel est privé. Il voit simplement » accessible « . À mesure que de plus en plus d’organisations déploient des agents, nous accumulons ces lacunes invisibles en matière d’autorisation.
Les experts appellent à des contrôles plus stricts sur les agents IA
Dubey a déclaré que les organisations devraient repenser la manière dont les agents d’IA obtiennent des autorisations plutôt que de traiter le problème principalement comme un défi de surveillance.
« Trois solutions concrètes : les agents obtiennent des listes blanches de référentiels explicites, et non un accès étendu aux comptes de service. Toutes les entrées des utilisateurs, y compris les messages de validation, les descriptions de relations publiques et les problèmes, doivent être validées avant d’atteindre le LLM. Et disposer d’un kill-switch d’urgence », a-t-il déclaré. « La plupart des équipes peuvent désactiver une clé API compromise. Pouvez-vous désactiver un agent malveillant ? »
Dubey a déclaré que GitLost démontre comment les agents d’IA peuvent effectivement devenir une menace interne une fois qu’un large accès organisationnel leur est accordé.
« Le génie de GitLost n’est pas qu’il a trompé une IA. C’est qu’il a militarisé l’hypothèse de GitHub selon laquelle les comptes de service sont dignes de confiance », a-t-il déclaré. « Les agents ont été explicitement conçus pour contourner le jugement humain et fonctionner de manière autonome. C’est exactement pourquoi ils sont dangereux : nous avons normalisé les opérations transfrontalières au moment où nous les avons automatisées. » Noma a également recommandé d’appliquer des contrôles d’accès de moindre privilège, de limiter l’accès inter-référentiel des agents IA et de traiter les problèmes GitHub, les demandes d’extraction et les commentaires comme des entrées non fiables.
