Confusion d'autorité : quand l'agent outillé détourne son propre accès

De quoi s’agit-il ?

Le 27 mai 2026, des chercheurs de l’University of Notre Dame, d’Inria et de l’University of Liverpool ont publié sur arXiv AIRGuard: Guarding Agent Actions with Runtime Authority Control (arXiv:2605.28914). Le papier nomme un mode de défaillance qu’il appelle confusion d’autorité (authority confusion) et propose une défense au moment de l’exécution. L’idée tient en une phrase que les auteurs répètent : une donnée peut informer, mais seule l’autorité peut autoriser.

La confusion d’autorité, c’est l’écart entre ce qu’un agent a le droit de faire et ce qu’un contenu suggère qu’il devrait faire. Un agent outillé lit des fichiers, exécute des commandes shell, appelle des API, envoie des e-mails et invoque des outils MCP. Un contenu contrôlé par l’attaquant — page web, document récupéré, paquet, script d’aide, sortie d’outil MCP — peut décrire une action qui paraît pertinente isolément, mais qui redirige discrètement l’accès autorisé de l’agent vers l’objectif de l’attaquant. Le papier soutient que ce phénomène est distinct du jailbreak comme du prompt injection classique, et que les défenses fondées uniquement sur la séparation données–instructions ou sur la provenance des paramètres ne le traitent pas.

Comment ça marche

La distinction compte parce que l’étape malveillante est rarement suspecte par son type d’outil. Lire un fichier, envoyer un message, appeler une API métier ou modifier une configuration sont des actions routinières et légitimes. Le problème est de savoir quelle autorité les justifie.

Les exemples du papier sont parlants. Une documentation contrôlée par l’attaquant peut étiqueter une URL externe comme point de terminaison d’« audit » — mais cette étiquette n’autorise pas l’agent à y transmettre des rapports locaux, des identifiants ou des données de configuration. Un paquet peut contenir des instructions d’installation sans autoriser une persistance. Une sortie d’outil MCP peut suggérer un destinataire sans autoriser l’envoi d’un e-mail. Un script téléchargé peut aider à une tâche sans autoriser sa propre exécution. Dans chaque cas, les paramètres de l’action peuvent être bien ancrés dans les observations, alors que l’opération sort du périmètre réellement accordé par l’utilisateur.

C’est pourquoi les contrôles de provenance et de teinte (taint) ne suffisent pas à eux seuls : une preuve n’est pas une autorité. Un argument peut être parfaitement ancré dans un contenu récupéré tandis que l’effet de bord qui en résulte reste non autorisé.

Pourquoi c’est important

À mesure que les agents passent de la production de texte à la prise d’actions, le rayon d’impact d’une seule étape mal jugée s’élargit : exfiltration de données, empoisonnement de configuration, installation via la chaîne d’approvisionnement, divulgation non autorisée. La confusion d’autorité s’aggrave aussi sur plusieurs étapes — des actions individuellement plausibles peuvent former une séquence nuisible qu’aucun contrôle isolé ne signalerait.

Le papier quantifie l’écart sur deux benchmarks : AgentTrap (141 cas, dont 91 attaques de confusion d’autorité couvrant exfiltration, empoisonnement de config, abus de MCP, escalade de privilèges, etc.) et DTAP-150 (150 tâches de domaine MCP : code, système de fichiers, finance, juridique, télécoms). Sans défense, le taux de succès d’attaque (ASR) sur AgentTrap atteint 20,9 % avec Claude Haiku 4.5 et 36,3 % avec Claude Sonnet 4.6 — soit, grosso modo, du cinquième au tiers des attaques réussissant contre des modèles performants en boucle d’agent ordinaire.

Défenses

AIRGuard traite le moindre privilège comme un problème d’autorisation au moment de l’action, et non comme une simple affectation statique de permissions. C’est une couche de garde pré-action qui, avant chaque appel d’outil produisant un effet de bord, vérifie quatre choses : l’autorité héritée de la tâche utilisateur et de la politique, le niveau de confiance de la cible, le niveau de confiance de la source, et l’effet probable de l’action. Concrètement, le papier combine un mapping des capacités, un héritage d’autorité (l’autorité de la tâche peut se restreindre au niveau de l’étape, mais jamais s’étendre), des étiquettes de confiance ressource et cible, des réservoirs de confiance par source (les sources réputées peuvent informer l’exécution, les sources peu fiables déclenchent une inspection), une simulation des effets de bord pour les actions sensibles, une cascade d’application graduée, et un audit de séquence qui détecte le risque inter-étapes.

Deux leçons de conception dépassent ce seul système. D’abord, inviter n’est pas appliquer : dans l’ablation, mettre la politique dans le prompt seul ne fait passer l’ASR que de 22 % à 17 %, tandis que la garde d’exécution atteint 4 % — parce qu’elle observe les appels d’outils normalisés et intervient avant l’effet de bord, au lieu de demander au modèle de se surveiller lui-même. Ensuite, attendez-vous à une tension sécurité–utilité : des contrôles plus stricts réduisent les effets de bord non autorisés mais peuvent sur-bloquer le travail légitime ; l’application doit donc être sélective (les auteurs rapportent un peu de sur-défense, p. ex. 6 % sur l’ablation DTAP-150).

Pour les équipes qui déploient des agents aujourd’hui, l’enseignement actionnable est d’ajouter un contrôle d’autorisation déterministe à la frontière des outils, piloté par la tâche de l’utilisateur et votre politique — et non par le contenu que l’agent vient de lire.

Statut

Élément	Détail
Papier	AIRGuard, arXiv:2605.28914v1, publié le 27 mai 2026
Type	Recherche défensive (garde d’exécution), pas un exploit actif
Modèles testés	Claude Haiku 4.5, Claude Sonnet 4.6 ; ablations avec GPT-5.4-mini et GPT-5.3-codex
Résultat	ASR AgentTrap 20,9 %→3,3 % (Haiku), 36,3 %→5,5 % (Sonnet) ; meilleur palier d’ASR sur 3/4 modèles sur DTAP-150
Bases de comparaison	ARGUS, MELON

Les chiffres rapportés proviennent de l’évaluation des auteurs et reflètent leurs benchmarks et versions de modèles à la date de publication du papier (mai 2026).