Architecturer des agents sûrs : une défense « plan et politique » contre l'injection de prompt

De quoi s’agit-il ?

Le 31 mars 2026, des chercheurs de NVIDIA et de leurs partenaires ont publié Architecting Secure AI Agents: Perspectives on System-Level Defenses Against Indirect Prompt Injection Attacks (arXiv:2603.30016). Il s’agit d’un position paper, pas d’une nouvelle attaque : son point de départ est que l’injection de prompt indirecte — des instructions malveillantes dissimulées dans des e-mails récupérés, des pages web ou des sorties d’outils, formalisée pour la première fois par Greshake et al. dans Not what you’ve signed up for (2023) — a peu de chances d’être résolue au seul niveau du modèle. Les auteurs se demandent plutôt comment le système autour du modèle doit être structuré pour qu’une seule chaîne injectée ne puisse pas dégénérer en action dangereuse.

Leur réponse est une architecture fondée sur deux concepts — le plan et la politique — et trois positions de conception sur l’endroit où doivent vivre les décisions de sécurité. L’un des co-auteurs, Kai Greshake, figurait sur le papier original sur l’injection indirecte, ce qui rend le cadrage notable : ceux qui ont nommé le problème soutiennent désormais que le correctif est architectural.

Comment ça fonctionne

Le papier introduit un vocabulaire pour analyser les agents. Un plan décrit ce que l’agent compte faire : une séquence ordonnée (ou un graphe) d’étapes d’exécution, chaque étape étant une action concrète avec ses entrées et sorties — par exemple GET_RECENT_EMAIL(sender=Alice) -> emails; SUMMARIZE(emails) -> summary; DRAFT_REPLY(summary) -> draft. Une politique décrit ce que l’agent est autorisé à faire : un prédicat sur les étapes et l’historique d’exécution qui marque chaque action comme permise ou non, induisant le sous-ensemble de plans que l’agent peut légalement exécuter. Les politiques vont des règles globales de contrôle d’accès statique (« ne jamais lire des données auxquelles l’utilisateur n’a pas accès ») à des contraintes de flux d’information dépendantes du contexte.

L’architecture de référence relie ces concepts dans des modules distincts plutôt que dans un modèle monolithique :

1. Un Orchestrateur (un LLM) transforme une tâche de haut niveau en un plan et une politique initiaux.
2. Un Approbateur de plan/politique revoit ce plan et cette politique, fournit un retour, et peut escalader vers un humain pour les objectifs ambigus.
3. Un Exécuteur (un LLM) transforme le plan approuvé en une action concrète, comme un appel d’outil avec ses arguments.
4. Un Contrôleur de politique approuve ou bloque chaque action proposée — via des vérifications par règles, un juge LLM, ou une confirmation humaine pour les étapes à haut risque — avant qu’elle n’atteigne l’environnement.
5. L’Environnement (API, web, système de fichiers) n’exécute que les actions approuvées et renvoie des réponses, qui peuvent déclencher des mises à jour du plan ou de la politique.

Point essentiel : le retour de l’environnement passe par des points de contrôle (les « boucliers » du papier) où le système peut transmettre le texte brut, le transformer ou le filtrer vers une représentation plus sûre, ou surveiller les anomalies — afin qu’une sortie d’outil non fiable ne devienne jamais silencieusement une nouvelle instruction.

Pourquoi c’est important

La plupart des agents déployés fusionnent tous ces rôles dans un seul modèle qui planifie, décide de ce qui est autorisé et agit dans un unique flux de tokens indifférencié — précisément la condition qui rend l’injection indirecte efficace, puisque le modèle ne peut pas séparer de façon fiable les commandes de confiance des données non fiables. En rendant le plan et la politique explicites et en les faisant appliquer par des composants distincts, l’architecture réduit la surface d’attaque : une instruction injectée dans un e-mail récupéré peut corrompre l’action proposée par l’Exécuteur, mais elle doit encore passer un Contrôleur de politique configuré indépendamment de ce contenu. Les auteurs avertissent aussi que les benchmarks actuels peuvent créer un « faux sentiment d’utilité et de sécurité », car ils testent souvent les modèles isolément plutôt que le système de bout en bout qui défendrait réellement un agent en production.

Défenses

La contribution du papier est un plan de défense, organisé en trois positions pour les praticiens qui construisent des systèmes agentiques :

• Replanification dynamique et consciente de la sécurité. Les plans statiques, en une passe, échouent dans les environnements réalistes. Le système doit pouvoir mettre à jour le plan et la politique à mesure que le contexte évolue — mais traiter chaque mise à jour comme un événement de sécurité, et non comme une réécriture libre.
• N’utiliser les LLM que là où c’est indispensable, et les contraindre. Les vérifications programmatiques par règles doivent gérer tout ce qui peut être formalisé (contrôle d’accès, listes d’autorisation). Réservez le jugement du LLM aux décisions réellement difficiles et dépendantes du contexte — et lorsqu’un LLM prend une décision de sécurité, limitez strictement ce qu’il peut observer et ce qu’il est autorisé à décider. Une entrée contrainte et un périmètre de décision étroit rendent le modèle bien plus difficile à manipuler.
• Considérer l’interaction humaine comme un élément central de conception. Les cas ambigus sont inévitables ; la supervision humaine ne peut donc pas être ajoutée après coup. Le défi ouvert est de réduire la fréquence des interventions humaines sans sacrifier ni la sécurité ni l’utilité.

Ces positions rejoignent le consensus défensif de 2026 — notamment Design Patterns for Securing LLM Agents against Prompt Injections et la « Agents Rule of Two » de Meta — selon lequel le moindre privilège, l’isolation du contenu non fiable et le contrôle déterministe des sorties relèvent de l’architecture du système, et non des seuls poids du modèle.

Statut

Il s’agit d’un position paper de la communauté (arXiv:2603.30016, publié le 31 mars 2026), et non d’une divulgation de vulnérabilité : il n’y a donc ni correctif ni CVE. Les auteurs décrivent l’architecture comme un « squelette » pour les futurs systèmes agentiques et appellent à des benchmarks qui évaluent des systèmes entiers plutôt que des modèles isolés. À retenir pour les équipes qui déploient des agents aujourd’hui : séparez la planification, la politique et l’application ; gardez les contrôles de politique programmatiques autant que possible ; et contraignez tout modèle utilisé pour une décision de sécurité à l’entrée et à l’autorité les plus étroites possibles.