GitLost : un agent GitHub fuit des dépôts privés

Qu'est-ce que GitLost ?

GitLost est le nom donné par Noma Labs (auteur : Sasi Levi) à une vulnérabilité des GitHub Agentic Workflows, la fonction qui permet de confier à un agent IA des tâches de dépôt comme le tri d'issues ou la réponse aux contributeurs. Un attaquant qui peut ouvrir une issue dans un dépôt public d'une organisation utilisant ce type de workflow peut obtenir que l'agent lise des dépôts privés et en recopie le contenu publiquement.

L'attaquant n'a besoin ni de compétences particulières, ni d'accès, ni d'identifiants. Il lui suffit d'ouvrir une issue dans un dépôt public de l'organisation, puis d'attendre l'exécution du workflow.

Comment l'attaque se déroule-t-elle ?

Dans la configuration démontrée par Noma, le workflow se déclenchait sur les événements issues.assigned, lisait le titre et le corps de l'issue et répondait avec l'outil d'ajout de commentaire. Il s'exécutait avec un accès en lecture aux autres dépôts de l'organisation, publics et privés. Noma indique avoir obtenu le même comportement avec d'autres déclencheurs.

1. L'attaquant ouvre une issue publique rédigée pour ressembler à une demande plausible d'un responsable commercial après un rendez-vous client.
2. Le workflow se déclenche. L'agent, suivant les instructions cachées dans le texte, lit les fichiers README d'un dépôt public et d'un dépôt privé.
3. L'agent publie le contenu récupéré sous forme de commentaire sur l'issue publique, lisible par tous.

Que change le mot « Additionally » ?

GitHub avait mis en place des garde-fous censés empêcher ce scénario. Au fil d'essais répétés, Noma a constaté que l'ajout du mot « Additionally » dans les instructions injectées amenait le modèle à reformuler sa sortie au lieu de refuser. Ce détail illustre une limite connue : un garde-fou fondé sur le comportement du modèle se contourne par la reformulation et ne constitue pas une barrière.

Est-ce un bogue qu'un correctif résoudra ?

Plusieurs analyses le décrivent comme un problème d'architecture : le workflow donne à l'agent des identifiants persistants vers des dépôts privés tout en l'exposant à du contenu contrôlé par un attaquant. Noma écrit seulement avoir divulgué la faille de manière responsable à GitHub ; les articles consultés ne donnent ni calendrier de réponse ni détail d'un correctif. GitHub Agentic Workflows restait en préversion publique à la date des articles.

Ce schéma réunit les trois conditions du risque agentique : accès à des données privées, exposition à du contenu non fiable, capacité de communiquer vers l'extérieur. Voir la page prompt injection et l'article sur l'injection indirecte.

Comment vérifier si vos workflows sont exposés ?

1. Inventaire : listez les workflows agentiques de chaque organisation, leurs déclencheurs et les dépôts qu'ils peuvent lire.
2. Déclencheurs publics : repérez ceux qui réagissent à du contenu que n'importe qui peut créer (issues, commentaires, pull requests de forks).
3. Portée des jetons : vérifiez si le jeton du workflow donne accès à d'autres dépôts, en particulier privés.
4. Canaux de sortie : l'agent peut-il publier un commentaire, ouvrir une pull request ou appeler une URL à partir de ce qu'il lit ?
5. Test sur un dépôt de test : ouvrez une issue contenant une instruction traçable demandant de recopier un fichier d'un dépôt privé de test, et observez le commentaire produit.
6. Variantes : essayez différentes formulations (« Additionally », contexte métier crédible, instruction en plusieurs étapes) pour mesurer la solidité du garde-fou.
7. Passé : relisez les commentaires d'issues récents d'un agent pour y repérer du code ou du texte qui n'aurait pas dû être public.

Quelles mesures réduisent le risque ?

Noma recommande de ne jamais traiter du contenu contrôlé par l'utilisateur comme une instruction fiable, de réduire les permissions au minimum, de limiter ce que l'agent peut publier publiquement et d'isoler l'entrée utilisateur du contexte d'instruction.

• Moindre privilège : le workflow qui lit des issues publiques n'a accès qu'au dépôt concerné, jamais à d'autres dépôts privés.
• Séparation : un agent pour le contenu public, un autre, sans exposition, pour le contenu privé.
• Validation humaine avant toute publication issue d'un dépôt privé.
• Contrôle des sorties : détecter les fragments de code ou de fichiers privés dans une réponse avant publication.
• Journalisation des lectures de dépôts effectuées par les agents.

Le cadre général est décrit dans la page sécurité des agents IA.

Comment concevoir des workflows agentiques plus sûrs ?

En traitant chaque workflow comme un petit service exposé à Internet, avec son propre périmètre de droits. Quatre schémas de conception réduisent fortement l'exposition.

1. Un workflow, un dépôt : le jeton du workflow est limité au dépôt qu'il sert. Si l'agent a besoin d'une information d'un autre dépôt, elle lui est fournie par une étape séparée, validée, qui n'expose pas le dépôt entier.
2. Lecture et publication séparées : l'agent qui lit du contenu public ne publie rien directement ; une seconde étape, déterministe, valide le format et le contenu de la réponse avant de la poster.
3. Liste d'actions autorisées : l'agent ne peut appeler que les outils nécessaires (ajouter une étiquette, par exemple) et pas un outil de commentaire libre quand un modèle de réponse suffit.
4. Déclencheurs prudents : limitez les workflows sensibles aux issues créées par des membres de l'organisation, et mettez en attente celles venant d'inconnus jusqu'à une revue humaine.

Ces choix coûtent peu à mettre en place et suppriment le cœur du problème : l'agent ne détient plus à la fois les données privées et la capacité de les publier.

Quels signaux de détection surveiller après coup ?

Si vous avez déjà des workflows agentiques actifs, cherchez des traces d'abus dans l'historique.

• Des commentaires d'agents qui contiennent des extraits de README, de fichiers de configuration ou de code d'un autre dépôt.
• Des issues récentes dont le texte contient des instructions adressées à un assistant (« demande de la part de la direction », « merci de joindre le contenu de... »).
• Des exécutions de workflows déclenchées par des comptes sans historique de contribution.
• Des lectures inhabituelles de dépôts privés dans les journaux d'audit de l'organisation, corrélées à une exécution d'agent.

Si vous trouvez un cas, supprimez le commentaire, considérez le contenu comme public pendant la période d'exposition, faites tourner les secrets qu'il pouvait contenir et documentez la chronologie.

Que retenir pour vos agents ?

Le modèle a été serviable plutôt que piraté. Il a traité un texte public comme une demande légitime et utilisé les accès qu'on lui avait donnés. La protection repose sur ce qu'il peut lire et publier.

Le Red Team Agent Express de CleanIssue (1 900 €, 5 jours) attaque votre agent avec ces scénarios et livre un rapport avec preuves : voir l'offre. Le rendez-vous découverte, 30 minutes et gratuit, sert à établir quels dépôts privés votre agent GitHub peut lire et rendre visibles.

Pour aller plus loin

• détournement d'agent via commentaire de PR
• injection de prompt via une dépendance