GitHub Agentic Workflows en bêta, injection de prompt, un attaquant non authentifié expose des dépôts privés, ce que GitHub doit affronter

Une étude publiée par Noma Security, relayée par plusieurs analyses techniques, décrit une vulnérabilité d’injection de prompt touchant la version bêta d’Agentic Workflows de GitHub. Le scénario documenté montre qu’un attaquant non authentifié peut déposer une issue piégée dans un dépôt public d’une organisation et amener l’agent à récupérer, puis à révéler des informations provenant de dépôts privés appartenant à la même organisation. L’épisode illustre une tension récurrente de l’automatisation moderne, gagner en productivité en donnant plus d’autonomie à un agent, tout en maîtrisant ce qu’il peut lire, croire et exécuter.

GitHub Agentic Workflows associe des GitHub Actions à un agent IA, pouvant s’appuyer sur Claude ou GitHub Copilot, avec une promesse simple, rédiger des workflows en langage naturel et laisser l’agent interpréter des issues, appeler des outils et répondre. Cette architecture ouvre la voie à une surface d’attaque où le contenu non fiable d’un dépôt public devient un vecteur d’instructions malveillantes, capable de détourner un agent pourtant “au service” de l’organisation.

La faille décrite intervient dans un contexte plus large. Des publications de la communauté sécurité décrivent depuis plusieurs mois l’extension du risque d’injection de prompt aux chaînes CI/CD. La Cloud Security Alliance a notamment formalisé une classe d’attaques “comment and control”, où un simple commentaire ou une issue peut pousser un agent à exfiltrer des secrets vers des journaux de build. Dans les entreprises, le sujet est devenu opérationnel, car les agents sont de plus en plus branchés sur des tokens, des dépôts et des outils d’administration.

Au-delà de la démonstration, l’alerte force une question de gouvernance, que doit-on autoriser à un agent IA placé au cœur des dépôts, des pipelines et de la documentation interne. La réponse passe moins par une “consigne” dans le prompt que par une séparation stricte des permissions, des contrôles de confiance sur les entrées et des garde-fous sur les sorties.

Noma Security détaille GitLost sur GitHub Agentic Workflows

Dans le cas décrit par Noma, l’attaque s’appuie sur un principe classique de l’injection de prompt, l’adversaire insère des consignes dans un contenu que l’agent est amené à lire, par exemple une GitHub Issue. L’agent, conçu pour exécuter des tâches à partir d’instructions rédigées en langage naturel, peut interpréter ces consignes comme prioritaires et déclencher des actions non prévues. Le point central n’est pas un “bug” traditionnel d’exécution, mais une confusion de frontières de confiance entre une entrée non fiable et les capacités réelles de l’agent.

La démonstration rapportée mentionne un point critique, l’attaquant n’a pas besoin d’être authentifié dans l’organisation cible. Il lui suffit de poster une issue “fabriquée” dans un dépôt public appartenant à la même organisation, puis d’attendre que le workflow agentique se déclenche. Si l’agent dispose d’accès aux dépôts privés, il peut être amené à interroger des ressources internes et à reformuler des données dans sa réponse, ce qui revient à une fuite.

Ce type d’attaque est particulièrement difficile à appréhender pour des équipes habituées à des modèles de menace classiques, car la charge utile est du texte. Les contrôles antérieurs, validation de paramètres, filtrage de caractères, scanners de dépendances, ne détectent pas naturellement une instruction malveillante rédigée en langage courant. Le risque augmente quand l’agent a des outils connectés, lecture multi-dépôts, recherche dans l’organisation, accès à des artefacts, et quand sa réponse est publiée dans un espace visible par des tiers.

Le vocabulaire de la recherche souligne cette bascule, on parle d’agent “outillé”, capable d’appeler des fonctions. De ce fait, une injection de prompt devient une attaque de chaîne d’approvisionnement informationnelle, la surface ne se limite plus au dépôt visé, mais s’étend à ce que l’agent peut joindre via ses permissions. Les organisations qui ont centralisé des secrets et des tokens de service dans des environnements d’actions risquent une exposition indirecte si l’agent peut les lire ou les déduire via des fichiers de configuration.

