La sécurité des agents est un problème de système : traiter le modèle comme non fiable

Qu’est-ce que c’est ?

Le 18 mai 2026, un collectif de chercheurs de Google, UC San Diego, l’université du Wisconsin–Madison, Meta FAIR, Cornell et EmbraceTheRed a publié un position paper intitulé Agent Security is a Systems Problem (arXiv:2605.18991, licence CC BY 4.0). Sa thèse tient en une phrase : le modèle d’IA qui anime un agent doit être traité comme un composant non fiable, et les invariants de sécurité doivent être imposés au niveau du système qui l’entoure, et non à l’intérieur du modèle.

Cette posture rompt délibérément avec l’approche dominante, qui fait du modèle l’objet premier de la sécurité et cherche à le rendre robuste par l’alignement et l’entraînement. Les auteurs — parmi lesquels des noms reconnus en ML adverse et en sécurité des systèmes — rappellent que c’est le pari que la discipline a déjà perdu une fois, à l’époque du « ML adverse classique » des modèles de vision, où les défenses fondées sur le modèle ont été contournées à répétition. Le papier a été repris dans la revue agentique de juin 2026 d’Adversa AI parmi les lectures notables du mois.

Comment ça fonctionne

Le papier transpose des décennies de doctrine de sécurité des systèmes vers les agents. L’architecture de référence sur laquelle il s’appuie comporte quatre éléments : une base de calcul de confiance (TCB) dont l’intégrité échappe à l’attaquant, une politique de sécurité qui déclare ce qui est autorisé, un moniteur de référence intégré à la TCB qui vérifie chaque requête face à cette politique, et un système non fiable de l’autre côté d’une frontière de sécurité. Sur cette ossature, les auteurs énoncent cinq principes que les agents violent couramment :

Principe	Ce qu’il exige
Moindre privilège	Un composant ne reçoit que les permissions nécessaires à sa tâche, pas davantage
Résistance à l’altération de la TCB	Le noyau de confiance ne peut être modifié par une entrée non fiable
Médiation complète	Toute requête franchissant la frontière est vérifiée — aucune ne contourne le moniteur
Flux d’information sécurisé	Les données sensibles ne doivent pas fuir vers des destinations non fiables, même par canal auxiliaire
Maillon humain faible	Les mécanismes doivent supposer que utilisateurs, administrateurs et développeurs commettront des erreurs

Pour montrer que la démonstration est descriptive et non abstraite, les auteurs analysent onze attaques réelles, déjà publiques contre des agents en production et associent chacune aux principes qu’elle a enfreints. La liste se lit comme un journal d’incidents 2025–2026 : exfiltration via Microsoft Copilot, « AgentFlayer » sur Cursor, exfiltration via Claude Code, ports exposés et fuites de secrets de Devin AI, « SpAIware » dans la mémoire longue de ChatGPT, prompt injection sur ChatGPT Operator, prise de contrôle de compte DeepSeek, Terminal DiLLMa, exécution de commande arbitraire dans Amp, et « AI ClickFix ». Dans le tableau 1 du papier, chacune viole le Flux d’information sécurisé, et la plupart enfreignent au moins deux principes à la fois — c’est tout l’argument : il ne s’agit pas de onze bugs sans rapport, mais d’une seule architecture manquante observée onze fois.

Deux de leurs exemples détaillés sont instructifs sans être actionnables. Dans le cas de la mémoire de ChatGPT, une injection de prompt indirecte logée dans un document non fiable a écrit des instructions de l’attaquant dans le magasin « Mémoires » réputé de confiance de l’application (défaut de résistance à l’altération de la TCB), l’application pouvait joindre des serveurs arbitraires quelle que soit la demande de l’utilisateur (moindre privilège), et les données de conversation ont ensuite fui via l’URL d’une image rendue (flux d’information). Dans le cas de Claude Code, une instruction injectée dans un fichier de code a fait lire à l’agent un fichier .env et exfiltrer le secret via un ping figurant sur liste blanche, dont la résolution DNS transportait la donnée — l’agent disposait d’un accès shell plus large que la tâche ne l’exigeait, et une donnée sensible a atteint un résolveur non fiable.

La moitié la plus difficile du papier explique pourquoi cela ne se corrige pas facilement. Les agents ne s’inscrivent pas proprement dans l’architecture classique. Une application traditionnelle est mono-usage : un développeur peut écrire une politique fixe au moment de l’installation. Un agent reçoit un objectif ouvert en langage naturel, compose des outils à l’exécution, suit des liens qu’il découvre et affine des tâches sous-spécifiées au fil de l’eau — sa politique est donc floue, dynamique et exprimée en prose. Les auteurs comparent cela au chargement dynamique de code sur le web, que le navigateur a discipliné avec la Content Security Policy, la Same-Origin Policy, le bac à sable des <iframe> et la Subresource Integrity. Les agents n’ont rien de tout cela : la provenance d’une instruction est difficile à établir, et le cloisonnement via des mécanismes comme l’Instruction Hierarchy reste probabiliste au mieux. Pire, utiliser un « LLM de sûreté » comme moniteur de référence réintroduit le problème qu’on cherchait à fuir : une TCB probabiliste, sans contrat formel, elle-même attaquable.

