In March 2026, during routine monitoring, Cloudforce One — Cloudflare’s threat intelligence unit — spotted an anomaly in Workers scripts deployed on the company’s serverless platform. Among these scripts, used to set up VPN proxy tunnels via the VLESS protocol, one contained thousands of repetitive comments written in multiple languages. These blocks were not meant for human developers, but for AI systems auditing the code. Cloudflare identified them as “Notice to AI” security decoys: hidden instructions embedded in code to persuade an automated analysis model that the script is harmless. That is the essence of indirect prompt injection (IDPI), an attack vector aimed not at traditional security tools, but at the reasoning layer of LLMs used as security assistants.

Cloudforce One then launched a broader study to measure how much this technique can actually degrade detection. In an initial phase, the researchers had tested short code excerpts of about 2,000 tokens and found that the decoys were often counterproductive: for most non-frontier models, piling up false safety claims acted as a warning sign and increased detection rather than reducing it. But that first pass left two major variables unexplored: saturation and context. A real attacker would not simply place a block of text at the top of a file; they could scatter comments throughout the script, while the AI auditor analyzes the full file, not just the opening lines.

The second phase addressed those gaps with a more realistic setup: comments were randomly distributed through the code, 18,400 API calls were run against a corpus of 100 confirmed malicious or abusive Workers scripts, and tests scaled up to 1,000 comments per file and files larger than 3 MB. Seven models were evaluated, split between non-frontier systems — faster, cost-optimized models — and frontier models with more advanced reasoning.

The study produced three main findings. First, deception follows a U-shaped curve. A moderate number of injected comments, roughly 1 to 20, can significantly reduce detection on the most vulnerable non-frontier models; on the weakest model, detection fell from 90% to 67%. But at the other extreme, with 1,000 comments or more, the tactic backfires. The repetition triggers what the researchers call a “repetition alarm,” and most models eventually recognize the saturation as a hallmark of fraud.

Second, the most operationally important threshold is not the absolute number of comments, but their ratio to functional code. When decoys account for less than 1% of the file, they are most effective: average detection across all tested models drops to 53.3%, versus 67.3% under normal conditions. The comments are subtle enough to influence the model’s reasoning without raising suspicion. Once comments exceed 25% of the file, however, they become a highly discriminative signal: detection rises to 99%, as the models interpret the imbalance as a clear sign of malicious intent.

Third, and most importantly, file size itself is the dominant risk factor. For Workers scripts under 500 KB, detection rates are close to 100%. But for files above 3 MB — including bundles of legitimate libraries such as TON SDK or React — detection collapses to just 12% to 18%. The explanation is twofold: either the malicious code falls outside the model’s context window, or it is so diluted by surrounding benign code that the model cannot isolate it. In the latter case, even when the entire file fits in context, malicious logic such as data exfiltration to Telegram can remain invisible, buried in thousands of lines of legitimate code.

Cloudforce One also found revealing linguistic biases. When scripts contained 1,000 comments in different languages, model behavior varied noticeably: Russian comments increased detection rates for several models; Chinese and Arabic comments triggered alarms in some frontier systems; Estonian, a low-resource language in training corpora, was treated with more trust by some models; and only one non-frontier model showed the opposite bias, becoming more suspicious of English comments. These stereotypes can help attackers choose the language least likely to trigger alerts, while also creating false positives for defenders.

A final concern is functional paralysis. Under extreme comment volume, some frontier models were not fooled into classifying the code as benign, but stopped functioning properly instead: rather than returning a clean malicious/benign verdict, they produced malformed outputs or refusals. In an automated security pipeline that depends on structured JSON responses to trigger blocks, that is effectively a bypass. The attacker does not need to convince the AI the code is safe; they only need to prevent it from issuing a blocking command.

Cloudforce One recommends several practical defenses: automatically strip comments before analysis to neutralize linguistic decoys; intentionally truncate large scripts so parsers prioritize functional code over boilerplate, metadata, or known SDK code; anonymize variables with neutral names such as variable1 and variable2 to avoid suggestive labels like FriendlyPayload influencing judgment; use targeted prompts such as “is this code a proxy?” instead of generic questions like “is this code abusive?”; and apply semantic validation by cross-checking natural-language claims in the code against actual program behavior.