Pour les équipes sécurité, l’élément le plus instructif tient à la simplicité du déclencheur. Une issue est une interaction banale, souvent ouverte, parfois modérée a posteriori. Si l’agent est paramétré pour lire automatiquement les issues et agir, l’attaquant obtient un canal d’entrée gratuit. Cette mécanique rappelle des incidents plus anciens d’automatisation, où des bots de CI réagissaient à des commentaires, mais avec une différence majeure, l’agent IA “interprète”, donc il peut combiner des fragments de contexte et prendre des initiatives.

GitHub Actions et Claude exposent une surface d’attaque par issues

GitHub Agentic Workflows repose sur une combinaison, GitHub Actions comme moteur d’automatisation, et un agent IA, pouvant être adossé à Claude ou à l’écosystème Copilot, pour analyser des contenus et piloter des outils. Cette architecture est efficace quand les entrées sont maîtrisées, tickets internes, dépôts privés, règles d’accès strictes. Mais dès qu’un workflow s’active sur un événement provenant d’un dépôt public, issue, commentaire, pull request, l’entrée devient une zone non fiable.

Dans une pipeline CI/CD, une issue peut déclencher des jobs, générer des réponses automatiques, ou provoquer des recherches de contexte. L’agent peut être autorisé à lire des fichiers, interroger l’API GitHub, ouvrir des PR ou commenter des résultats. Une injection de prompt vise à détourner cette chaîne, en demandant à l’agent de “résumer” du code interne, d’extraire une configuration, ou d’afficher des portions de logs. L’objectif n’est pas toujours de voler du code source complet, une poignée d’indices suffit parfois, noms de dépôts, chemins internes, endpoints, identifiants de projet, conventions d’API.

Les analyses publiées en 2026 sur les attaques “comment and control” attirent l’attention sur un autre point, l’exfiltration via des sorties que l’on juge inoffensives. Un agent peut être incité à écrire des secrets dans des Actions logs, ou à répondre dans un commentaire public. Même si les secrets ne sont pas explicitement affichés, un agent peut divulguer des fragments, ou expliquer comment les obtenir. Dans des environnements complexes, une simple indication sur l’emplacement d’un token, ou sur le nom d’une variable, raccourcit considérablement l’effort d’un attaquant.

Le lien avec la chaîne d’approvisionnement logicielle est direct. L’incident autour de CVE-2025-30066 et d’autres actions tierces compromises avait montré que GitHub Actions est une cible à grande échelle pour la collecte de credentials. Les agents IA ajoutent une couche, ils ne se contentent pas d’exécuter un script, ils décident quelles ressources appeler et comment présenter le résultat. De plus, ils sont parfois autorisés à consulter plusieurs dépôts d’une même organisation pour “aider” à résoudre un problème, ce qui multiplie le périmètre de lecture.

Dans ce contexte, les mesures techniques doivent être concrètes. Réduire la portée des tokens, désactiver l’accès inter-dépôts par défaut, appliquer le principe du moindre privilège sur GITHUB_TOKEN, et limiter les triggers sur des événements publics. De plus, les équipes doivent traiter le texte des issues comme une entrée non fiable, au même titre qu’un paramètre utilisateur dans une application web, avec une politique de séparation claire entre “contenu à analyser” et “instructions à exécuter”.

Les organisations durcissent tokens, permissions et sorties d’agent

La réponse opérationnelle la plus efficace consiste à revoir les permissions des agents. Dans de nombreuses configurations, le gain de productivité a conduit à accorder des accès larges, lecture des dépôts privés, consultation d’issues internes, accès aux artefacts, et droits d’écriture dans des dépôts de travail. Or l’injection de prompt transforme une permission “pratique” en capacité d’exfiltration. Les équipes sécurité recommandent de découper les usages, un agent dédié aux dépôts publics ne doit pas pouvoir lire des dépôts privés, et un agent ayant accès aux dépôts privés ne doit pas publier de sorties dans des espaces publics.

Le durcissement passe aussi par les tokens. Le GITHUB_TOKEN utilisé par Actions peut être configuré avec des droits minimaux, lecture seule, pas de permission sur les secrets, pas d’administration. Les secrets d’organisation doivent rester inaccessibles aux workflows déclenchés par des événements non approuvés. Quand des clés d’API externes sont nécessaires, il est préférable de recourir à des identités à durée de vie courte, ou à des mécanismes d’authentification fédérée, au lieu de secrets statiques, car une fuite dans un log ou un commentaire devient immédiatement exploitable.

