Autoriser un outil n'est pas autoriser un appel dans les frameworks d'agents

De quoi s’agit-il ?

Le 27 juin 2026, un court article arXiv de David Mellafe Zuvic (2606.28679) a nommé précisément un défaut partagé par de nombreuses piles d’agents : elles traitent le fait qu’un outil soit exposé comme s’il valait autorisation. L’article audite trois briques très répandues — LangChain/LangGraph, LlamaIndex et le Stripe Agent Toolkit — autour d’une question étroite : avant qu’un appel d’outil émis par le modèle ne s’exécute, le framework revérifie-t-il les valeurs concrètes des arguments au regard d’une politique ? Sur les commits publics épinglés examinés, la réponse est identique pour les trois : ils contrôlent quels outils le modèle peut appeler, mais aucun ne fournit par défaut de vérification déterministe et fermée par défaut de ce que l’appel tente réellement de faire.

Ce manque est le problème classique du député confus (confused deputy), décrit par Norm Hardy en 1988 : un programme privilégié est amené par un appelant moins privilégié à détourner une autorité qu’il détient légitimement. La note de recherche de la Cloud Security Alliance de mars 2026 documente pourquoi ce motif refait surface comme une classe à fort impact dans les déploiements d’agents.

Comment ça marche

Un agent qui lit du contenu non fiable — un e-mail, un document récupéré, un résultat d’outil — tout en détenant des outils à effet de bord (paiements, messagerie, CRM, API d’infrastructure) n’a aucune frontière nette entre données et instructions. Si un attaquant peut écrire dans un canal que l’agent lit, le texte injecté peut orienter le modèle vers un appel d’outil que l’opérateur n’a jamais voulu.

Le point clé de l’audit est de savoir où la défense manque. Un garde-fou de capacité répond à « create_payment est-il un outil autorisé ? » — et il peut répondre oui à juste titre, puisque l’agent est censé effectuer des paiements. Ce qu’aucun contrôle par défaut ne tranche, c’est « cet appel create_payment, avec ces arguments (ce bénéficiaire, ce montant), est-il autorisé maintenant ? ». Faute de contrôle au niveau des arguments, une instruction injectée produisant un appel bien formé mais non autorisé passe :

# Garde-fou de capacité : passe — create_payment est un outil exposé
# Manquant : autorisation par appel sur les valeurs {payee, amount}
create_payment(payee="attacker-controlled", amount=9999)

L’article rapporte que ce même virement non autorisé s’exécute avec le dispatch par défaut de LangChain (avec une preuve de concept LlamaIndex associée), tandis que le même appel est refusé lorsqu’un garde-fou d’autorisation par valeur est placé devant l’exécution. Il n’y a ici aucune primitive d’exploitation inédite et l’article ne revendique aucun CVE — le constat est que la posture par défaut échoue de façon ouverte sur les valeurs.

Pourquoi c’est important

Les agents sont de plus en plus reliés à des outils aux effets irréversibles : envoyer de l’argent, diffuser du courrier à de nombreux destinataires, modifier des contrôles d’accès, supprimer des données. Quand la seule couche d’application est le suivi d’instructions du modèle lui-même, une seule injection réussie hérite de toute l’autorité de l’opérateur. La note de la CSA relie cela à un incident réel de chaîne d’approvisionnement en 2026, où un ticket de dépôt forgé a poussé un agent de code authentifié à installer un paquet contrôlé par l’attaquant — la chaîne du député confus en conditions réelles, pas seulement sur le papier.

Les architectures multi-agents aggravent le tableau : un sous-agent qui fait confiance à son orchestrateur via le même canal que ses instructions légitimes propagera une seule injection à travers plusieurs jeux d’identifiants, sans humain dans la boucle à chaque étape.

Défenses

Réautorisez chaque appel sur ses valeurs, pas seulement sur son nom. Placez un point de décision de politique devant le dispatch d’outils qui évalue les arguments concrets — bénéficiaire, montant, liste de destinataires, ressource cible — et refuse par défaut. Le modèle de référence de l’article, ScopeGate, structure cela en cinq étapes : portée (scope), autorisation, plafond monétaire, idempotence et refus par défaut. Vous n’avez pas besoin de cette implémentation exacte ; il vous faut la propriété qu’une valeur non autorisée soit rejetée de manière déterministe, avant exécution.

Traitez le contenu récupéré comme des données, jamais comme des instructions. Ne faites provenir les instructions déclenchant une action que de principaux autorisés. Le contenu issu de pages web, e-mails, documents et réponses d’outils ne doit pas pouvoir déclencher seul un appel à effet de bord.

Exigez une confirmation humaine pour les actions irréversibles. Paiements, envois de masse, changements d’identifiants et suppressions doivent requérir une approbation explicite hors bande, appliquée au niveau du runtime, quelle que soit l’origine apparente de l’instruction.

Restreignez les identifiants, ne cédez pas une autorité ambiante. Remplacez les larges concessions OAuth par des concessions étroites, par usage ; donnez à l’agent sa propre identité pour que les actions anormales ressortent. Limitez le rayon d’impact (plafonds de dépense, destinataires/domaines en liste blanche) afin qu’un député confus ait peu de marge.

Rendez chaque transfert d’autorité explicite dans les graphes multi-agents. Les sous-agents ne doivent pas hériter implicitement des permissions d’un orchestrateur ; journalisez et signez les messages inter-agents pour qu’un orchestrateur manipulé ne puisse déléguer en silence.

Statut

Élément	Détail
Source	arXiv 2606.28679, « Capability Gates Are Not Authorization » (soumis le 27 juin 2026)
Audité	LangChain/LangGraph, LlamaIndex, Stripe Agent Toolkit (commits publics épinglés)
Constat	Contrôle de capacité présent par défaut ; pas d’autorisation par appel, fermée par défaut, sur les valeurs
Contrôle de référence	ScopeGate (PDP/PEP) — portée, autorisation, plafond monétaire, idempotence, refus par défaut
Résultats rapportés	Le virement non autorisé s’exécute avec LangChain par défaut ; refusé par le garde-fou testé (0/48 contournements statiques, 0/29 tentatives adaptatives, 0/10 refus à tort)
CVE	Aucun revendiqué par l’auteur
Contexte	Note de recherche CSA sur les attaques par député confus contre les agents (publiée le 23 mars 2026)

Cet article synthétise des recherches défensives publiquement divulguées et ne contient aucune instruction d’attaque opérationnelle.