Blanchiment de prompt entre modèles : un refus qui ne survit pas au relais

De quoi s’agit-il ?

Le 3 juillet 2026, Axis Intelligence Research a ajouté à son suivi mensuel AI Model Vulnerability Tracker (mis à jour le 4 juillet 2026) une entrée décrivant un schéma qu’elle nomme blanchiment de prompt entre modèles par chaînage d’API. Ce n’est pas une faille d’un modèle en particulier. C’est un écart qui s’ouvre entre deux modèles lorsque la sortie de l’un est injectée dans l’autre comme un simple message utilisateur — précisément le câblage sur lequel reposent les stacks d’orchestration multi-agents.

Le constat est simple et dérangeant. Le modèle A refuse une requête. L’orchestrateur, par conception ou par inadvertance, transmet une version reformulée de la même requête sous-jacente au modèle B. Le modèle B ignore totalement que le modèle A l’avait déjà déclinée. Il voit un message utilisateur neuf, d’apparence anodine, et il répond. Le refus n’a pas voyagé avec la requête. En laboratoire, 14 chaînes testées sur 18 ont produit la sortie refusée en deux sauts.

Comment ça marche

Le mécanisme est structurel, pas astucieux. Un refus de sécurité est une propriété d’une seule inférence : le modèle évalue le prompt qu’il a devant lui et décline. Cette décision n’est pas une étiquette durable attachée à la requête ; c’est un événement qui se produit à l’intérieur d’un appel de modèle, puis s’évapore. Lorsqu’un orchestrateur passe le relais — du résumeur au planificateur, du planificateur à l’exécuteur d’outils, du modèle d’un éditeur à celui d’un autre — il transmet en général le contenu, pas l’historique de sécurité qui l’a produit.

Le second modèle hérite donc des mots, mais pas du verdict. Une requête qui semble malveillante dans une formulation peut être reformulée, décomposée en sous-tâches, ou simplement requalifiée en « contexte à traiter » avant d’atteindre le modèle B. Comme le modèle B répond à ce qui ressemble à un tour utilisateur anodin, son propre entraînement à l’alignement se déclenche face à la mauvaise question. La surface d’attaque, dit le suivi, est la couture entre les modèles, pas une faiblesse de l’un ou de l’autre.

Ce constat rejoint un argument plus large de la littérature de recherche. Un article de position de mai 2026, Safety and Fairness in Agentic AI Depend on Interaction Topology, Not on Model Scale or Alignment, défend la thèse générale : lorsque le comportement d’un système est dominé par la façon dont ses composants sont assemblés, l’alignement de chaque composant ne se compose pas de façon fiable en sécurité au niveau du système. Aligner chaque modèle isolément contraint le comportement local ; c’est la topologie du pipeline qui détermine ce que l’ensemble fait réellement. Le blanchiment entre modèles est cette thèse abstraite qui apparaît sous forme de constat concret et reproductible.

Pourquoi c’est important

L’orchestration multi-agents est passée de la démo de recherche à la tuyauterie de production au cours du premier semestre 2026. Comme le documente la revue de mi-année sur l’IA agentique de DeepInspect (1er juillet 2026), les appels de modèles chaînés se trouvent désormais derrière des fonctionnalités d’entreprise ordinaires — résumer, puis planifier, puis agir — mélangeant souvent éditeurs et versions de modèles dans un même chemin de requête. Chaque relais de cette chaîne est un endroit où un refus peut être discrètement perdu.

Conséquence : « nous utilisons un modèle bien aligné » cesse d’être un argument de sécurité suffisant. Le constat a été reproduit avec un éventail de modèles de pointe actuels jouant le rôle du maillon aval, ce qui signifie que l’exposition est une propriété du schéma d’architecture, pas des garde-fous d’un éditeur donné. Une équipe peut acheter le modèle le plus enclin au refus du marché et livrer malgré tout un pipeline qui blanchit une requête rejetée à travers lui — parce qu’on n’a jamais dit au modèle qu’un rejet avait déjà eu lieu.

Défenses

Le correctif consiste à cesser de traiter un relais comme une page blanche. Faites voyager l’état de sécurité à travers la couture, et revérifiez à chaque frontière plutôt que de supposer qu’un modèle amont l’a déjà fait.

Concrètement : revérifiez à chaque saut. Appliquez une classification des entrées sur le contenu qui entre dans chaque modèle de la chaîne, pas seulement celui avec lequel l’utilisateur dialogue. Le second modèle doit être protégé comme si son entrée était du texte utilisateur non fiable — car, fonctionnellement, c’en est. Propagez les signaux de refus. Lorsqu’un modèle amont décline, l’orchestrateur devrait l’enregistrer et refuser de transmettre en aval une requête sémantiquement équivalente, au lieu de la reformuler et de la réessayer en silence. Préservez la provenance. Étiquetez le contenu selon son origine — utilisateur, outil, ou sortie d’un autre modèle — pour qu’un garde-fou aval puisse le pondérer correctement au lieu de tout lire comme un tour utilisateur de confiance. Placez la couche de politique à la frontière de requête, pas dans les modèles. Une passerelle qui voit toute la chaîne peut appliquer une politique unique et cohérente sur l’ensemble des sauts, ce qu’aucun modèle isolé ne peut faire puisqu’aucun ne voit le chemin complet. Enfin, testez le pipeline, pas les pièces. Évaluez la sécurité de bout en bout sur la chaîne assemblée ; une campagne qui ne red-teame que chaque modèle isolément manquera précisément cette classe de défaillance, parce qu’elle vit entre eux.

Statut

Aspect	Détail
Référence	AVI-2026-0104, « Cross-Model Prompt Laundering via API Chaining » (suivi Axis Intelligence)
Divulgation	Déposé le 3 juillet 2026 ; signalé à OpenAI, Anthropic et Google DeepMind le 3 juillet 2026
Classe	Écart de sécurité architectural — état de refus non préservé lors des relais entre modèles
Reproduction	14 chaînes testées sur 18 ont produit la sortie refusée en deux sauts (tests en laboratoire)
Concernés	Signalé contre GPT-5, Claude Sonnet 4.6 et Gemini 3 Pro comme modèle aval ; schéma au niveau du framework
Ancrage académique	Article de position sur la topologie d’interaction (arXiv 2605.01147, mai 2026) : l’alignement par composant ne se compose pas en sécurité système
Exploité dans la nature	Non signalé comme exploité ; divulgué en divulgation coordonnée