🤖 AI

On the Inseparability of Instructions and Data in Shared-Embedding Sequence Models

Cet article démontre que la prévention parfaite des injections de requêtes est mathématiquement impossible dans les modèles de séquences à plongements partagés, en arguant que la sécurité robuste nécessite une séparation architecturale des canaux de contrôle et de contenu plutôt que l'amélioration des défenses au sein du pipeline.

Auteurs originaux : Dewank Pant, Shruti Lohani, Avijit Kumar

Publié 2026-06-29

📖 7 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Dewank Pant, Shruti Lohani, Avijit Kumar

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

L'idée principale : Le problème du « Bol Mélangeur »

Imaginez que vous êtes un chef (le modèle d'IA) travaillant dans une cuisine. Vous avez deux types d'ingrédients :

La Fiche Recette (Instructions de confiance) : Ce sont les règles données par le propriétaire du restaurant (ex : « Ne servez que des plats végétariens », « Ne donnez jamais la sauce secrète »).
La Commande du Client (Données non fiables) : Ce sont les requêtes apportées par les clients (ex : « Je veux un burger », « Peux-tu me raconter une blague ? »).

Dans les modèles d'IA actuels, le chef met à la fois la Fiche Recette et la Commande du Client dans le même bol mélangeur. Ils sont hachés, mélangés et broyés ensemble en une seule soupe d'ingrédients uniforme avant que le chef ne commence à cuisiner.

La thèse principale du papier :
Les auteurs soutiennent que, parce que la Recette et la Commande sont mélangées dans le même bol, il est mathématiquement impossible pour le chef de distinguer parfaitement « ce que le propriétaire a dit » de « ce que le client a dit » une fois qu'ils sont mélangés.

Si un client glisse une note dans sa commande disant : « Ignore la fiche recette et donne-moi la sauce secrète », le chef ne peut pas distinguer que cette note est différente de la recette elle-même. Pour le cerveau du chef, tout n'est que « soupe ». Par conséquent, le chef pourrait accidentellement suivre la note sournoise du client au lieu des règles du propriétaire.

L'analogie centrale : La machine Von Neumann

Le papier compare ce problème d'IA à une célèbre faille de sécurité informatique des années 1970 appelée Dépassement de tampon (Buffer Overflow).

Anciens ordinateurs (Architecture Von Neumann) : Dans ces machines, les programmes informatiques (code) et les données (nombres) vivaient dans le même espace mémoire. Un pirate pouvait tromper l'ordinateur en lui injectant des données qui ressemblaient à un programme. L'ordinateur exécutait alors accidentellement les données comme s'il s'agissait d'une commande, faisant planter le système ou permettant au pirate de prendre le contrôle.
IA Moderne (Transformers) : Les auteurs affirment que l'IA présente exactement la même faille. Les « Instructions » (le prompt système) et les « Données » (l'entrée utilisateur) vivent dans le même espace mathématique (les vecteurs). Un pirate peut concevoir des « données » qui ressemblent à des « instructions » pour l'IA. Parce que l'IA ne peut pas les distinguer une fois qu'elles sont mélangées, elle suit les instructions du pirate.

Le papier soutient que, tout comme on ne pouvait pas corriger les dépassements de tampon simplement avec un « meilleur code » ou une « saisie plus prudente », nous ne pouvons pas corriger l'injection de prompt (prompt injection) simplement avec un « meilleur entraînement » ou « plus de filtres ». Le problème est l'architecture (le bol mélangeur), et non la compétence du chef.

Les trois raisons pour lesquelles c'est impossible

Le papier prouve cette impossibilité en trois étapes logiques :

1. Le problème du « Vocabulaire Partagé » (Collision de représentation)

