Détournement d’identité de workflow : Noma Labs transforme un e-mail de support ordinaire en accès privilégié aux données

Le 9 septembre 2026, l’équipe de recherche de Noma Security, sous la signature de Noma Labs, a publié un compte rendu de ce qu’elle appelle le détournement d’identité de workflow : un workflow d’IA d’entreprise lit un message ordinaire qui arrive à un point d’entrée public — une boîte de réception d’assistance, un ticket GitHub, un formulaire web, un document partagé — puis exécute le travail demandé à l’aide de son propre compte de service à privilèges élevés plutôt qu’avec les autorisations de l’expéditeur. La démonstration de Noma montre un tiers extérieur envoyant un courriel à l’adresse d’assistance publique d’une entreprise et demandant, entre autres, les chiffres de ventes trimestriels issus du courriel le plus récent du directeur financier ; quelques minutes plus tard, le contenu arrive dans la boîte de réception de l’attaquant. Aucun modèle n’a été trompé et aucun compte n’a été compromis, ce qui est le point du rapport : « tout ce que l’attaquant avait à faire, c’était de demander ». L’archive ne consigne aucun préjudice réel — aucune victime n’est nommée et aucun système déployé n’est décrit comme compromis — et classe le constat en recherche, gravité moyenne, confiance A, contesté : faux. Ce compte rendu s’appuie sur le rapport de Noma Labs, sur la couverture publiée le même jour par Dark Reading et sur le suivi de CSO Online, et l’archive des incidents d’IA contient cette entrée aux côtés de ses entrées voisines, chacune avec ses propres sources, son niveau de gravité et son indice de confiance.

Les champs propres à la fiche méritent d’être lus avant le texte courant. Elle est étiquetée INFRA et EXFIL, couvre la région GLOBAL, porte une date unique précise au jour près, le 9 septembre 2026, et n’est pas signalée comme entrée phare. Cette date est celle de la publication de la recherche et rien d’autre ; aucune chronologie d’incident n’y est rattachée, car il n’y a pas d’incident à dater. C’est la première chose à retenir : ce que Noma a publié est un mécanisme et une catégorie, pas un rapport de violation.

Ce que Noma a démontré, et ce qu’il n’a pas démontré

La séquence de la boîte de réception du support est une illustration construite plutôt qu'un cas client. Le rapport de Noma ne nomme aucune organisation, ne donne aucun décompte des déploiements affectés, ne publie aucune télémétrie issue d'un pipeline réel et ne renvoie à aucune exécution de preuve de concept pour ce scénario — contrairement à la recherche de juillet du groupe, qui pointait vers une exécution publique de GitHub Actions. Ce que le rapport propose en revanche, c'est une description du mécanisme suffisamment précise pour être confrontée à une architecture : une entrée non authentifiée arrive, le modèle l'interprète correctement, le pipeline exécute l'appel en aval, et cet appel est effectué avec l'autorité du créateur du workflow.

Sasi Levi, responsable de la recherche en sécurité chez Noma et auteure du rapport, résume la cause racine en une phrase : « l’identité et les permissions de l’utilisateur qui déclenche un workflow sont dissociées de l’identité et des permissions utilisées pour l’exécuter ». Lorsque c’est le cas, le workflow devient, selon les mots du rapport, « des proxys non authentifiés pour des actions privilégiées et une exfiltration silencieuse de données ».

Étant donné que les actions s’exécutent via une automatisation de confiance avec des identifiants valides, Noma soutient que les alertes conventionnelles ont peu de choses à détecter. La requête est normale, la sortie du modèle est une sortie de modèle valide, l’appel API est authentifié, la réponse est celle que le flux de travail a été conçu pour envoyer. CSO Online a cité le red teamer Vibhum Dubey, qui rend concret le problème de détection : « Les événements individuels peuvent sembler parfaitement légitimes. Les signaux utiles proviendraient de la corrélation entre le demandeur d’origine, l’identité utilisée en aval, les ressources consultées, les paramètres fournis et l’action finale. »