Pourquoi c’est important

Ce papier est un cadre, pas un correctif, et c’est là sa valeur. Si l’on admet que la séparation des instructions et des données fondée sur le modèle « sera toujours contournée par des attaquants persistants » — la conjecture explicite des auteurs, cohérente avec le triangle mortel et les arguments d’intégrité contextuelle sur la prompt injection — alors investir uniquement dans un modèle plus robuste relève d’une mauvaise allocation de budget. Le levier se trouve dans l’échafaudage autour du modèle.

Le papier offre aussi un vocabulaire commun aux défenseurs. « Notre agent s’est fait prompt-injecter » donne peu de prise ; « cet incident a violé le Moindre privilège et le Flux d’information sécurisé, et notre moniteur de référence n’avait pas une médiation complète sur l’outil ping » désigne exactement le contrôle à construire. Le tableau des onze attaques transforme une année de gros titres en une liste de modes de défaillance à éprouver sur son propre déploiement.

Le papier conclut en nommant trois problèmes de recherche qu’il reconnaît non résolus : (1) la séparation prouvable des instructions et des données (l’analogue agentique de la protection mémoire W⊕X, probablement nécessaire mais pas suffisante) ; (2) la génération vérifiable de politique — traduire une intention floue en langage naturel vers une politique formelle de moindre privilège qu’un moniteur déterministe peut imposer, avec garantie de correction ; et (3) le contrôle de flux d’information capable de démêler les sources de données une fois que le LLM les a mélangées dans son contexte. Aucun n’est disponible aujourd’hui. Considérez tout discours « à l’épreuve de la prompt injection » comme une exagération de l’état de l’art.

Défenses

La prescription du papier est une défense en profondeur implémentée en dehors du modèle. Concrètement :

1. Traitez le modèle comme non fiable par défaut. Supposez que toute entrée ingérée par l’agent — documents, pages web, sorties d’outils, événements de calendrier, notifications — peut porter des instructions hostiles, et que le modèle peut les suivre. Concevez de sorte qu’un modèle compromis soit contenu, pas catastrophique. Cela rejoint la posture « traiter l’agent comme un processus ».

2. Imposez le moindre privilège par tâche, pas par session. Le cas du ping de Claude Code est un défaut de moindre privilège : l’agent détenait un accès shell large à un instant où la tâche ne l’exigeait pas. Cantonnez l’accès aux outils au sous-objectif courant et révoquez-le ensuite. Voir le motif de la règle de deux pour une contrainte pratique.

3. Placez un moniteur de référence déterministe sur le chemin de toute action conséquente. Visez la médiation complète : réseau sortant, écritures de fichiers, exécution shell et lecture de secrets doivent tous franchir un même point de contrôle consultant une politique explicite. Évitez de faire d’un LLM le seul arbitre de cette décision.

4. Ajoutez des contrôles de flux d’information en sortie. La plupart des onze attaques se terminaient sur un canal d’exfiltration. Étiquetez les sources sensibles, et bloquez ou assainissez les flux des données de haute confiance vers des destinations de basse confiance — URL d’images rendues, requêtes DNS, webhooks, HTTP sortant. C’est aussi l’esprit de mesures éditeurs comme le verrouillage d’exfiltration d’OpenAI.

5. Concevez pour le maillon humain faible. Une demande d’approbation qui déforme ce qui est approuvé, ou qui surgit si souvent que l’utilisateur l’accepte machinalement, n’est pas un contrôle. Réservez la revue humaine aux actions à fort rayon d’impact et faites en sorte que l’invite décrive ce qui va réellement se passer.

6. N’attendez pas les briques non résolues. La séparation prouvable instructions/données, la génération vérifiable de politique et le contrôle de flux complet sont des problèmes de recherche. En attendant, compensez par des frontières grossières mais déterministes : exécution en bac à sable, listes blanches réseau imposées sous l’agent, et identifiants de moindre privilège.

Statut

Élément	Référence	Date	Notes
Position paper publié	arXiv:2605.18991v1 [cs.CR]	2026-05-18	Google, UCSD, UW–Madison, Meta FAIR, Cornell, EmbraceTheRed ; CC BY 4.0
Attaques réelles analysées	Papier §2.2 + Annexe A	2024–2026	11 cas représentatifs mappés sur 5 principes ; tous violent le Flux d’information sécurisé
Problèmes ouverts nommés	Papier §3	2026-05-18	Séparation instructions/données, génération vérifiable de politique, contrôle de flux — tous non résolus
Reprise par la communauté	Revue Adversa AI de juin 2026	2026-06-01	Classé en « Article » : la sécurité des agents comme problème de système, pas de modèle

À retenir : ce n’est pas une nouvelle attaque, mais une re-catégorisation. Les incidents d’agents de l’année écoulée ne sont pas un problème de robustesse de modèle que les labos finiront par entraîner, mais un problème de sécurité des systèmes que la discipline sait déjà raisonner — et qu’elle n’a pas encore fini d’ingénier pour les agents.