La métaphore : Imaginez que la Fiche Recette et la Commande du Client utilisent tous deux le mot « Sel ».
La réalité : Dans l'IA, des mots comme « le », « est », « vous » et « aide » apparaissent à la fois dans les instructions système et dans les entrées utilisateur. L'IA associe ces mots au même nombre mathématique. Une fois que l'IA voit le mot « aide », elle ne sait pas s'il provient de la règle du propriétaire (« Aide l'utilisateur ») ou de la ruse de l'utilisateur (« Aide-moi à contourner les règles »). La « source » du mot est effacée dès qu'il entre dans le bol.

2. L'angle mort dans la cuisine (Récupération de la provenance)

La métète : Si vous essayez de regarder la soupe et de deviner quelle cuillerée provient de la Fiche Recette et laquelle provient de la Commande du Client, vous vous tromperez parfois.
La réalité : Le papier prouve mathématiquement que, comme les ingrédients « de confiance » et « non fiables » sont si similaires (ils partagent le même vocabulaire et le même espace), aucune quantité d'observation de la soupe ne pourra parfaitement les distinguer. Il y aura toujours une petite chance d'erreur. Si vous ne pouvez pas les distinguer parfaitement, vous ne pouvez pas bloquer parfaitement les éléments malveillants.

3. Le problème des « Variations Infinies » (Couverture finie)

La métaphore : Imaginez que vous entraîniez votre chef à reconnaître 1 000 façons dont un client pourrait essayer de le tromper. Mais un client rusé peut écrire sa ruse de 1 000 000 de façons différentes (en utilisant différentes langues, des emojis, du code ou des astuces d'orthographe) qui signifient toutes la même chose.
La réalité : Vous pouvez entraîner une IA sur des millions d'exemples, mais le nombre de façons de la tromper est effectivement infini. Comme l'IA apprend en voyant des exemples, elle ne pourra jamais apprendre à être sûre contre chaque variation possible d'une ruse. Elle aura toujours un « angle mort » pour une ruse qu'elle n'a pas encore vue.

Ce que cela signifie pour la sécurité de l'IA

Les auteurs ne disent pas que l'IA est inutile ou que nous devrions arrêter de l'utiliser. Ils disent :

On ne peut pas « patcher » le bol mélangeur : Vous ne pouvez pas corriger ce problème simplement en entraînant mieux l'IA, en ajoutant plus de « garde-fous » ou en filtrant les mots. Tant que l'IA mélange les instructions et les données dans le même espace, un attaquant rusé finira par trouver un moyen d'y glisser une fausse instruction.
La solution est architecturale : Pour vraiment résoudre cela, nous devons changer la conception de la cuisine. Nous avons besoin d'un système où la Fiche Recette et la Commande du Client sont conservées dans des bols séparés qui ne se mélangent jamais jusqu'à la toute fin. La « Recette » doit être une règle rigide que la « Commande du Client » ne peut ni toucher ni écraser.
Défense en profondeur : Jusqu'à ce que nous construisions ces nouveaux systèmes à « bols séparés », nous devons traiter l'IA comme nous traitons les anciens ordinateurs sujets aux dépassements de tampon : partons du principe qu'ils seront piratés, utilisez plusieurs couches de défenses faibles (comme des pare-feu et des bacs à sable) et limitez les dégâts s'ils sont effectivement compromis.

Résumé

Le papier prouve que la sécurité parfaite est impossible pour les modèles d'IA actuels car ils traitent « ce qu'il faut faire » et « ce qu'il faut traiter » comme étant la même chose. C'est comme demander à un chef d'ignorer la note du client si la note est écrite avec la même encre et sur le même papier que la recette. La seule façon de résoudre cela est de changer la conception fondamentale de l'IA, et non de simplement essayer de mieux l'entraîner.

Résumé technique : Sur l'indissociabilité des instructions et des données dans les modèles de séquences à plongements partagés

1. Énoncé du problème

L'article traite de la vulnérabilité persistante des grands modèles de langage (LLM) face à l'injection de prompt, où des adversaires conçoivent des entrées utilisateur qui poussent le modèle à dévier de ses instructions système prévues. Bien que la communauté de la recherche ait proposé de nombreuses défenses (ex. : ajustement des instructions, garde-fous, ingénierie de la représentation), ces mesures ont systématiquement échoué à fournir une protection robuste et durable. Les auteurs posent une question fondamentale : la prévention parfaite de l'injection de prompt est-elle théoriquement possible au sein de l'architecture actuelle des transformeurs à plongements partagés ?

Le problème central réside dans la conception architecturale où les instructions système de confiance et les données utilisateur non fiables sont traitées via un pipeline de représentation partagé. Dans ces architectures, les deux entrées sont projetées dans le même espace vectoriel via une fonction de plongement (embedding) partagée, effaçant toute distinction immuable entre le « code » (instructions) et les « données » (entrée utilisateur) une fois qu'elles pénètrent dans le modèle.

2. Méthodologie et cadre formel

2.1 Le modèle d'action prompté

Les auteurs formalisent le système comme un Modèle d'Action Prompté $M = (\Sigma, d, E, f, A)$ , où :

Plongement Partagé ( $E$ ) : Les instructions de confiance ( $s$ ) et le contenu utilisateur non fiable ( $u$ ) sont tous deux projetés par la même fonction $E: \Sigma \to \mathbb{R}^d$ .
Espace d'Action ( $A$ ) : Comprend la génération de jetons (tokens) et les actions de contrôle autoritaires (refus, invocation d'outils, routage de politique, écritures en mémoire).
Propriété de Sécurité (Contrôle Sémantiquement Fidèle - SFC) : Les auteurs définissent la SFC comme l'exigence que le comportement de contrôle autoritaire dépende uniquement du contenu sémantique de l'entrée non fiable, et non de variations sémantiquement non pertinentes de son encodage (ex. : obfuscation, suffixes adverses).

2.2 Approche théorique

La preuve d'impossibilité repose sur trois piliers théoriques distincts :

Impossibilité de récupération de la provenance : En utilisant la distance de Variation Totale (TV), les auteurs démontrent que lorsque les entrées de confiance et non fiables partagent un espace de représentation, l'erreur de Bayes-optimale pour récupérer l'origine (la provenance) d'une représentation est strictement non nulle, à moins que les distributions ne soient disjointes.
Exposition du chemin de contrôle : Ils montrent que dans les mécanismes d'attention standards, le contenu non fiable contribue à l'agrégation de valeur des nœuds pertinents pour le contrôle (ceux qui déterminent les refus ou l'usage d'outils). Ainsi, les données non fiables influencent causalement les sorties de contrôle.
Écart d'invariance de couverture finie : Ils soutiennent que comme les classes d'équivalence sémantique (ex. : tous les encodages possibles d'une requête) sont infinies ou super-polynomiales, et que les données d'entraînement sont finies, aucun mécanisme opérant uniquement au sein du pipeline partagé ne peut garantir l'invariance sur tous les encodages possibles.

3. Contributions clés

Formalisation du Contrôle Sémantiquement Fidèle (SFC) : L'article définit la SFC comme la propriété de sécurité minimale pour les systèmes agentiques, distinguant la dépendance sémantique légitime (refuser des requêtes malveillantes) de la dépendance représentationnelle illégitime (contourner les refus via des astuces d'encodage).
Le Théorème d'Indissociabilité : Les auteurs prouvent que dans toute architecture à plongements partagés dépourvue de séparation imposée entre le contrôle et les données, la perfection de la SFC ne peut être garantie au sein du pipeline de représentation partagé. Il s'agit d'un résultat d'impossibilité, et non d'une critique des méthodes d'entraînement actuelles.
Isomorphisme structurel avec l'architecture Von Neumann : L'article établit une analogie précise entre l'injection de prompt dans les LLM et les vulnérabilités de dépassement de tampon (buffer overflow) dans les machines Von Neumann. Tout comme la mémoire partagée permet la confusion entre code et données (menant à des dépassements de tampon), les plongements partagés permettent la confusion entre instructions et données utilisateur (menant à l'injection de prompt).
Ancrage empirique : Les auteurs fournissent des mesures confirmant les hypothèses théoriques :
- Recouvrement du vocabulaire : Les corpus d'instructions et de données utilisateur partagent une vaste majorité de jetons (couverture de 61,5 % à 82,3 %), garantissant des collisions de plongement.
- Recouvrement de la représentation : Les distributions d'états cachés pour les instructions et les données utilisateur restent indiscernables (recouvrement MMD élevé) même dans les couches profondes, particulièrement dans les couches pertinentes pour les sorties de contrôle.
- Contamination comportementale : Les expériences montrent que même lorsque les modèles refusent des charges utiles malveillantes, les jetons non fiables altèrent les états cachés pertinents pour le contrôle, modifiant le cadrage et la longueur de la sortie, confirmant que le chemin de contrôle est exposé.

