GitLost prouve que votre agent IA peut divulguer vos données sans même être piraté
Un attaquant n’a eu besoin ni de mot de passe volé, ni d’e-mail de phishing, ni d’une chaîne d’exploits pour extraire du code source privé d’une organisation GitHub. Une seule phrase, saisie dans un ticket GitHub public, a suffi. Les chercheurs en sécurité de Noma Labs ont révélé la faille le 6 juillet 2026 et l’ont baptisée GitLost. Elle réside dans les Agentic Workflows de GitHub, qui associent GitHub Actions à un agent IA basé sur Claude ou GitHub Copilot, et il ne s’agit pas d’un bug au sens classique. Cette faille démontre ce qui se produit lorsqu’un agent IA reçoit plus d’autorisations que nécessaire pour une tâche donnée, puis se voit confier la lecture de contenus non vérifiés.
Voici le cœur du problème : l’agent n’a pas été piraté. Il a fait ce pour quoi il a été conçu. Il a lu un ticket, suivi les instructions cachées dans ce ticket, et utilisé l’outil à sa disposition — publier un commentaire public — pour remettre à un inconnu le contenu d’un dépôt privé. Dark Reading a rapporté que GitHub a mis à jour sa documentation en réaction. Selon Noma, la faille de conception sous-jacente était toujours active à la date de publication.
Cette distinction compte plus que la vulnérabilité elle-même. Les équipes de sécurité ont passé vingt ans à bâtir des systèmes de détection autour des accès non autorisés — identifiants volés, élévation de privilèges, mouvements latéraux. GitLost a contourné tout cela. L’agent était autorisé. Il faisait exactement ce pour quoi il avait été conçu. Il n’était simplement pas censé pouvoir accéder à ce qu’il a atteint.
Résumé de l’incident
1. Une phrase, zéro identifiant.
Noma Labs, la branche recherche de Noma Security, a exfiltré des données privées de dépôts GitHub en cachant une instruction en anglais courant dans un ticket public — sans compromission de compte, ni malware, ni compétence en codage.
2. La barrière a cédé sur un seul mot.
Le simple fait de commencer l’instruction injectée par « Additionally » a suffi à faire considérer à l’agent IA de GitHub une prise de contrôle comme une tâche légitime, au lieu d’un ordre à refuser.
3. L’échec vient de l’accès, pas de l’intelligence.
L’agent compromis disposait d’un accès en lecture permanent à tous les dépôts publics et privés de l’organisation pour accomplir une simple tâche de triage. Il s’agit d’une exposition de propriété intellectuelle à l’échelle de l’organisation, et non d’une vulnérabilité ponctuelle.
4. Ce schéma est désormais la norme, pas une exception.
Le projet GenAI Security d’OWASP relie l’injection de prompts à six des dix catégories de son Top 10 pour les applications agentiques et la désigne comme la principale cause des échecs de sécurité IA agentique en production.
5. La plupart des organisations ne voient même pas l’écart, encore moins comment le combler.
Selon la Cloud Security Alliance, moins d’une organisation sur quatre dispose de règles documentées de gouvernance des identités IA, et seules 12 % se disent très confiantes dans leur capacité à stopper une attaque menée via une identité non humaine. Un audit des risques, qui cartographie l’accès réel de chaque agent IA par rapport au strict nécessaire pour sa tâche, constitue le point de départ pour combler cette faille.
Que s’est-il passé : dans la chaîne d’attaque GitLost
Le workflow ciblé par Noma Labs était banal. Il se déclenchait lorsqu’un ticket était assigné, lisait le titre et le corps du ticket, puis publiait une réponse via l’outil de commentaire de l’agent. Pour cela, il fonctionnait avec un accès en lecture à tous les autres dépôts de l’organisation — publics et privés.
Un attaquant sans identifiants, sans accès aux dépôts et sans compétence technique a ouvert un ticket public qui ressemblait à une demande interne classique. Cachée dans le corps du ticket, une instruction en anglais ordonnait à l’agent d’aller chercher un fichier dans un dépôt privé et d’en coller le contenu dans un commentaire public. Lors de l’assignation du ticket, l’agent a lu le texte, traité l’instruction cachée comme une partie normale de sa tâche, récupéré le fichier privé et l’a publié publiquement. La preuve de concept de Noma a permis d’exfiltrer des données privées de dépôt en quelques minutes.
Pas de malware. Pas d’exploitation. Pas de prise de contrôle de compte. Juste du texte, inséré dans un contenu que l’agent était censé lire dans le cadre de son travail habituel.
C’est ce point que tout RSSI doit retenir. Il ne s’agit pas d’un échec des contrôles d’accès au sens habituel. L’agent disposait des droits pour lesquels il avait été configuré. La faille vient de ce que « configuré » signifiait ici. Tout fichier de dépôt privé accessible à un agent sans vérification d’autorisation à chaque requête devient un vecteur potentiel d’exfiltration — la classification des données appliquée au contenu des dépôts permettrait au moins d’identifier les actifs présentant le plus grand risque réglementaire ou concurrentiel en cas de fuite.
La barrière a cédé sur un seul mot
GitHub avait pourtant mis en place des garde-fous pour empêcher cela. Les chercheurs de Noma ont testé le workflow comme l’aurait fait un attaquant, en modifiant la formulation jusqu’à trouver celle qui fonctionne. Ce qui a marché était d’une simplicité déconcertante : commencer l’instruction injectée par le mot « Additionally ».
Lisez bien : un seul mot, choisi parce qu’il présentait la tentative de détournement comme une suite logique de la tâche, a suffi pour que le modèle obéisse au lieu de refuser.
Voilà qui devrait inquiéter tous ceux qui misent leur sécurité IA sur des filtres au niveau du prompt. Une défense qu’un simple connecteur peut contourner n’est pas une défense. Ce n’est qu’un ralentisseur, et les ralentisseurs n’arrêtent pas des attaquants qui peuvent tester à l’infini, en privé, jusqu’à ce que ça passe.
L’injection de prompts n’est plus un risque théorique
GitLost n’est pas une anomalie. C’est la règle. Le projet GenAI Security d’OWASP (State of Agentic AI Security and Governance, version 2.01) relie l’injection de prompts à six des dix catégories de son Top 10 pour les applications agentiques — et selon Help Net Security qui relaie les conclusions du groupe en 2026, l’injection de prompts est identifiée comme la principale cause des échecs de sécurité IA agentique actuellement observés en production.
La cause racine est architecturale, et non un simple défaut d’entraînement que de meilleurs modèles combleraient. Les grands modèles de langage traitent le prompt système, la requête utilisateur et tout texte externe comme un seul flux de tokens. Il n’existe aucun mécanisme fiable pour marquer certains tokens comme des commandes de confiance et d’autres comme des données non fiables. Une phrase malveillante cachée dans un ticket GitHub, une invitation calendrier ou un e-mail client a exactement le même poids pour le modèle qu’une instruction de son véritable opérateur.
C’est cette réalité architecturale qui explique pourquoi « il suffit d’écrire un meilleur prompt système » échoue systématiquement, GitLost inclus.
Les preuves ne s’arrêtent pas à GitLost. Des chercheurs ont révélé la CVE-2025-6514, une faille d’exécution de code à distance notée 9,6 sur l’échelle CVSS, dans un package Model Context Protocol largement utilisé, après quinze versions saines, lorsqu’une ligne d’exfiltration a été discrètement ajoutée, selon les conclusions citées par OWASP et relayées par Help Net Security. Par ailleurs, la CVE-2026-22708 visant l’agent de codage Cursor a montré qu’un attaquant qui empoisonne l’environnement d’exécution d’un agent peut transformer ses propres commandes sur liste blanche en vecteur de livraison de charges arbitraires — la liste blanche a facilité l’attaque, car elle a validé d’office les commandes nécessaires à l’attaquant. La CVE-2025-59532 contre Codex CLI d’OpenAI a démontré que la sortie d’un agent pouvait redéfinir la frontière de son bac à sable.
Trois fournisseurs différents, trois mécanismes différents, une cause racine commune : un agent a fait confiance à du contenu ou des commandes qu’il aurait dû traiter comme malveillants, et personne n’a suffisamment restreint son accès pour limiter les conséquences. Une fuite de données par l’un de ces vecteurs entraîne les mêmes obligations de notification réglementaire qu’une compromission d’identifiants — le canal d’exfiltration est l’IA, mais le compte à rebours réglementaire démarre dès la découverte dans tous les cas.
Vous pensez que votre organisation est sécurisée. Mais pouvez-vous le prouver ?
Pour en savoir plus :
La vraie vulnérabilité, c’est l’accès permanent, pas le comportement du modèle
C’est là que ça devient inconfortable. Après un incident de ce type, le réflexe du secteur est d’interroger le modèle : pourquoi a-t-il cédé à « Additionally », quel filtre aurait dû l’arrêter, quel fournisseur corrigera le premier. Ce réflexe traite le symptôme comme la maladie.
L’agent GitLost n’avait besoin que de l’autorisation de lire un ticket dans un dépôt pour remplir sa mission. Il disposait d’un accès en lecture permanent à tous les dépôts de l’organisation, publics et privés, sans limite de durée. C’est cet écart entre ce qu’exige une tâche et ce qu’on accorde à une identité qui a causé tout le dommage. L’injection de prompt n’a été que le déclencheur.
Appelons-le par son nom : l’agent tout-puissant. Les organisations provisionnent les agents IA comme les services IT provisionnaient les comptes de service en 2005 : accès large, permanent, rarement audité — sauf que désormais, ces identifiants sont derrière un système qu’on peut convaincre d’agir simplement en tapant une phrase.
Le rapport de la Cloud Security Alliance sur la sécurité des identités non humaines et de l’IA chiffre précisément l’ampleur de cette faille. Moins d’une organisation sur quatre dispose de règles formellement adoptées pour la création ou la suppression des identités IA. Seules 12 % se disent très confiantes dans leur capacité à empêcher une attaque menée via une identité non humaine. Plus de 16 % ne suivent même pas la création de nouvelles identités IA, laissant ainsi une population croissante d’agents pratiquement invisibles pour les programmes de gouvernance des données conçus pour les comptes humains.
Douze pour cent. Ce n’est pas une marge d’erreur dans un modèle de maturité. C’est près de neuf responsables sécurité sur dix qui admettent, lorsqu’on leur pose la question, qu’ils ne pourraient pas stopper ce type d’incident s’il survenait demain. Les programmes de gestion des risques supply chain qui encadrent l’accès des fournisseurs humains mais pas celui des agents IA provisionnés par ces mêmes fournisseurs passent à côté de la population d’identités non humaines qui croît le plus vite dans l’entreprise.
Pourquoi les garde-fous seuls échoueront toujours
Il existe deux réactions intuitives à GitLost, et toutes deux sont erronées.
La première consiste à bloquer l’IA agentique tant que la technologie n’a pas mûri — geler les Agentic Workflows de GitHub, les intégrations Copilot, attendre que les fournisseurs trouvent la solution. Cela revient à renoncer à la productivité qu’apporte un agent qui trie les tickets 24/7, et ne résiste pas à la pression du marché. Les équipes d’ingénierie à qui l’on dit non trouveront un contournement, avec ou sans validation. Ce contournement, c’est l’IA fantôme — des agents non gouvernés, hors du périmètre des règles, sans traçabilité ni revue des accès.
La seconde consiste à faire confiance au modèle. Améliorer les prompts, souscrire à la dernière mise à jour des garde-fous du fournisseur, considérer « Additionally » comme un bug isolé que la prochaine version du modèle corrigera. Le rapport 2026 de Gravitee sur la sécurité des agents IA montre bien le résultat : 88 % des organisations exploitant des agents IA en production ont confirmé ou suspecté un incident de sécurité lié à ces agents au cours de l’année écoulée, alors que 82 % des dirigeants affirment que leurs règles existantes les protègent déjà contre les actions non autorisées des agents.
Les deux affirmations sont vraies. Simultanément. Les dirigeants pensent être couverts. Les données d’incident disent le contraire. C’est dans cet écart entre confiance et réalité que prospèrent les attaques à la GitLost, et aucune ingénierie de prompt n’y changera rien, car le garde-fou se situe au mauvais niveau.
La solution n’est ni de bloquer l’IA, ni de lui faire confiance. Il s’agit d’appliquer à l’accès des agents les mêmes principes que ceux déjà utilisés pour les accès humains — ce que la plupart des organisations n’ont pas encore fait.
La faille de gouvernance cachée derrière l’adoption des agents IA
Toute organisation qui fait tourner un agent IA sur ses propres données a déjà pris, implicitement, une décision sur la portée des accès de cet agent. Presque aucune ne l’a fait de façon délibérée.
L’accès large, permanent et rarement audité est la norme non parce que quelqu’un l’a choisi, mais parce que restreindre l’accès à chaque tâche demande plus d’efforts que de le provisionner une fois pour toutes. C’est le même raccourci qui a produit des autorisations de comptes de service tentaculaires, des rôles IAM oubliés, et des intégrations tierces dont plus personne ne se souvient l’autorisation. L’IA agentique va simplement plus vite, touche plus de systèmes et — comme le montre GitLost — peut être pilotée par n’importe qui capable d’écrire une phrase sur un forum public.
Les recommandations de Noma aux concepteurs sont explicites : ne jamais traiter un contenu contrôlé par l’utilisateur comme une instruction de confiance, limiter ce qu’un agent peut publier publiquement, et — en premier lieu — restreindre les autorisations au strict nécessaire pour la tâche. Deux de ces trois recommandations ne concernent pas le modèle. Elles relèvent de la gouvernance des données, tout simplement. La minimisation des données appliquée à la portée d’accès des agents IA — chaque agent ne disposant que des droits de lecture sur les dépôts, fichiers ou types de données nécessaires à sa tâche — constitue la mise en œuvre opérationnelle de ce principe de gouvernance.
Les régulateurs n’attendent pas que le secteur règle le problème à son rythme. Le rapport OWASP recense 42 instruments réglementaires distincts dans 10 juridictions qui traitent déjà de la gestion des incidents IA, et plusieurs imposent des délais de notification en heures, pas en trimestres. Une organisation incapable de répondre à « qu’est-ce que cet agent pouvait atteindre » le jour d’un incident ne répondra pas assez vite pour satisfaire un régulateur, encore moins un client. Un plan de réponse aux incidents documenté, couvrant explicitement les scénarios d’exfiltration par agent IA — y compris un guide d’action pour le scénario « l’agent a publié des données privées », tel que démontré par GitLost — transforme une gestion de crise chaotique en une réponse maîtrisée et rapide.
Ce qui comble réellement la faille : accès des agents IA restreint et gouverné
Cessez de vous demander si votre modèle est assez intelligent pour résister aux mauvaises instructions. Voici la vraie question : si cet agent est détourné maintenant, à quoi peut-il accéder ?
Pour y répondre, il faut quatre contrôles précis, pas une vague promesse de « gouvernance IA ».
- Restreindre l’accès à la tâche, pas à l’identité. Un agent chargé de trier un ticket n’a pas besoin d’une visibilité permanente sur tous les dépôts privés de l’organisation. Les règles RBAC et ABAC qui évaluent chaque requête selon la classification, la sensibilité et le contexte — au lieu d’accorder une autorisation large et permanente — limitent l’impact à ce que la tâche exige réellement. C’est le même principe du moindre privilège appliqué depuis vingt ans aux comptes humains, enfin étendu aux identités qui les dépassent désormais en nombre.
- Isoler les identifiants du modèle de raisonnement. Les tokens utilisés par un agent doivent être stockés dans un trousseau ou un coffre-fort auquel le modèle de langage n’a jamais accès. Kiteworks a conçu son Serveur MCP Sécurisé précisément sur ce principe : les identifiants OAuth sont stockés dans le gestionnaire d’identifiants du système d’exploitation et ne sont jamais exposés au contexte du LLM, de sorte qu’un agent compromis ne peut pas extraire les clés pour aller au-delà de la session en cours.
- Gouverner la couche données indépendamment des intentions déclarées de l’agent. L’objectif affiché par un agent n’est pas un contrôle de sécurité — c’est une suggestion générée par l’agent lui-même. Kiteworks Compliant AI applique les décisions RBAC et ABAC au niveau du contenu pour chaque requête IA, évaluées en temps réel, indépendamment de ce que l’agent estime pouvoir faire. Le tableau de bord RSSI affiche en temps réel tous les accès IA aux données, offrant aux équipes sécurité la visibilité comportementale nécessaire pour détecter une activité anormale avant toute exfiltration.
- Considérer que le canal d’exfiltration sera l’outil légitime déjà à disposition de l’agent, et auditer en conséquence. GitLost n’a pas nécessité de nouvelle fonction. Il a détourné la publication de commentaires, une fonction prévue pour l’agent. Des journaux d’audit complets et infalsifiables de chaque fichier manipulé et de chaque sortie de l’agent transforment un incident en une recherche forensique de cinq minutes, et font toute la différence entre supposer ce qu’un agent a fait et pouvoir le prouver. L’alimentation de ces logs en temps réel dans une plateforme SIEM permet aux équipes sécurité de détecter des schémas d’exfiltration multi-étapes qu’un seul journal ne suffirait pas à révéler.
Aucun de ces contrôles n’empêche l’injection de prompt. Rien sur le marché ne le fait aujourd’hui. Ce qui détermine si une injection devient une fuite, ce n’est pas si le modèle se laisse tromper. C’est si l’agent qui s’est fait piéger avait accès à des données de valeur.
Que faire dès lundi matin
Cessez de débattre du fournisseur IA qui a les meilleurs garde-fous. Commencez à auditer ce que vos agents peuvent réellement atteindre.
Récupérez la liste des autorisations de chaque agent IA ou workflow automatisé ayant accès à vos dépôts, stockages de fichiers ou environnement Zero Trust Data Exchange. Pour chacun, notez ce que l’agent est censé faire et comparez-le à ce à quoi il est effectivement autorisé à accéder. Toute divergence entre ces deux listes est un GitLost en puissance.
Corrigez ensuite la faille au niveau des accès, pas au niveau du prompt. Limitez les droits à la tâche. Isolez les identifiants de tout ce que le modèle peut voir ou influencer. Faites passer chaque requête de données IA par une politique d’application qui se moque de l’intention affichée par l’agent. Tracez tout comme si un auditeur allait le demander, car cela arrivera un jour.
Les organisations qui subiront la prochaine version de GitLost seront celles qui débattent encore du modèle le plus sûr, au lieu de se demander ce que leurs agents n’auraient jamais dû pouvoir atteindre.
Pour en savoir plus sur la gouvernance des accès aux données des agents IA avant qu’un incident de type GitLost ne touche votre organisation, réservez votre démo sans attendre !
Foire aux questions
GitLost est une faille d’injection de prompt révélée par Noma Labs le 6 juillet 2026 dans les Agentic Workflows de GitHub. Un attaquant dissimule des instructions en anglais courant dans un ticket public ; lorsqu’un agent IA disposant d’un accès en lecture permanent aux dépôts de l’organisation traite ce ticket, il suit les instructions cachées et publie les données du dépôt privé dans un commentaire public. Aucun identifiant, malware ou compétence technique n’est requis. Les organisations qui évaluent leurs stratégies de protection des données IA doivent considérer ce cas comme représentatif d’une classe de risques plus large, et non comme un bug isolé de GitHub. Un audit des risques, qui cartographie l’accès réel de chaque agent IA par rapport à l’inventaire des tâches qui lui sont attribuées, est fondamental : sans cela, impossible de répondre précisément à la question « qu’est-ce que nos agents pouvaient atteindre ? » en cas de contrôle réglementaire ou d’obligation de notification client.
Les chercheurs de Noma ont constaté que le fait de commencer l’instruction injectée par le mot « Additionally » poussait le modèle à interpréter la prise de contrôle comme une suite logique de la tâche, et non comme un ordre à refuser. Les filtres au niveau du prompt fonctionnent sur la formulation, et celle-ci est infiniment modulable — un filtre calibré pour détecter la formulation du jour passera à côté du synonyme de demain. C’est pourquoi les principes de Zero Trust Architecture, qui considèrent que toute requête peut être malveillante quelle que soit sa formulation, sont plus importants qu’une détection linguistique améliorée. La classification des données appliquée au contenu accessible par un agent ne bloque pas l’injection, mais limite les actifs classifiés exposés — un agent qui n’a accès qu’à du contenu public ne pourra pas exfiltrer du code source confidentiel, peu importe les instructions reçues.
Ce n’est pas un cas isolé. Le projet GenAI Security d’OWASP relie l’injection de prompts à six des dix catégories de son Top 10 pour les applications agentiques et l’identifie comme la principale cause des échecs de sécurité IA agentique actuellement observés en production, selon Help Net Security (juin 2026). Le rapport 2026 de Gravitee sur la sécurité des agents IA a également révélé que 88 % des organisations exploitant des agents IA en production ont confirmé ou suspecté un incident de sécurité lié à ces agents sur l’année écoulée, ce qui explique pourquoi les programmes de protection des données IA ne peuvent plus traiter l’injection de prompts comme une exception. Les organisations soumises à des obligations de conformité réglementaire — HIPAA, CMMC, RGPD — doivent considérer la conclusion d’OWASP sur l’injection de prompts comme un risque documenté à traiter dans leur gouvernance IA, et non comme un bug à reporter en attendant un correctif.
Limitez l’accès de chaque agent à la tâche précise qu’il exécute, au lieu d’accorder des autorisations larges et permanentes à l’échelle de l’organisation. Isolez les identifiants utilisés par l’agent du contexte du modèle de langage pour qu’un agent compromis ne puisse pas les extraire. Appliquez les décisions RBAC et ABAC au niveau des données pour chaque requête, indépendamment de l’intention affichée par l’agent, et conservez des journaux d’audit complets sur les accès et sorties de chaque agent. C’est le modèle de Kiteworks Compliant AI et du Serveur MCP Sécurisé Kiteworks. Les organisations doivent également documenter un plan de réponse aux incidents couvrant spécifiquement le scénario « un agent IA a publié des données privées » — le compte à rebours de notification, les étapes d’évaluation de la portée et la séquence de communication doivent être définis avant l’incident, pas pendant.
Le rapport de la Cloud Security Alliance sur la sécurité des identités non humaines et de l’IA montre que moins d’une organisation sur quatre dispose de règles documentées et formellement adoptées pour la création ou la suppression des identités IA, et que seules 12 % se disent très confiantes dans leur capacité à empêcher une attaque menée via une identité non humaine. Plus de 16 % ne suivent pas du tout la création de nouvelles identités IA, rendant une population croissante d’agents pratiquement invisible pour les programmes de gouvernance des données conçus pour les comptes humains. Les organisations doivent étendre leurs pratiques de gestion des risques supply chain aux identités d’agents IA provisionnées par des fournisseurs tiers — un agent IA d’un fournisseur opérant dans votre organisation GitHub avec des droits larges et permanents représente un risque supply chain que la plupart des cadres actuels de gouvernance fournisseur n’adressent pas explicitement.
Ressources complémentaires
- Article de blog
Stratégies Zero Trust pour une protection abordable de la vie privée liée à l’IA - Article de blog
Comment 77 % des organisations échouent à sécuriser les données IA - eBook
IA et gouvernance : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025 - Article de blog
Il n’existe pas de « –dangerously-skip-permissions » pour vos données - Article de blog
Les régulateurs ne se contentent plus de demander si vous avez une politique IA. Ils veulent des preuves concrètes.