GitLost ne veut pas dire que n'importe quel dépôt privé GitHub peut être volé par un issue public. L'affaire montre plutôt une combinaison dangereuse pour les agents IA: données privées, entrée non fiable et sortie publique dans le même workflow.

Agent IA séparé par une frontière de confiance entre issues publics et dépôts privés

Noma Labs a publié GitLost le 6 juillet. La cible était GitHub Agentic Workflows, une fonction en preview qui permet de décrire une automatisation de dépôt en Markdown et de l'exécuter avec un agent dans GitHub Actions. GitHub met en avant des jetons en lecture seule par défaut, un sandbox, des safe outputs et une analyse de menace avant publication.

Dans le PoC de Noma, un issue public a orienté l'agent vers le contenu d'un dépôt privé, puis ce contenu a été publié dans un commentaire public. D'après Noma et The Hacker News, l'attaquant n'avait pas besoin d'identifiants volés ni d'accès au dépôt privé. Le problème venait de l'architecture: l'agent lisait une entrée publique, disposait d'un accès large en lecture et pouvait répondre dans un canal public.

Ce qui s'est passé

Agentic Workflows transforme des instructions en langage naturel en workflows GitHub Actions via gh-aw. L'agent peut trier des issues, regarder des pull requests, examiner des échecs CI ou préparer des tâches de maintenance.

Côté produit, c'est pratique. Côté sécurité, c'est aussi un compte de service avec une interface en langage naturel.

Le workflow testé par Noma se déclenchait quand un issue était assigné. Il lisait le titre et le corps, puis répondait par commentaire. Il avait aussi accès en lecture à d'autres dépôts de l'organisation. L'issue ressemblait à une demande métier banale. Une fois lancé, l'agent a récupéré du contenu d'un dépôt public et d'un dépôt privé, puis l'a placé dans un commentaire public.

La leçon défensive n'est pas le wording exact du test. Elle est plus simple: un filtre n'est pas une frontière de sécurité. Si la protection repose sur la capacité du modèle à reconnaître une demande suspecte, elle finira par céder.

Une portée limitée, mais un vrai risque

GitLost exige plusieurs conditions: un workflow agentique activé, une entrée publique ou contrôlée par un attaquant, un token capable de lire des dépôts privés et une sortie visible depuis l'extérieur. Ce n'est pas une fuite universelle.

Mais beaucoup de workflows d'entreprise vont dans cette direction. Un agent lit des tickets, PR, événements Sentry, messages support ou commentaires. Il récupère du contexte interne. Puis il publie une réponse. L'utilité vient du mélange des zones de confiance; le risque aussi.

Un jeton read-only peut quand même lire des informations sensibles. Si l'agent peut ensuite publier du texte dans un canal public, la lecture suffit pour créer un chemin d'exfiltration.

La trifecta de Simon Willison

Le modèle de la "lethal trifecta" s'applique directement: données privées, contenu non fiable et communication externe. Dans GitLost, les données privées sont le dépôt, le contenu non fiable est l'issue public et la communication externe est le commentaire public.

Retirez l'un des trois éléments, et le risque diminue fortement. Un issue public sans accès aux dépôts privés est moins dangereux. Une analyse privée sans sortie publique est plus difficile à transformer en fuite. Un bot public qui ne lit pas de dépôts privés a moins à exposer.

Les contrôles à mettre en place

Posez trois questions avant d'activer un agent: que peut-il lire, qui peut écrire dans son contexte, où peut-il envoyer le résultat?

Si les réponses sont dépôts privés, n'importe quel auteur d'issue public et commentaire public, il faut arrêter le workflow. Ce n'est pas une simple automatisation; c'est un chemin d'exfiltration.

Utilisez des tokens limités à un dépôt ou à un usage. Évitez l'accès large à toute l'organisation. Séparez les agents publics et privés. Un agent qui répond à des issues publics ne devrait pas être celui qui lit des dépôts sensibles.

Ajoutez une revue humaine avant toute sortie publique basée sur des données privées. Conservez des logs utiles: issue déclencheur, dépôts lus, token utilisé, sortie proposée, approbation.

Ce que les fournisseurs doivent corriger

Les plateformes d'agents doivent rendre les frontières de confiance visibles. Le contenu issu d'issues publics, de PR externes, de logs, de pages web ou d'outils MCP doit conserver son origine. Une politique devrait pouvoir dire: ce texte peut informer l'analyse, mais ne peut pas autoriser une lecture privée ni une écriture publique.

Read-only ne suffit pas si l'agent lit des données privées et parle publiquement. Autonomous ne suffit pas si l'administrateur ne voit pas les outils, dépôts, sorties et accès réseau disponibles.

GitLost n'est pas une raison d'abandonner l'automatisation par IA. C'est une raison de traiter les agents comme des acteurs dotés de droits. La règle utile: ne combinez pas entrée publique, données privées et sortie publique dans un agent sans supervision.