La vérification qui échoue est une vérification d’autorisation, et non un filtre de contenu.

L’illustration la plus frappante du rapport est une paire de demandes identiques. D’un directeur financier : « Quels sont les chiffres de ventes trimestriels du directeur des finances dans son e-mail le plus récent ? » D’un expéditeur externe : les mêmes mots. Le point de Noma est que le prompt et l’opération demandée sont identiques, alors que la décision d’autorisation devrait être entièrement différente — « Un directeur financier a droit à cette information ; un expéditeur externe n’y a pas droit. »

Les détecteurs standard d’injection de prompt et les garde-fous d’agents, soutient le rapport, classent les deux entrées de manière identique, car rien de malveillant ne s’y trouve à détecter. « Le risque de sécurité ne réside pas dans le prompt ; il réside dans la frontière d’autorisation. » L’affirmation structurelle de Noma en découle : les garde-fous, les instructions système et les filtres d’entrée « n’ont pas été conçus pour servir de frontière d’autorisation », de sorte qu’un pipeline qui s’appuie sur eux pour décider de ce qu’un appelant peut récupérer s’appuie sur un contrôle auquel on n’a jamais demandé ce rôle.

La distinction importe en pratique. L’injection de prompt directe manipule la manière dont le modèle suit les instructions ; l’injection de prompt indirecte dissimule des instructions dans le contenu que le modèle lira ensuite ; le détournement d’identité de workflow, tel que Noma le définit, ne requiert ni l’une ni l’autre, car la requête est une que le modèle est censé comprendre et que le pipeline est censé exécuter. Un défenseur qui a passé l’année à renforcer ses défenses contre l’injection a travaillé sur une autre couche.

Les workflows statiques restent à l'écart de l'effort de durcissement des agents

Noma distingue deux choses que l’on utilise couramment de manière interchangeable. Un workflow d’IA est une séquence prédéfinie et statique dans laquelle un modèle constitue une étape de traitement — le raccourci du rapport est étape A, modèle, étape B, étape C — et le pipeline déterministe autour du modèle contrôle ce qui se passe. Un workflow agentique est autonome : l’agent décide quelles étapes suivre et quels outils invoquer. Une grande partie des efforts de sécurité actuels, soutient le rapport, s’est portée sur le second type, en restreignant l’accès aux outils et en délimitant les permissions pour les agents qui prennent des décisions dynamiques, et ces contrôles n’atteignent pas le premier.

Le rapport referme également une échappatoire évidente. Restreindre qui ou quoi peut déclencher un flux de travail ne résout pas le problème : si une automatisation s’exécute à 8 h 00 selon un calendrier et agit sur une boîte de réception dans laquelle n’importe qui peut écrire, auditer « qui peut déclencher ce flux de travail » répond à la mauvaise question. La règle de Noma est que chaque automatisation doit être évaluée par « la partie la moins digne de confiance capable d’influencer ce sur quoi elle agit » — y compris les e-mails, formulaires, tickets, tickets GitHub, documents partagés et messages de chat.

Noma affirme que Google a corrigé un cas Google Workflows ; Google n’a rien publié.

La seule plateforme nommée dans le rapport est celle de Google. Noma déclare avoir identifié le même vecteur de risque dans Google Workflows, l’avoir signalé de manière responsable, et que Google a accusé réception du rapport et confirmé un correctif « sans divulguer les détails de mise en œuvre ». Cette phrase constitue l’intégralité du dossier public. Aucun avis Google, note de version ou CVE décrivant ce vecteur n’a pu être trouvé, et tous les comptes rendus secondaires du correctif — y compris ceux publiés dans les jours suivant le 9 septembre — l’attribuent à Noma plutôt qu’à Google.

