Parallax : placer la sécurité des agents dans l'architecture, pas dans le prompt

De quoi s’agit-il ?

Parallax est un paradigme défensif exposé dans un position paper, « Parallax: Why AI Agents That Think Must Never Act », déposé sur arXiv le 14 avril 2026 (arXiv:2604.12986, par le chercheur indépendant Joel Fokou). Son argument est direct : la façon dominante de sécuriser les agents — écrire des consignes de sécurité dans le prompt système — opère au même niveau d’abstraction que les attaques qu’elle prétend bloquer, et ne tient donc plus dès que le modèle est manipulé. L’auteur propose de déplacer la frontière de sécurité hors du langage naturel pour la faire passer dans l’architecture du système, et fournit une implémentation de référence open source (OpenParallax, écrite en Go) pour montrer ce que cela donne en pratique.

C’est une proposition à un seul auteur, avec un prototype et une évaluation menée par l’auteur lui-même, et non un résultat reproduit indépendamment. Nous la couvrons parce qu’elle nomme avec netteté une faille qui revient dans presque tous les incidents d’agents : quand le composant de raisonnement est compromis, les contrôles qui vivent à l’intérieur de ce composant disparaissent avec lui.

Comment ça marche

Parallax part d’une distinction que le paper qualifie de différence de nature, pas de degré. Un LLM conversationnel produit du contenu ; un agent produit des actions — écritures de fichiers, commandes shell, appels d’API, modifications de base de données. L’entraînement à la sûreté répond à la question « le modèle produit-il la bonne chose ? ». La sécurité d’un agent doit répondre à « le système fait-il la bonne chose ? » — même quand le modèle a déjà été convaincu de faire la mauvaise.

La critique en trois points des garde-fous au niveau du prompt mérite d’être reprise, car chaque point renvoie à des attaques que nous avons documentées :

• Même substrat que la menace. Instructions et données non fiables transitent par un seul mécanisme d’attention, sans séparation structurelle — la condition même qui rend possible la prompt injection.
• Dégradation en contexte long. L’historique cumulé déplace la frontière effective des contraintes, et l’empoisonnement de mémoire peut implanter des instructions qui persistent d’une session à l’autre.
• Pas de survie à la propagation multi-agents. Dès que la sortie d’un modèle devient l’entrée d’un autre, une seule injection traverse toutes les couches en aval.

Face à cela, Parallax propose quatre principes, tous empruntés à des pratiques anciennes de sécurité des systèmes plutôt qu’inventés pour l’IA :

1. Séparation cognitif–exécutif. Le composant qui raisonne sur une action est rendu structurellement incapable de l’exécuter, et le composant qui exécute est incapable de raisonner. C’est la séparation de privilèges (Provos et al.) appliquée aux agents : la frontière vit dans l’isolation de processus, pas dans la retenue du modèle.
2. Validation adversariale à déterminisme gradué. Un validateur indépendant et multi-niveaux s’interpose entre raisonnement et exécution et décide si une action proposée est autorisée. Point clé : le validateur est immuable vis-à-vis de ce qu’il valide — la même logique d’ancre de confiance qu’un TPM ou un HSM.
3. Contrôle de flux d’information. Des étiquettes de sensibilité des données se propagent dans le workflow (politique de type Bell-LaPadula), ce qui permet de détecter les menaces dépendantes du contexte comme « lis ce fichier privé, puis émets une requête sortante » — le lethal trifecta exprimé comme règle de flux.
4. Exécution réversible. L’état est capturé avant toute action destructrice, afin de pouvoir revenir en arrière quand la validation échoue.

La version en une phrase, tirée du paper : le système qui raisonne sur les actions doit être structurellement incapable de les exécuter, et le système qui exécute les actions doit être structurellement incapable de raisonner, avec un validateur indépendant et immuable interposé entre les deux. Aucun exploit n’est reproduit ici — la contribution est une architecture, pas une attaque.

Pourquoi c’est important

