Le fossé sécurité agent-humain : ce que la production déploie, ce que la recherche étudie
Un papier UCLA du 23 mai 2026 audite 59 études académiques, 21 systèmes d'agents en production et 26 plugins de sécurité — et constate que les défenses préférées des chercheurs n'ont aucun déploiement en production.
De quoi s’agit-il ?
Le 23 mai 2026, trois chercheurs d’UCLA — Peiran Wang, Ying Li et Yuan Tian — ont publié Reframing LLM Agent Security as an Agent–Human Interaction Problem (arXiv:2605.24309). Le papier n’est ni une nouvelle attaque ni une nouvelle défense. C’est un audit systématique de la manière dont la sécurité des agents est réellement traitée en 2026 : il cartographie 59 papiers académiques, 21 systèmes d’agents en production et 26 plugins de sécurité, à la coupure d’avril 2026. Le résultat est l’un des instantanés les plus clairs publiés cette année sur l’écart entre la recherche en sécurité des agents et les systèmes effectivement déployés.
Fonctionnement
Wang et al. partent du constat que presque tous les agents en production — Claude Code, Cursor, Copilot, Gemini CLI, ChatGPT Agent, Microsoft 365 Copilot, assistants MCP — placent un humain quelque part dans la boucle. Le papier classe ces mécanismes d’Agent-Human Interaction (AHI) en cinq catégories :
- Spécification de politique — l’utilisateur écrit des règles en amont (« ne jamais pousser sur main », « pas de sortie réseau »). Adoptée par au moins 14 des 21 systèmes en production.
- Approbation à l’exécution — l’agent demande « puis-je exécuter cette commande / envoyer cet e-mail / appeler cet outil ? » avant chaque action sensible. Également adoptée par 14+ systèmes sur 21.
- Configuration de périmètre — l’utilisateur choisit des listes blanches de fichiers, d’outils, d’hôtes ou de domaines que l’agent peut toucher. Pareillement dominante.
- Ancrage d’intention — le système tente de relier chaque action à une intention utilisateur vérifiable avant exécution. Très étudié en recherche, zéro déploiement en production dans l’audit.
- Étiquetage de confiance — treillis de confiance ou étiquettes de provenance sur chaque jeton entrant dans le contexte, à la manière du contrôle de flux d’information. Très étudié, également zéro déploiement en production.
Le décalage est brutal : les trois catégories que les praticiens déploient effectivement reçoivent peu d’attention en recherche, tandis que les deux catégories préférées des chercheurs n’ont pas franchi le seuil d’un seul produit livré. Le papier impute cela à la charge cognitive. L’étiquetage de confiance, en particulier, exige des utilisateurs un raisonnement sur la provenance des données à une granularité qui ne correspond pas à leurs modèles mentaux — chaque jeton étiqueté, chaque flux suivi. La spécification de politique et la configuration de périmètre, bien que plus grossières, collent à la manière dont les opérateurs raisonnent déjà.
Les auteurs formalisent ensuite le mode de défaillance de l’approche dominante. L’approbation à l’exécution, étendue à de longues sessions d’agent, produit de la fatigue d’approbation : un agent de codage 2026 peut déclencher des dizaines d’appels d’outils par tâche, et les utilisateurs finissent soit par valider mécaniquement chaque invite, soit par désactiver complètement la boîte de dialogue. Les auteurs citent ce phénomène comme cause racine de plusieurs incidents d’injection indirecte en 2025-2026, où l’agent demandait dûment confirmation et où l’humain cliquait dûment « oui » sur une requête dont le contexte avait déjà été empoisonné.
Pourquoi c’est important
Ce recadrage a deux conséquences pratiques pour quiconque déploie un agent.
D’abord, il relocalise le problème de conception. La question n’est plus peut-on faire confiance au LLM pour décider ? mais à quel endroit du workflow d’alignement d’intention de l’humain le LLM apporte-t-il le plus de levier au moindre risque ? C’est une question d’UX avec des implications de sécurité, et elle rejoint ce que la Agents Rule of Two de Meta et la lethal trifecta de Simon Willison laissaient déjà entendre : la défense est architecturale, pas comportementale.
Ensuite, cela explique pourquoi tant de défenses impeccables sur papier échouent en audit. L’ancrage d’intention présuppose que les utilisateurs articuleront leur intention sous forme structurée. L’étiquetage de confiance présuppose qu’ils raisonneront sur des étiquettes. Aucune de ces hypothèses ne résiste à une véritable session d’agent de codage. Une SoK de décembre 2025 sur le Trust-Authorization Mismatch in LLM Agent Interactions (arXiv:2512.06914) parvient à une conclusion similaire par un autre angle : le modèle d’autorisation que l’utilisateur croit appliquer et celui que l’agent applique réellement divergent systématiquement.
Défenses
Le papier est descriptif, pas prescriptif, mais l’audit suggère une liste concrète pour les équipes qui déploient des agents à la mi-2026 :
- Privilégier la configuration de périmètre, pas l’approbation à l’exécution. Un agent correctement scopé réduit le nombre d’invites d’approbation, seul moyen de lutter contre la fatigue.
- Traiter la spécification de politique comme un artefact de premier ordre. Versionnez-la, faites-la passer en revue de code, livrez-la avec l’agent — comme vous le feriez d’une politique IAM.
- Réserver l’approbation à l’exécution aux actions irréversibles. Écritures en base, mouvements financiers, merges de code, envois externes. Tout le reste devrait être décidable par politique en amont.
- Ne pas s’appuyer uniquement sur l’ancrage d’intention ou l’étiquetage de confiance. Ce sont des directions de recherche utiles mais, selon l’audit, elles ne sont pas productisées. Empilez-les au-dessus des trois mécanismes dominants, pas à leur place.
- Mesurer la fatigue d’approbation. Journalisez le nombre d’approbations par session et le taux de clics. Un taux de 95 % de validation mécanique est un signal de sécurité plus parlant que n’importe quelle sortie de classifieur.
État
| Élément | Date | Statut |
|---|---|---|
| Papier déposé (arXiv:2605.24309) | 23 mai 2026 | Préprint public |
| Systèmes en production audités | Avril 2026 | 21 systèmes, 26 plugins |
| Corpus académique | 2022-2026 | 59 papiers |
| SoK liée (Trust-Authorization Mismatch) | Déc. 2025 | arXiv:2512.06914 |
| Adoption industrielle du cadrage AHI | En attente | Au stade de discussion |
Le papier est un préprint, non encore relu par les pairs à l’heure où ces lignes sont publiées. Sa contribution empirique — l’audit de 21 systèmes en production — est la partie la plus directement utile aux défenseurs aujourd’hui, et la moins susceptible de bouger dans une révision.