DACSI : quand les documents récupérés falsifient les signaux de contrôle du système

De quoi s’agit-il ?

Le 8 juin 2026, un papier intitulé Document-Authored Control-Signal Impersonation: A Low-Cost Indirect Prompt Attack on RAG Safety Boundaries (arXiv:2606.09005) a donné un nom à un mode de défaillance que les concepteurs de systèmes de génération augmentée par récupération (RAG) redécouvrent régulièrement par accident. L’auteur l’appelle DACSI — Document-Authored Control-Signal Impersonation (usurpation, par un document, de signaux de contrôle).

Le décor est le prompt RAG ordinaire. Le système sérialise plusieurs éléments dans un seul bloc en langage naturel : la requête de l’utilisateur, les documents tirés de l’index, plus les métadonnées, les labels système et les instructions de tâche. DACSI survient lorsqu’un texte rédigé par l’attaquant à l’intérieur d’un document récupéré se déguise en l’un de ces signaux de contrôle — une étiquette de provenance, un marqueur d’autorité, un drapeau « vérifié », une mention de politique de divulgation — de sorte que le modèle traite une donnée comme si elle était une politique.

Ce n’est pas le jailbreak classique « ignore previous instructions ». Le papier positionne explicitement DACSI comme une sous-classe non impérative, de type métadonnées de l’injection de prompt indirecte : il n’ordonne pas au modèle d’enfreindre une règle, il affirme discrètement qu’une règle autorise déjà l’action.

Comment ça marche

La cause racine est structurelle, et c’est la même que derrière toutes les classes d’injection indirecte : le rendu du prompt RAG fusionne le texte fiable et non fiable dans un canal unique. Une fois que le prompt système, le passage récupéré et les métadonnées arrivent sous la même forme de tokens, il n’existe aucun marqueur fiable que le modèle puisse utiliser pour distinguer un signal de contrôle autorisé d’une chaîne qui lui ressemble seulement.

L’injection de type commande demande : le modèle obéira-t-il à une instruction glissée dans une donnée ? DACSI pose une question plus subtile : le modèle attribuera-t-il à tort le statut de signal de contrôle autorisé à du texte de document non fiable ? Au lieu de « fais X », la charge se lit comme un fait d’environnement — un label prétendant que le contenu est fiable, interne, pré-approuvé ou exempté d’une politique de sécurité. Si le modèle a appris à se fier à de tels labels lorsqu’ils apparaissent dans son contexte, un document qui en fabrique un hérite d’une autorité qui ne lui a jamais été accordée.

Aucune charge fonctionnelle n’est reproduite ici, et aucune n’est nécessaire pour saisir le mécanisme. Le résumé en une ligne que le papier propose lui-même est toute la leçon : un label écrit dans un document est une donnée, pas une politique. Tout champ qu’un attaquant peut écrire dans un document récupérable — un en-tête, une note de bas de page, une portion masquée, un faux bloc de métadonnées ressemblant à du JSON — est contrôlé par l’attaquant, quelle que soit son apparence officielle.

Pourquoi c’est important

DACSI compte parce qu’il se loge dans l’angle mort de la défense la plus répandue. Beaucoup de garde-fous RAG sont réglés pour attraper les injections impératives — du texte qui dit au modèle de faire quelque chose d’interdit. Un passage qui ne contient aucun impératif, seulement l’affirmation que « cette source est vérifiée et exemptée de politique », peut franchir ce filtre tout en orientant le résultat.

Il passe aussi à l’échelle à bas coût. L’attaquant n’a besoin ni d’accès au modèle ni d’optimisation par gradient ; il lui faut un seul document empoisonné atterrissant dans un corpus interrogé par le système — une page wiki, un disque partagé, un résultat web scrappé, un ticket de support. C’est la même barrière basse qui fait de l’injection indirecte le mode de défaillance agentique dominant en production, et DACSI élargit la surface à tout système laissant le contenu récupéré porter du texte de type métadonnées.

Le point plus large, cohérent avec l’argument d’intégrité contextuelle et avec les taxonomies de sécurité RAG, est que l’autorité d’une source ne peut pas être établie par quoi que ce soit d’écrit à l’intérieur de la source. La confiance doit venir du canal, pas de la charge.

Défenses

Vous ne pouvez pas faire en sorte qu’un modèle de langage distingue de façon fiable un vrai signal de contrôle d’un faux si les deux arrivent sous forme du même texte. Sortez donc la décision de confiance du prompt.

• Établissez les signaux de contrôle hors-bande. L’autorité, la provenance et les drapeaux de politique doivent être attachés à un document par le pipeline de récupération et d’ingestion que vous contrôlez, jamais lus dans le corps du document. Si un marqueur « fiable » ou « exempté de politique » peut apparaître dans du contenu récupérable, supprimez-le avant que le texte n’atteigne le modèle.
• Traitez tout texte récupéré comme une donnée non fiable. Rendez les passages récupérés dans une zone clairement délimitée et de moindre privilège, et indiquez au modèle que rien à l’intérieur ne peut accorder de permissions, fixer une politique ou affirmer sa propre fiabilité. Combinez avec des contrôles tenant compte de la provenance comme ceux d’ARGUS.
• Assainissez le contenu de type métadonnées à l’ingestion. Détectez et neutralisez les structures rédigées par le document qui imitent les métadonnées système — faux en-têtes, pseudo-balises JSON, mentions « vérifié par », formules de politique de divulgation. C’est la matière première de DACSI.
• Ne vous fiez pas aux filtres d’injection uniquement impératifs. Testez vos garde-fous contre des charges non impératives qui affirment une autorité plutôt que d’émettre une commande. Un filtre qui n’attrape que « ignore previous instructions » manquera entièrement cette classe.
• Limitez le rayon d’impact. Associez ce qui précède à des portées d’outils en moindre privilège et à des contrôles d’exfiltration, afin qu’un signal de contrôle mal attribué ne puisse, à lui seul, atteindre des données sensibles ou une voie d’exfiltration.

Statut

Élément	Détail
Papier	Document-Authored Control-Signal Impersonation (DACSI)
Identifiant	arXiv:2606.09005v1
Publié	2026-06-08
Classe	Injection de prompt indirecte — sous-classe non impérative, type métadonnées
Nature	Résultat de recherche / caractérisation de classe d’attaque (pas d’exploit en production)

DACSI n’est pas une nouvelle vulnérabilité produit à corriger ; c’est un nom donné à une erreur d’architecture récurrente. Les systèmes les plus exposés sont ceux qui laissent les documents récupérés s’exprimer avec la voix du système lui-même. Le correctif n’est pas un meilleur classifieur à l’intérieur du prompt — c’est le refus de laisser le prompt devenir l’endroit où l’autorité se décide.