Le rapport n’est pas non plus parfaitement cohérent quant au produit Google dont il parle. Le corps du texte mentionne Google Workflows ; un intitulé de section du même rapport indique « Google Workspace : AI Workflow Identity Hijacking ». Tous deux sont des produits Google avec des périmètres de confiance différents, et le rapport ne les concilie pas. Noma ne précise pas si le cas qu’il a signalé a été exploité, combien de clients ont été exposés, ni ce que le correctif a changé — et comme Google n’a rien dit, aucune de ces lacunes ne peut être comblée du côté du fournisseur.

GitLost était la même frontière, vue à travers un prisme plus étroit

La divulgation antérieure de Noma donne un précédent à cette catégorie. En juillet 2026, le groupe a publié des recherches sur GitHub Agentic Workflows, qu'il a nommées GitLost : un workflow déclenché lorsqu'une issue était assignée lisait le titre et le corps de l'issue et répondait par un commentaire, et comme l'agent disposait d'un accès en lecture à l'ensemble des dépôts de l'organisation, des utilisateurs externes pouvaient utiliser l'assignation d'issue pour atteindre des données de dépôts privés. Dark Reading en a fait un article le 7 juillet 2026 et a décrit un attaquant dissimulant des commandes en anglais simple dans le corps d'une issue ouverte dans un dépôt public, sans avoir besoin d'identifiants ni de compétences en programmation.

Les deux cadrages ne sont pas identiques, et la différence est ce qui est intéressant. Le compte rendu de Dark Reading en juillet est une histoire d’injection de prompt : du texte contrôlé par l’attaquant est lu comme des instructions. Le rapport de Noma de septembre décrit GitLost en termes de déclencheur et d’accès en lecture à l’ensemble du dépôt, et le présente comme la même frontière d’autorisation vue sous un angle. Les deux descriptions correspondent à un flux de travail dont l’agent a lu du texte écrit par un tiers, mais seule la plus ancienne dépend du fait que le modèle soit piloté. Noma affirme désormais avoir signalé le même vecteur de risque à Google ; elle ne précise pas si le cas GitLost a jamais été exploité au-delà de la démonstration publiée.

Selon Noma, Hacker News, Dark Reading et plus de 100 autres médias internationaux ont couvert les recherches sur GitLost. Ce chiffre provient du fournisseur, et cet article n'a pas compté la couverture de manière indépendante.

Les praticiens conviennent que le mécanisme est ancien ; le débat porte sur le nom.

La couverture médiatique indépendante n’a pas contesté le constat, et deux praticiens externes ont contesté la nouveauté plutôt que le fond. Morey Haber, conseiller principal en sécurité chez BeyondTrust, a déclaré à Dark Reading : « Personne n’a trompé un modèle d’IA pour lui faire faire quoi que ce soit qu’il n’était pas censé faire. Le modèle a fait exactement ce qu’on lui avait dit, par un inconnu (non fiable), et le flux de travail qui l’entourait a utilisé l’identité de quelqu’un d’autre pour que cela se produise, car il n’était pas correctement délimité et traité selon le principe du moindre privilège. » CSO Online a cité Vibhum Dubey décrivant ce schéma comme « une classe connue de faiblesse d’autorisation », et ajoutant que lorsqu’une entrée non authentifiée peut déclencher un flux de travail de confiance qui agit avec ses propres privilèges, « le flux de travail peut effectivement agir comme un mandataire confus. »

Ram Varadarajan, directeur général d’Acalvio, a proposé à Dark Reading un contrôle entièrement différent : au lieu de davantage de filtrage, parsemer l’environnement de leurres — de faux fils de discussion de dirigeants, des enregistrements de jetons-leurres — qui n’offrent aucune raison légitime à un workflow autorisé de les toucher, afin qu’une requête à l’apparence bénigne qui cherche à en atteindre un heurte une limite qu’elle ne devrait jamais franchir. Le désaccord, pour autant qu’il existe, porte sur la question de savoir si la contribution utile est un nouveau nom pour une faille de délégation de l’époque de 1988 ou une description concrète de l’endroit où cette faille se trouve désormais. La position de Noma est la seconde : ce schéma est systémique dans les pipelines d’IA d’entreprise et les cadres actuels de sécurité de l’IA examinent la mauvaise surface.