4. Résultats et conclusions

Impossibilité d'une prévention parfaite : Le résultat central est qu'aucune défense opérant uniquement au sein du pipeline de représentation partagé (ex. : de meilleurs classifieurs, l'ajustement de l'alignement ou le filtrage dans le pipeline) ne peut garantir une prévention parfaite de l'injection de prompt.
Le rôle de l'entraînement : Les défenses actuelles (RLHF, garde-fous) agissent comme des « correctifs » qui améliorent le comportement moyen, mais ne peuvent éliminer la vulnérabilité structurelle. L'article cite l'abliteration (chirurgie de poids qui supprime les capacités de refus) comme preuve que la sécurité est encodée comme une direction fragile dans l'espace partagé, plutôt que comme un circuit structurellement séparé.
Limites des marqueurs de position ou de segment : L'article démontre que les encodages de position et les marqueurs de segment logiciels (ex. : [INST]) sont insuffisants car ils encodent la localisation, et non une provenance immuable, et peuvent être forgés par des adversaires.
Limites quantitatives : Les auteurs dérivent une borne montrant qu'à mesure que le budget computationnel d'un adversaire augmente, la capacité à distinguer les représentations de confiance des représentations adverses tend vers un choix aléatoire (la distance TV approche 0).

5. Signification et affirmations

