Des décennies d’ingénierie en cybersécurité ont été consacrées à construire des murs. Nous séparons le plan de contrôle (control plane) du plan de données (data plane). Nous utilisons des requêtes paramétrées pour prévenir les injections SQL, garantissant que la base de données traite les entrées de l’utilisateur strictement comme des données, et jamais comme des commandes SQL exécutables.
Avec l’intégration explosive de l’IA Agentique, l’industrie a connecté avec enthousiasme des interfaces en langage naturel à des API backend hautement privilégiées. Cependant, les développeurs supposent à tort que parce qu’ils ont étiqueté une section de leur prompt comme System: et une autre comme User:, le modèle sous-jacent comprend la frontière entre les deux.
Il n’en est rien.
Comme le souligne la publication urgente du Microsoft Security Response Center de mai 2026 (“Prompts become shells: RCE vulnerabilities in AI agent frameworks”), les frameworks d’orchestration modernes s’effondrent sous leur propre poids. Lorsque ces frameworks injectent les entrées utilisateur, les instructions système, les documents récupérés par RAG et les définitions d’outils dans la même fenêtre de contexte, ils placent effectivement des données Internet non fiables dans un terminal d’exécution à haut privilège. Le résultat est une élévation systémique des privilèges via le prompt.
Pour comprendre la mécanique d’un effondrement de la frontière de confiance, nous devons examiner comment les LLM traitent l’information à travers le prisme de la couche d’exécution sémantique.
Dans les architectures informatiques classiques de Von Neumann, les instructions (le code) et les données partagent le même espace mémoire physique. Dans les années 1990 et au début des années 2000, cet espace partagé a conduit à l’âge d’or des dépassements de tampon (Buffer Overflows). Si un attaquant injectait trop de données dans une variable, les données débordaient dans l’espace d’instructions, et le processeur les exécutait aveuglément en tant que code. L’industrie a résolu ce problème en implémentant des protections matérielles comme le bit NX (No-eXecute), empêchant mathématiquement les données d’être interprétées comme du code.
L’IA Agentique est une machine de Von Neumann linguistique.
À l’intérieur de la fenêtre de contexte d’un LLM, il n’y a pas de “bit NX” pour le texte. Il n’existe aucune signature cryptographique distinguant le prompt système du prompt utilisateur. Pour le mécanisme d’auto-attention du modèle, les instructions rigides du développeur, le schéma JSON d’un outil, et une charge utile malveillante cachée dans un PDF ne sont que de simples jetons.
Dans une fenêtre de contexte LLM, les primitives informatiques traditionnelles s’effondrent complètement :
Code (Logique) : le prompt système du développeur (“tu es un assistant utile…”).
Données : l’entrée de l’utilisateur (“résume ce texte.”).
Configuration : les manifestes d’outils (“fonctions disponibles : [read_db, send_email]”).
Documentation : les fragments de contexte récupérés via RAG.
Puisque le LLM est un interpréteur probabiliste non typé, il prédit continuellement le prochain jeton logique en se basant sur le poids sémantique de l’ensemble de la fenêtre de contexte. Si les “données” non fiables contiennent des modèles sémantiques qui imitent fortement du “code” ou de la “configuration”, le modèle modifiera son comportement de manière transparente, exécutant les données comme s’il s’agissait d’une instruction système. C’est ce qu’on appelle la confusion instruction/données (Instruction/Data Conflation).
3. Confusion d’autorité contextuelle et élévation de privilèges du prompt
Lorsque les frontières de confiance s’effondrent, la conséquence immédiate est la confusion d’autorité contextuelle.
Dans un framework d’orchestration, différents composants ont différents niveaux d’autorité. Le prompt système a une haute autorité ; un document extrait du web a une faible autorité. Cependant, comme le LLM ne comprend que les poids mathématiques d’attention (et non des rôles RBAC codés en dur), un attaquant peut utiliser la manipulation sémantique pour gonfler artificiellement l’autorité de sa charge utile.
Des revues académiques récentes de 2026 (ex: MDPI Information 17/1/54 et des études arXiv associées sur le détournement de prompt) démontrent comment les attaquants parviennent à une élévation de privilèges de prompt (Prompt Privilege Escalation) au sein de la frontière effondrée :
1. Détournement de persona (Usurpation d'autorité)
l’attaquant intègre des phrases imitant des composants système de haute autorité au sein des données non fiables. Des chaînes telles que [OUTREPASSEMENT SYSTÈME], <|im_start|>system, ou ERREUR : MODE DÉBOGAGE REQUIS exploitent les données d’entraînement du modèle. Parce que le modèle a été affiné (fine-tuned) pour obéir aux formats de type système, il élève le privilège des données de l’utilisateur à celui d’une instruction système.
2. Exploitation de l'ambiguïté sémantique
le langage humain est intrinsèquement ambigu. Les attaquants conçoivent des charges utiles qui sont sémantiquement plus proches des descriptions d’outils du modèle que la requête utilisateur inoffensive. En l’absence de frontières strictes, le modèle résout l’ambiguïté sémantique en exécutant la charge utile de l’attaquant, la percevant comme l’interprétation la plus “statistiquement probable” de la fenêtre de contexte.
4. La manifestation de l’effondrement dans les exploits modernes
En reconnaissant l’effondrement de la frontière de confiance comme la cause première, nous pouvons démystifier l’ensemble de la taxonomie des attaques modernes contre l’IA Agentique. Chaque technique avancée que nous avons documentée dans le Hermes Codex n’est qu’une manifestation différente de la confusion entre instruction et données.
Empoisonnement RAG (Les données deviennent des instructions) : lorsqu’un pipeline RAG d’entreprise récupère un PDF empoisonné depuis SharePoint, le framework d’orchestration injecte le texte du PDF directement dans la fenêtre de contexte du LLM pour ancrer (ground) la réponse. Parce que la frontière est effondrée, la charge utile malveillante à l’intérieur du PDF cesse d’être une donnée passive ; elle est élevée au rang de contexte actif, détournant fondamentalement le flux logique de l’agent.
Empoisonnement d’outils (La documentation devient du code) : comme discuté dans notre analyse de la chaîne d’approvisionnement sémantique, les LLM s’appuient sur les descriptions de schémas JSON pour comprendre comment utiliser un outil. Un attaquant empoisonnant un registre tiers de Model Context Protocol (MCP) modifie la description de l’outil. Le LLM absorbe ces métadonnées comme une instruction système faisant autorité, permettant à une documentation externe de dicter l’exécution interne.
Mouvement latéral d’agent à agent (Les sorties deviennent des commandes) : dans les essaims multi-agents, l’Agent A traite des données Internet non fiables et les résume pour l’Agent B (un agent administrateur hautement privilégié). Parce que l’Agent B fait intrinsèquement confiance à la sortie de l’Agent A, l’effondrement de la frontière de confiance est effectivement transmis à travers le réseau, conduisant à une compromission systémique.
5. Pourquoi la sécurité Cloud échoue à protéger les agents IA
L’effondrement de la frontière de confiance ne se contente pas de briser le LLM ; il brise les modèles traditionnels de sécurité cloud et de gestion des identités et des accès (IAM) qui l’entourent.
Comme l’indique avec insistance le blog Microsoft Security (“Prompts become shells”, mai 2026), attacher un rôle IAM hautement privilégié (ex: un rôle AWS IAM ou une identité gérée Azure) au conteneur d’un agent IA repose sur une hypothèse dangereuse. La sécurité cloud suppose que le conteneur exécute du code compilé et déterministe (comme un backend Node.js ou Python) où le chemin d’exécution est strictement contrôlé par les développeurs.
Lorsque le conteneur héberge un LLM équipé d’outils (comme aws_s3_read ou execute_bash), le chemin d’exécution n’est plus contrôlé par le code ; il est contrôlé par le prompt.
En raison de cette frontière effondrée, tout utilisateur (ou toute source de données empoisonnée) qui influence la fenêtre de contexte du LLM hérite effectivement du rôle IAM attaché au conteneur. Les pare-feux d’application web (WAF) traditionnels et les outils de gestion de la posture de sécurité cloud (CSPM) ne peuvent pas inspecter l’intention sémantique d’un prompt en langage naturel, ce qui les rend totalement aveugles à l’exploitation de l’agent.
6. Rétablir la frontière (Atténuations architecturales)
Nous ne pouvons pas “patcher” un modèle Transformer pour séparer définitivement les instructions des données ; l’architecture est fondamentalement plate. Par conséquent, les architectes de sécurité doivent concevoir une “architecture de Harvard” pour l’IA au niveau de la couche d’orchestration, forçant la séparation des flux d’exécution.
Pour reconstruire la frontière de confiance, les organisations doivent séparer physiquement le traitement des données non fiables de l’exécution des outils privilégiés.
Le LLM Analyseur (Parser LLM) : ce modèle est strictement confiné (sandboxed). Il n’a aucun outil et aucune capacité de sortie réseau. Son seul rôle est d’ingérer les prompts utilisateurs non fiables et les données RAG, de les assainir, et d’en extraire des variables structurées (ex: JSON strict).
Le LLM Planificateur (Planner LLM) : ce modèle détient les outils hautement privilégiés. Il n’interagit jamais avec les entrées brutes de l’utilisateur. Il n’accepte que la sortie JSON déterministe et strictement typée fournie par le LLM Analyseur.
B. Génération structurée et contraintes d’exécution
S’en remettre au LLM pour générer du texte libre qui est ensuite parsé en arguments d’outils est une recette pour le désastre. Les frameworks doivent imposer une génération structurée (ex: en utilisant Outlines, Instructor, ou des API natives en mode JSON combinées à des schémas strictement évalués). Si l’interpréteur probabiliste tente de dévier de la structure mathématique codée en dur, le pipeline d’exécution doit échouer de manière sécurisée (fail-close) immédiatement.
Puisque la frontière cognitive est intrinsèquement instable, la frontière opérationnelle doit être absolue. Les agents ne doivent jamais posséder d’autorité ambiante. Chaque invocation d’outil doit nécessiter des jetons éphémères Just-In-Time (JIT) et une approbation humaine dans la boucle (HITL) hors bande pour les actions altérant l’état du système, garantissant qu’un détournement sémantique ne puisse pas mener à des dommages cinétiques.
7. Conclusion : la cause première des vulnérabilités de l’IA
L’intégration des grands modèles de langage dans les flux de travail des entreprises a généré une explosion de capacités innovantes, mais elle l’a fait en violant le principe le plus sacré de l’informatique : la séparation du code et des données.
L’effondrement de la frontière de confiance n’est pas un bug qui peut être corrigé avec plus d’entraînement RLHF, de meilleurs prompts système ou un simple filtrage par mots-clés. C’est une réalité architecturale inhérente au déploiement de machines de Von Neumann linguistiques. Chaque vulnérabilité majeure dans l’écosystème de l’IA Agentique — du Tool Injection à la compromission de serveurs MCP — est un symptôme en aval de cette faille fondamentale unique.
Tant que l’industrie de la cybersécurité ne cessera pas de traiter les injections de prompt comme de simples “hallucinations” ou “violations de la politique de contenu”, et ne commencera pas à les traiter comme des confusions d’autorité contextuelle qui contournent les contrôles IAM de l’entreprise, l’IA Agentique restera un risque massif et non atténué pour l’infrastructure des entreprises.