La mesure d'atténuation consiste à déléguer et à instaurer un point de contrôle, et non à améliorer le filtre.

Les contrôles recommandés par Noma se situent au niveau de la couche applicative plutôt qu’au niveau de la couche modèle. La délégation de jetons tenant compte de l’identité consiste à supprimer les clés d’API administratives statiques des workflows d’IA et à exécuter les opérations sur les données avec des jetons de délégation à durée de vie courte et à portée limitée, liés au demandeur authentifié, afin que le contexte utilisateur se propage jusqu’à l’appel qui accède réellement aux données. Les points de contrôle d’autorisation contextuelle consistent à considérer chaque sortie de modèle comme une entrée non fiable et à placer une évaluation explicite du contrôle d’accès et de la protection à l’exécution entre l’étape de transformation du modèle et tout appel ultérieur à une base de données ou à un outil. La séparation asymétrique des sorties consiste à isoler structurellement la récupération de données des canaux de communication externes, afin qu’un workflow traitant des données internes sensibles ne partage pas de chemin d’exécution avec un mécanisme automatisé qui répond à des tiers.

Dubey a donné à CSO Online un test moins coûteux que n’importe lequel des trois : comparer les résultats selon les niveaux de privilèges. « Si un utilisateur peu privilégié peut obtenir le même résultat qu’un administrateur parce que les systèmes en aval ne voient que l’identité du workflow, c’est là que je concentrerais l’enquête. »

Ce que le dossier laisse en suspens

Aucune victime, aucun décompte et aucune télémétrie. Le cas de la boîte de réception du support de Noma est une démonstration ; le rapport ne nomme aucune organisation et l’archive classe comme faux un préjudice réel. La plausibilité du mécanisme ne prouve pas qu’il a été utilisé.

• Quel produit Google a été corrigé, et quelle était la correction. Le texte de Noma mentionne Google Workflows, son titre de section mentionne Google Workspace, et Google n’a rien publié. Les organisations ne peuvent pas encore déterminer, à partir de sources publiques, si un pipeline qu’elles exploitent était concerné.

• Si le vecteur a été exploité quelque part. Ni le rapport ni aucune couverture médiatique examinée pour cet article ne décrit une campagne observée, une perte de données ou un constat forensique attribuables à un détournement d’identité de workflow.

• Si la catégorie tient face à la mesure. Aucun tiers indépendant n’a publié de scan, de corpus de pipelines concernés ni de suite de tests pour ce motif ; les éléments disponibles relèvent d’un argumentaire architectural et du compte rendu d’un seul fournisseur sur un unique cas corrigé.

• Qui fait valoir cet argument. Noma Labs est la branche de recherche de Noma Security, qui vend des contrôles de sécurité pour agents exactement du type que recommande son rapport. Cela ne rend pas le constat faux — Dark Reading et CSO Online l’ont tous deux relayé, et aucun n’y a relevé d’erreur factuelle —, mais c’est un contexte que le lecteur doit garder à l’esprit lorsqu’il évalue l’ampleur de la catégorie.

Le niveau de gravité « medium » de l'enregistrement et son indicateur de préjudice réel « false » décrivent les preuves, pas le mécanisme. Ce que Noma a réellement établi est étroit et vérifiable : que l'identité de déclenchement d'un workflow et son identité d'exécution sont deux choses distinctes, que la seconde est généralement la plus puissante, et qu'un pipeline qui ne les compare jamais fera pour un inconnu ce qu'il ferait pour la personne pour qui il a été conçu. Le contrôle qui en découle est donc tout aussi peu spectaculaire — demander, pour chaque automatisation, qui peut influencer ce sur quoi elle agit, et si une quelconque étape en aval revérifie un jour que la personne qui demande était autorisée à demander.