L’idée la plus utile du paper est sa méthode d’évaluation, l’Assume-Compromise Evaluation : au lieu de tester si le modèle peut être jailbreaké, les auteurs supposent qu’il l’est déjà, contournent entièrement le système de raisonnement, et injectent des appels d’outils malveillants directement à la frontière d’exécution. C’est la bonne question pour des agents en production, parce qu’elle cesse d’évaluer la partie du système que tout le monde sait déjà peu fiable et commence à évaluer la partie censée contenir les dégâts.

Sous ce test — 280 cas adversariaux répartis en neuf catégories d’attaques — l’implémentation de référence rapportée bloque 98,9 % des attaques avec zéro faux positif dans sa configuration par défaut, et 100 % dans une configuration de sécurité maximale. À prendre comme des chiffres de prototype auto-rapportés, pas comme un benchmark établi. La partie durable est la thèse structurelle qui les sous-tend : un garde-fou au niveau du prompt offre zéro protection quand le système de raisonnement est compromis, puisqu’il n’existe qu’à l’intérieur du système compromis. Une frontière architecturale, elle, tient quel que soit ce que le modèle a été amené à tenter.

Tout cela arrive au moment où l’industrie a ouvertement admis que la prompt injection n’est peut-être pas entièrement soluble au niveau du modèle — la même conclusion atteinte, par des chemins très différents, par les travaux affirmant que les agents finiront toujours par céder à la prompt injection et par la lecture de la sécurité des agents comme problème de systèmes. Parallax est un vote de plus pour le même virage : cesser de vouloir rendre le modèle parfaitement fiable, et concevoir pour qu’un modèle peu fiable ne puisse pas causer de dégât irréversible. Cela fait directement écho à la règle de deux des agents et à l’autorisation d’outils basée sur la tâche.

Défenses

Parallax est une proposition de défense ; ses enseignements sont donc des patterns architecturaux applicables sans adopter son implémentation précise :

• Séparez le planificateur de l’exécuteur. Ne laissez pas le composant qui ingère du contenu non fiable être celui qui détient les privilèges d’exécution. Placez une frontière de processus ou de confiance entre « décider » et « faire ».
• Interposez un validateur indépendant que l’agent ne peut pas modifier. Ce qui contrôle une action ne doit partager ni état, ni prompt, ni mémoire avec la boucle de raisonnement — sinon compromettre le raisonneur compromet le contrôle. C’est la logique derrière les garde-fous à bornes prouvables.
• Rendez les actions destructrices réversibles. Faites un instantané avant les écritures, suppressions et changements de configuration, afin qu’une mauvaise action soit un incident dont on revient, pas une brèche que l’on découvre plus tard.
• Suivez le flux des données, pas seulement les appels isolés. Étiquetez les données sensibles et bloquez les flux qui combinent lecture privée et canal sortant — le trifecta est une propriété du chemin, pas d’une étape unique.
• Supposez la compromission quand vous testez. Évaluez votre frontière en injectant des actions au-delà du modèle, pas seulement en tentant de le jailbreaker. Si votre récit de sécurité s’effondre quand on suppose le modèle hostile, ce récit était le modèle.

Une réserve que le paper soulève lui-même : l’enforcement architectural ajoute de la latence et un coût d’ingénierie, et un validateur trop grossier bloquera du travail légitime. Le propos n’est pas que les chiffres de Parallax soient définitifs, mais que la frontière a sa place dans l’architecture.

Statut

Élément	Valeur
Source	arXiv:2604.12986v1, « Parallax: Why AI Agents That Think Must Never Act »
Auteur	Joel Fokou (chercheur indépendant)
Publication	14 avril 2026
Type	Position paper + implémentation de référence open source (OpenParallax, Go)
Thèse centrale	La sécurité des agents doit être appliquée architecturalement ; les garde-fous au niveau du prompt échouent sous un raisonneur compromis
Résultat rapporté	98,9 % des 280 cas adversariaux bloqués, 0 faux positif (défaut) ; 100 % (sécurité max) — prototype, auto-rapporté
Maturité	Proposition mono-auteur ; pas encore reproduite indépendamment