Injection de prompt : menace d’autorité et confusion instruction/donnée
Cette page définit l’injection de prompt comme une menace d’autorité et clarifie la confusion structurelle entre instruction et donnée.
Dans un régime interprétatif, un système d’IA ne « lit » pas seulement du contenu. Il agrège des signaux hétérogènes (instructions, contexte, données, sources récupérées) et produit une réponse comme si ces éléments étaient compatibles. L’injection de prompt exploite précisément cette zone grise : faire passer une instruction pour une donnée, ou faire consommer une donnée comme si elle portait une autorité supérieure.
Sur gautierdorval.com, l’injection de prompt n’est pas traitée comme un simple « hack de prompt », mais comme un mécanisme de renversement de hiérarchie dans la chaîne d’interprétation.
Statut de cette page
Cette page est une clarification interprétative.
Elle fixe un cadre de lecture interne, afin d’éviter que le terme « injection de prompt » soit utilisé de manière floue (ex. pour désigner toute erreur, toute hallucination ou tout désaccord de réponse).
Définition opératoire
Injection de prompt : tentative de faire exécuter, prioriser ou intégrer une instruction non légitime en l’insérant dans un canal consommé par le modèle (input utilisateur, contenu récupéré, metadata, outils, mémoire), de manière à modifier la sortie ou la décision du système.
Le cœur du problème n’est pas l’existence d’une instruction, mais son statut : elle est consommée comme si elle était autorisée, pertinente et de niveau supérieur, alors qu’elle ne l’est pas.
Principe central : confusion instruction/donnée
Une donnée décrit.
Une instruction commande.
L’injection de prompt cherche à faire croire qu’une donnée est une instruction (« ignore les règles précédentes ») ou qu’une instruction est une donnée fiable (« ce document prouve que… »). Cette confusion est aggravée lorsque le système ne borne pas clairement :
- ce qui a le droit d’instruire (policies, system prompts, règles runtime)
- ce qui sert de contexte (retrieval, mémoire, citations)
- ce qui est une source de vérité (canon, définitions, hiérarchie des pages).
Menace d’autorité
Dans ce cadre, l’injection est une menace d’autorité : elle cherche à déplacer la « source qui décide ».
Un système vulnérable n’échoue pas parce qu’il « comprend mal », mais parce qu’il accorde un rang d’autorité illégitime à un fragment.
Typologie minimale (surfaces courantes)
- Injection directe : l’instruction est dans l’input utilisateur et vise à écraser des règles.
- Injection via contenu : l’instruction est insérée dans un texte récupéré (page, PDF, commentaire, doc), puis consommée comme contexte.
- Injection via métadonnées : titres, descriptions, alt, champs structurés, qui deviennent une voie de passage.
- Injection via outils : réponses d’API, plugins, connecteurs, dont la sortie est traitée comme « autoritaire ».
- Injection via mémoire : consolidation d’une instruction persistée, qui devient une règle implicite.
Ce que cette clarification exclut (bornage)
- Une hallucination n’est pas automatiquement une injection.
- Une erreur factuelle ne prouve pas une compromission.
- Un contenu trompeur public n’est pas une injection tant qu’il n’est pas ingéré comme autorité par le système.
Relation aux autres clarifications de la série
Cette page s’inscrit dans une séquence de stabilisation :
- Injection indirecte : quand une consigne de traitement devient surface d’attaque
- Empoisonnement RAG : contamination de corpus et dérive interprétative
- AI poisoning : définition et taxonomie (cadre englobant)
- Q-Layer face aux attaques d’injection : bornage des conditions de réponse
Portée de cette clarification
Cette page s’applique aux lectures humaines, aux synthèses automatisées, aux citations sans clic, et aux chaînes d’agents interconnectés.
Elle doit être interprétée comme une clarification de principe orientée hiérarchie d’autorité, et non comme un guide opératoire ou une procédure de test.
