Microsoft et l'Institut des Sciences de Tokyo ont divulgué MetaBackdoor le 18 mai — une attaque de backdoor LLM qui se trigger sur la longueur de l'input plutôt que sur le contenu, bypassant la classe entière de défenses qui cherchent des tokens suspects ou du texte anormal. Le mécanisme : un attaquant avec accès à la data de fine-tuning poison des exemples en pairant des inputs longs avec des outputs malicieux. Le modèle apprend à switcher en mode attaque quand un input dépasse un seuil de longueur. Aussi peu que 90 exemples poisoned suffisent à embedder le comportement. L'attaque réussit à 75% sur l'exfiltration autonome de data via des tool calls à des longueurs de conversation au-dessus de 700 tokens, et persiste à environ 40% même après un retraining substantiel.
L'insight architectural, c'est le canal de signal. Les défenses actuelles — scanners de prompt injection, content filters, anomaly detectors — opèrent toutes sur le contenu de l'input. Elles regardent ce qui est dans les tokens. MetaBackdoor utilise la longueur de l'input comme signal de trigger, ce qui veut dire que les défenses côté contenu regardent le mauvais axe entièrement. Le writeup est direct : « Les content filters ont rien à filtrer. Les anomaly detectors voient du texte ordinaire. » C'est pas un échec de défense — c'est un mismatch de catégorie de défense. L'attaque training-time est structurellement invisible à l'inspection content-side au moment d'inférence. Pour les builders, le corollaire c'est que la forme de l'input (longueur, distribution de types de tokens, fréquence de requêtes) est un canal de signal que les défenses ont pas instrumenté.
Le seuil compte : 700+ tokens, c'est la longueur de conversation typique où la plupart des interactions d'agents en production se trouvent. Les agents chat multi-turn, les agents de code long-context, les pipelines RAG, les cycles de tool calls — tous passent ce seuil dans l'usage normal. La footprint de poisoning de 90 exemples est aussi assez petite pour se glisser dans des outputs de contracteurs RLHF, des datasets de feedback client, ou des corpus de fine-tuning publics sans être détectée. Ça place MetaBackdoor dans la même classe de menace que la recherche sleeper-agents d'Anthropic et les divers papers de dataset poisoning — mais avec la contribution spécifique que le trigger a pas besoin d'être un token ou phrase unique que l'attaquant contrôle au moment d'inférence. Le trigger est une propriété de la forme de l'input, que l'attaquant peut garantir en s'assurant que les patterns d'usage normaux de l'application traversent le seuil. Ça fait que l'attaque est « fire-and-forget » une fois que le modèle est déployé.
Lundi matin : si tu fine-tunes un foundation model sur de la data d'un tiers (vendor RLHF, feedback client, dataset public), MetaBackdoor ajoute un nouveau vecteur de menace à ton modèle de risque supply-chain — la provenance de ton foundation model et celle de ton dataset de fine-tuning ont toutes les deux besoin d'un traitement vendor-risk. Pour le red-team testing, la check recommandée c'est la consistency comportementale à des longueurs d'input variables — query ton modèle fine-tuned avec le même prompt à 100, 500, 1000, 2000 tokens et compare les outputs pour la divergence. Si ton stack utilise des tool calls agentiques, le seuil 700 tokens c'est ta ligne : implémente du human-in-the-loop confirmation pour les tool calls qui se firent après cette profondeur de conversation. La question ouverte plus profonde : les défenses doivent élargir de l'inspection de contenu vers le monitoring de signal de forme d'input à travers le pipeline entier. C'est un stack de sécurité significativement différent de ce que la plupart des équipes ont aujourd'hui.