Pourquoi les agents IA sont vulnérables au prompt injection, et comment les protéger au niveau architectural

Dans les logiciels traditionnels, architecture et sécurité sont clairement séparées : il existe un périmètre, une authentification, une validation des entrées. Dans les systèmes d'IA, cette frontière s'estompe au point que les approches classiques cessent de fonctionner.

Le problème central : les agents IA réunissent ce qui a toujours été séparé — le plan de contrôle (control plane) et le plan de données (data plane). Dans une application classique, la commande de l'utilisateur est traitée par un code déterministe, et les données ne peuvent pas réécrire la logique. Dans un système LLM, tout texte présent dans la fenêtre de contexte influence potentiellement le comportement du modèle.

L'OWASP le formule ainsi : « Toutes les entrées ont le même poids de confiance, et le modèle ne peut pas distinguer intrinsèquement les instructions de confiance des données non fiables. » Il s'agit d'un changement architectural qui exige d'intégrer la sécurité dès la conception du système, et non de l'ajouter comme un filtre superficiel.

Principe 1 : la séparation de la confiance comme primitive architecturale

De nombreux architectes placent le contenu non fiable, les données internes et les instructions système dans la même fenêtre de contexte, en espérant que le modèle s'y retrouvera seul. C'est une erreur. La solution consiste à introduire un niveau de confiance explicite pour chaque fragment, avec une séparation imposée des couches.

Le système ne travaille pas avec des chaînes de prompt concaténées, mais avec des blocs de contexte typés. Chaque bloc reçoit des métadonnées de provenance et un niveau de confiance : les instructions système sont trusted, les données issues de la base interne sont internal, le contenu externe et les documents RAG sont untrusted. Les outils vérifient ces étiquettes avant toute exécution.

L'OWASP appelle cela « segregation of trust » et souligne, dès 2026, que ce n'est plus simplement une bonne pratique mais une exigence architecturale.

Principe 2 : isolation des outils et privilèges minimaux

Une erreur architecturale dangereuse consiste à donner au LLM accès à des outils disposant de droits excessifs. Cela peut être un outil de lecture capable de supprimer des documents, ou une connexion à une base de données avec des droits d'administrateur alors que seul un SELECT est nécessaire. La solution : attribuer à chaque outil l'ensemble minimal de droits nécessaires et un contexte d'exécution isolé.

Au lieu de transmettre au modèle des requêtes SQL, le système accepte des paramètres structurés (table, filtres, limite) et construit lui-même une requête paramétrée. Cela élimine toute une classe d'attaques par injection. Évitez les fonctionnalités ouvertes comme l'exécution de commandes shell ou de requêtes URL arbitraires. Utilisez des outils granulaires avec des restrictions : les outils de fichiers n'écrivent que dans un répertoire spécifique et avec une extension déterminée, les outils email n'envoient qu'à des adresses figurant sur une liste autorisée.

Principe 3 : contrôle de la mémoire et du corpus RAG

Le corpus RAG fait partie de la surface d'attaque, souvent plus dangereuse que le prompt lui-même. L'étude WARP a montré qu'il est possible d'injecter des documents « empoisonnés » dans le corpus de recherche, et qu'au moment du déclencheur, le RAG récupérera précisément ces documents. L'étude AgentPoison réussit dans 82 % des cas avec un taux d'empoisonnement inférieur à 0,1 % — un seul document malveillant sur mille peut suffire.

La protection comprend trois couches : le contrôle de la provenance de chaque document avec métadonnées et hachages de contenu, l'isolation des résultats de recherche marqués comme untrusted, et la surveillance de la dérive — détecter si la recherche commence à renvoyer des documents qu'elle ne renvoyait pas auparavant.

Principe 4 : le human-in-the-loop comme composant architectural

Il ne s'agit pas d'une fonctionnalité d'interface avec un bouton de confirmation, mais d'un composant intégré au runtime. Les actions sont classées par niveau de risque : LOW (lecture seule, données internes), MEDIUM (écriture en sandbox, notifications internes), HIGH (suppression, appels API externes, opérations financières). Les actions à risque HIGH nécessitent une confirmation — l'agent ne peut pas la contourner.

Des incidents réels confirment cette nécessité : CVE-2025-32711 (EchoLeak) — une injection de prompt dans Microsoft Copilot avec exfiltration de données zero-click ; CVE-2025-54135 et CVE-2025-54136 — des exécutions de code à distance (RCE) via injection de prompt dans l'implémentation MCP de l'IDE Cursor. Tous résultent d'erreurs architecturales, et non de défauts du modèle.

Il ne s'agit pas de rendre le modèle sûr. Il s'agit de concevoir la sécurité au niveau de l'architecture du système.