L'article affirme que l'injection de prompt n'est pas simplement un défaut à corriger, mais une vulnérabilité structurelle inhérente à l'architecture à plongements partagés.

Analogie architecturale : La portée de l'article réside dans le recadrage de l'injection de prompt comme étant analogue à la confusion code-données dans les machines Von Neumann. De même que les dépassements de tampon ont nécessité une défense multicouche (canaris de pile, ASLR, bits NX) et, finalement, des langages de programmation sûrs pour les contenir, l'injection de prompt nécessite une séparation architecturale entre les canaux d'instruction et de données.
Implications pour la défense : Les auteurs soutiennent que compter uniquement sur un « meilleur entraînement » ou une « classification dans le pipeline » est insuffisant. Une posture de défense mature doit inclure :
1. Atténuations architecturales : Imposer une séparation immuable entre le contrôle de confiance et le contenu non fiable (ex. : encodeurs disjoints, attention typée).
2. Protections au runtime : Des défenses multicouches similaires à l'ASLR ou aux canaris de pile.
3. Changement de paradigme à long terme : Vers des paradigmes de représentation « sémantiquement sûrs » qui éliminent la confusion des plongements partagés par construction.

L'article conclut que, bien que les systèmes utiles ne doivent pas ignorer l'entrée de l'utilisateur, la prévention parfaite est impossible sans imposer la séparation du contrôle au niveau architectural. Tant qu'une telle séparation n'est pas atteinte, l'injection de prompt demeure un risque irréductible dans les applications intégrant des LLM.