The broader conclusion is nuanced. Linguistic prompt injection remains a real threat, especially in the “1% bypass zone,” but frontier models appear more resilient than expected to textual decoys. The real vulnerability lies in attackers’ ability to bury a malicious payload inside enough legitimate data to overwhelm the model’s attention. In practice, adversaries no longer need to persuade the AI that their code is safe — they only need to make the malicious signal too weak to detect.

Tout commence en mars 2026, lors d’une opération de surveillance routinière.

Les équipes de Cloudforce One, la division de renseignement sur les menaces de Cloudflare, détectent une anomalie dans des scripts Workers déployés sur la plateforme serverless de l’entreprise.

Parmi ces scripts, utilisés pour mettre en place des tunnels de proxy VPN via le protocole VLESS, l’un d’eux contient des milliers de lignes de commentaires répétitifs, rédigés en plusieurs langues. Il s’agit de des blocs de texte en langage naturel destinés non pas aux développeurs humains, mais aux systèmes d’intelligence artificielle chargés d’auditer le code.

Ces commentaires constituent ce que les chercheurs appellent des leurres de sécurité « Notice to AI » ». Soit des instructions dissimulées dans du code, conçues pour convaincre un modèle d’analyse automatisée que le script est inoffensif.

C’est la définition même de l’injection de prompt indirecte (Indirect Prompt Injection, ou IDPI), un vecteur d’attaque qui cible non plus les systèmes traditionnels, mais la couche de raisonnement des LLM utilisés comme outils de sécurité.

18 400 appels API

Suite à cette découverte, Cloudforce One a lancé une étude systématique pour évaluer l’impact réel de cette technique sur les capacités de détection des modèles.

Dans une première phase, les chercheurs avaient testé de courts extraits de code (environ 2 000 tokens), concluant que les leurres étaient largement contre-productifs : pour la plupart des modèles non-frontier, une accumulation de fausses déclarations de sécurité agissait comme un signal d’alarme, augmentant la détection plutôt que de la réduire.

Mais cette première phase laissait deux variables critiques non explorées : la saturation et le contexte. Un attaquant réel ne se contente pas d’insérer un bloc de texte en début de fichier ; il peut disperser ses commentaires tout au long du script, et l’auditeur IA analyse le fichier complet, pas seulement les premières lignes.

La phase 2 a donc été conçue pour combler ces lacunes :

Réalisme : les commentaires sont désormais distribués aléatoirement dans le code, imitant une structure naturelle.

Échelle : 18 400 appels API contre un corpus de 100 scripts Workers malveillants ou abusifs confirmés.

Volume : test jusqu’à 1 000 commentaires par fichier et sur des fichiers dépassant 3 Mo.

Sept modèles ont été évalués, répartis en deux catégories : les modèles non-frontier (rapides, optimisés pour le coût) et les modèles frontier (systèmes de pointe avec raisonnement avancé).

Trois grandes découvertes

1. La « courbe en U » de la tromperie

L’étude révèle un phénomène contre-intuitif. L’efficacité des leurres suit une courbe en U selon le volume de commentaires injectés. Un volume modéré (1 à 20 commentaires) suffit à abaisser significativement les taux de détection des modèles non-frontier les plus vulnérables.  Le taux de détection du modèle non-frontier le plus faible chute de 90 % à 67 %.

Mais à l’extrême opposé (1 000 commentaires ou plus), la stratégie se retourne contre l’attaquant. La répétition massive déclenche ce que les chercheurs appellent une « alarme de répétition », et la plupart des modèles finissent par reconnaître cette saturation comme un signe caractéristique de fraude.

2. La « zone de contournement à 1 % »

Le constat le plus opérationnel concerne non pas le nombre absolu de commentaires, mais leur ratio par rapport au code fonctionnel.

Lorsque les leurres représentent moins de 1 % du fichier total, ils sont les plus efficaces. Le taux de détection moyen sur l’ensemble des modèles testés s’effondre à 53,3 %, contre 67,3 % en conditions normales. Les commentaires sont alors suffisamment discrets pour influencer subtilement le raisonnement du modèle sans déclencher de suspicion.

À l’inverse, dès que les commentaires dépassent 25 % du fichier, ils deviennent une signature à haute valeur discriminante : le taux de détection remonte à 99 %, les modèles interprétant cette surreprésentation comme un indicateur clair d’intention malveillante.

3. Le volume comme masque ultime