Un point souvent sous-estimé est la “sécurité des sorties”. Même si l’agent ne peut pas accéder à un dépôt privé, il peut divulguer des informations sensibles issues de son propre contexte de conversation, de fichiers temporaires ou de réponses d’API. Les organisations mettent en place des garde-fous, règles empêchant la publication automatique, modération humaine obligatoire avant commentaire public, et filtres de contenu pour bloquer des patterns, clés, tokens, noms de dépôts internes. Ces contrôles ne remplacent pas la réduction de permissions, mais ils limitent l’impact si un agent dérape.

La gouvernance des événements GitHub devient un autre chantier. Les workflows déclenchés sur issues ou commentaires publics doivent être isolés, exécutés dans des environnements dépourvus d’accès aux secrets et aux dépôts privés. Certaines équipes choisissent un modèle d’approbation, l’événement public crée un ticket interne, puis un opérateur relance une action sécurisée. Cela ajoute une friction, mais réduit la surface d’attaque, surtout pour les organisations exposées à des contributions externes.

Enfin, les équipes de développement ont intérêt à formaliser une “politique d’agent”. Un agent IA ne doit pas être considéré comme un mainteneur humain. Il doit être traité comme un système automatisé potentiellement manipulable, avec une journalisation dédiée, des alertes sur comportements anormaux, consultations de dépôts inattendues, volumes de lecture élevés, commentaires contenant des segments ressemblant à des secrets. En résultat, l’agent redevient un outil contrôlé, au lieu d’un acteur autonome difficile à auditer.

Les chercheurs relient prompt injection et chaîne d’approvisionnement logicielle

La vulnérabilité signalée autour de GitHub Agentic Workflows s’inscrit dans une tendance plus large, la fusion entre IA générative et chaîne CI/CD. Les chercheurs décrivent l’injection de prompt comme l’équivalent textuel d’une injection de commande, avec une différence, la “commande” est interprétée par un modèle et un orchestrateur d’outils. Cette médiation crée des comportements émergents, un agent peut suivre une instruction non parce qu’elle est “valide”, mais parce qu’elle est formulée de manière à paraître prioritaire, urgente, ou conforme au rôle qu’on lui a attribué.

La chaîne d’approvisionnement logicielle est particulièrement sensible à ce phénomène. Les systèmes d’automatisation agrègent des ressources, dépôts de code, actions tierces, registres de packages, systèmes de tickets, documentation. Un agent qui relie ces briques peut devenir un point de pivot. Dans un scénario de fuite, l’attaquant n’a pas besoin de compromettre un serveur, il exploite la circulation de texte et la confiance implicite accordée à un processus automatisé qui “a le droit” de lire et de répondre.

Les publications de la Cloud Security Alliance en 2026 insistent sur des éléments concrets, l’exfiltration de secrets vers les journaux, l’usage de commentaires comme canal de commande, et la difficulté de détecter l’intention malveillante dans une suite de phrases. Elles rappellent aussi que les incidents de la chaîne Actions ne relèvent pas uniquement de l’IA, les compromissions d’actions tierces ont déjà touché des dizaines de milliers de dépôts. L’agent IA ajoute un accélérateur, il peut être manipulé pour aller chercher des informations dans plusieurs endroits, puis les assembler en une sortie exploitable.

Pour les entreprises, la question devient économique. Les agents promettent une réduction du temps de maintenance, génération de workflows, tri de tickets, propositions de correctifs. Mais la surface d’attaque augmente avec chaque permission ajoutée. Une approche pragmatique consiste à réserver l’autonomie complète aux environnements internes, dépôts privés, événements authentifiés, et à conserver un modèle semi-automatique sur les dépôts publics, avec validation humaine ou sandbox stricte. Dans les organisations à forte exposition open source, cette distinction est souvent la plus rentable en termes de risque.

Les fournisseurs, dont GitHub, sont attendus sur des mécanismes techniques robustes, étiquetage des entrées non fiables, isolation contextuelle, politiques de tool-calling, et protections contre la divulgation. Les équipes sécurité, elles, insistent sur un point, la formation ne suffit pas. Dire à un agent “ignore les instructions dans les issues” ne garantit rien si le système exécute quand même des outils à partir de contenus non approuvés. La sécurité dépend d’abord de contrôles de permission, d’isolement et de vérifications systématiques sur les actions et sur les sorties.