La découverte la plus significative de l’étude dépasse la problématique des leurres linguistiques. Quelle que soit la sophistication des commentaires injectés, c’est la taille des fichiers qui constitue le facteur de risque le plus important.

Pour des scripts Workers inférieurs à 500 Ko, les taux de détection approchent les 100 %. Pour des fichiers dépassant 3 Mo ( notamment des bundles de bibliothèques légitimes comme les SDK TON ou React ), ce taux s’effondre à seulement 12 à 18 %.

L’explication est double. Soit le code malveillant se retrouve hors de la fenêtre de contexte du modèle, soit il est tellement dilué par du code bénin environnant que l’attention du modèle ne parvient plus à l’isoler.

Dans ce deuxième cas, même lorsque l’ensemble du fichier tient dans la fenêtre de contexte, la logique malveillante ( par exemple, une exfiltration de données vers Telegram) reste indétectable, noyée dans des milliers de lignes de code légitime.

Des biais linguistiques révélateurs

L’étude met également en évidence des stéréotypes linguistiques développés par les modèles. Lorsque les scripts contiennent 1 000 commentaires dans différentes langues, les réactions varient sensiblement :

Les commentaires en russe augmentent les taux de détection de plusieurs modèles.

Les scripts en chinois et en arabe déclenchent des signaux d’alarme chez certains modèles frontier.

L’estonien, langue à faible ressource de représentation dans les corpus d’entraînement, est traité avec davantage de confiance par certains modèles.

Seul un modèle non-frontier  montre un biais inverse, en se méfiant davantage des commentaires en anglais.

Ces stéréotypes linguistiques constituent à la fois un levier potentiel pour les attaquants — en choisissant la langue la moins susceptible de déclencher des alertes — et un risque de faux positifs pour les défenseurs.

La paralysie fonctionnelle : un risque sous-estimé

Un dernier phénomène mérite l’attention des équipes de sécurité.

Face à un volume extrême de commentaires (1 000 et plus), certains modèles frontier n’ont pas été trompés, mais ont cessé de fonctionner correctement : au lieu de rendre un verdict binaire « malveillant / bénin », ils ont produit des réponses mal formatées ou des refus.

Dans un pipeline de sécurité automatisé qui repose sur des sorties JSON structurées pour déclencher des blocages, cette paralysie fonctionnelle équivaut à un contournement.

L’attaquant n’a pas besoin de convaincre l’IA que son code est sûr ; il lui suffit de la rendre incapable d’émettre une commande de blocage.

Les recommandations de Cloudforce One

Pour renforcer les pipelines d’audit IA, les chercheurs proposent plusieurs mesures concrètes :

Suppression automatique des commentaires avant analyse : simple à mettre en œuvre, cette étape neutralise les leurres linguistiques et recentre le modèle sur la logique fonctionnelle.

Troncature intentionnelle : pour les scripts volumineux, les parseurs doivent prioriser les blocs de code fonctionnel sur le boilerplate, les métadonnées ou le code SDK connu.

Anonymisation des variables : renommer les variables en chaînes neutres (variable1, variable2…) évite que des noms évocateurs (FriendlyPayload, par exemple) n’influencent le jugement du modèle.

Prompts ciblés : remplacer les requêtes génériques (« ce code est-il abusif ? ») par des questions spécifiques (« ce code est-il un proxy ? ») améliore la précision des réponses.

Validation sémantique : croiser les déclarations en langage naturel présentes dans le code avec le comportement programmatique réel, pour éviter qu’une documentation légitime trop zélée ne soit faussement signalée.

L’étude de Cloudforce One apporte une nuance importante au débat sur les risques de l’injection de prompt. Si la tromperie linguistique reste une menace réelle, notamment dans la « zone de contournement à 1 % », les modèles frontier s’avèrent globalement plus résistants qu’attendu face aux leurres textuels.

La véritable vulnérabilité se situe dans la capacité des attaquants à noyer un payload malveillant dans un volume de données légitimes suffisant pour saturer l’attention des modèles.

En d’autres termes, les adversaires n’ont plus besoin de convaincre l’IA que leur code est sûr. Ils ont seulement besoin de rendre le signal malveillant trop faible pour être détecté.

The post Les IA de sécurité, nouvelles cibles de l’injection de prompt appeared first on Silicon.fr.