Tool Misuse et Excessive Agency : quand les agents IA ont trop de droits

L'Excessive Agency désigne une autonomie, des autorisations ou des fonctionnalités trop étendues chez un agent IA : il peut faire plus que ce que sa tâche exige. Le Tool Misuse est l'usage abusif d'outils légitimes : l'accès est autorisé, l'utilisation ne l'est pas. Les deux entraînent des actions non voulues, des fuites de données et des coûts incontrôlés. Dans la classification de l'OWASP, l'Excessive Agency forme le cadre dans lequel le Tool Misuse se matérialise en risque agentique concret.

• Réponse rapide 1 : L'Excessive Agency est la cause (trop d'autonomie ou de droits), le Tool Misuse la conséquence (un outil légitime est utilisé de manière non sécurisée ou détourné de sa finalité).
• Réponse rapide 2 : L'OWASP classe le sujet dans le LLM Top 10 2025 sous LLM06:2025 et dans l'Agentic Top 10 2026, publié le 9 décembre 2025, sous ASI02 (Tool Misuse & Exploitation).
• Réponse rapide 3 : Les contre-mesures clés sont le moindre privilège, des jetons à portée limitée et de courte durée, une validation humaine pour les actions critiques et des limites strictes de débit ou de coûts.

Pourquoi « avoir trop de droits » est le vrai problème des agents

Les applications LLM classiques répondent : un prompt entre, une complétion sort. Les systèmes agentiques planifient, choisissent des outils, écrivent en mémoire et agissent, avec une validation humaine minimale à chaque étape. C'est précisément ce passage de « répondre » à « agir » qui fait des autorisations la question de sécurité centrale.

L'OWASP regroupe cela dans le LLM Top 10 2025 sous LLM06:2025 Excessive Agency : le fait d'accorder aux LLM une autonomie d'action non contrôlée alors que la délimitation des autorisations ou la supervision humaine est insuffisante. Cette entrée a été explicitement étendue aux architectures agentiques en 2025 et fait ainsi le pont entre les risques liés aux LLM et ceux liés aux agents. L'Excessive Agency précède directement plusieurs risques de l'OWASP Top 10 pour les applications agentiques 2026, à savoir ASI02 (Tool Misuse), ASI03 (Identity & Privilege Abuse) et ASI10 (Rogue Agents).

L'Excessive Agency apparaît généralement à trois niveaux :

• Trop d'autorisations : l'agent hérite de droits trop larges de l'utilisateur ou du compte de service sous lequel il tourne.
• Trop de fonctionnalités : l'agent dispose d'outils dont sa tâche n'a absolument pas besoin (par exemple un outil de suppression ou de paiement pour un cas d'usage en lecture seule).
• Trop d'autonomie : des actions critiques s'exécutent sans confirmation, par exemple via des modes d'approbation automatique ou « YOLO » activés.

Tool Misuse (ASI02) : accès légitime, usage illégitime

La description de l'ASI02 par l'OWASP est précise : l'agent opère dans le cadre de ses privilèges autorisés, mais applique un outil légitime de manière non sécurisée ou non prévue. Il supprime des données précieuses, appelle de façon excessive des API coûteuses, exécute des opérations destructrices ou exfiltre des informations. La distinction avec l'ASI03 est importante : l'accès est légitime, l'usage ne l'est pas.

Vecteurs d'attaque et d'erreur typiques :

• Injection de prompt qui détourne un outil, par exemple send_email, soudain utilisé pour une campagne de phishing contre toute la base clients.
• Désalignement entre l'interprétation de la tâche par l'agent et l'intention du développeur.
• Délégation non sécurisée : l'agent transmet un outil puissant à un sous-agent sans garde-fous contextuels.
• Modes d'approbation automatique ou « YOLO » qui désactivent les demandes de confirmation.

Les risques concrets : actions, données, coûts

Les trois dimensions du dommage se distinguent clairement :

La dimension des coûts est particulièrement délicate dans l'univers des agents : l'OWASP la classe dans le LLM Top 10 sous LLM10:2025 Unbounded Consumption (« denial-of-wallet »). Les plans à plusieurs étapes multiplient la consommation de jetons, c'est pourquoi chaque plan a besoin d'un budget appliqué de manière stricte.

Incidents documentés (état en 2026)

Parmi les cas documentés publiquement figurent les suivants :

• Amazon Q Code Assistant (CVE-2025-8217, juillet 2025) : Des attaquants ont compromis un jeton GitHub et injecté des instructions malveillantes dans l'extension VS Code v1.84.0. Des prompts destructeurs combinés aux flags --trust-all-tools et --no-interactive auraient effacé des systèmes de fichiers et des ressources cloud sans confirmation (The Register). L'extension était installée chez environ 1 million de développeurs ; le correctif est arrivé avec la v1.85.0.
• OpenAI Operator (Embrace The Red, Johann Rehberger, février 2025) : Une injection de prompt dans une issue GitHub a amené l'agent à ouvrir des pages de compte connectées et à divulguer des données privées, comme l'adresse e-mail sur Hacker News ou l'adresse et le numéro de téléphone sur Booking.com (Embrace The Red).
• Langflow (CVE-2025-3248) : Ce framework d'agents très répandu permettait, dans les versions antérieures à 1.3.0, d'exécuter du code sans authentification (CSA Singapour). Selon CrowdStrike, plusieurs acteurs malveillants exploitent depuis avril 2025 une faille critique de Langflow pour s'implanter, voler des identifiants et injecter des malwares. Il s'agit d'une vulnérabilité du framework lui-même et non d'un Tool Misuse au sens strict : ici, c'est la plateforme d'agents qui devient la cible.

Expérience de pensée : la limite qu'on fait sauter à force de persuasion

Dans les blogs de sécurité circule une cascade d'achats dans l'industrie manufacturière, par exemple chez Stellar Cyber. Nous n'avons pas trouvé de source primaire vérifiable. Ce cas ne vaut donc que comme expérience de pensée : sur trois semaines, un agent d'achat est progressivement « convaincu » que sa limite d'autorisation s'élève à 500 000 dollars américains. L'attaquant passe ensuite de fausses commandes pour 5 millions de dollars américains en 10 transactions. La leçon : une limite qui n'existe que dans le contexte de l'agent peut être levée par la persuasion. Elle doit figurer comme limite stricte dans l'outil ou dans la passerelle.

Contre-mesures : une défense en couches

Les mesures suivent le cycle de vie d'un agent. Point important : aucune protection isolée ne suffit. Les couches se complètent.

S'y ajoutent deux principes d'architecture. Premièrement, le modèle de passerelle ou de proxy placé devant chaque agent, point central d'application des listes d'autorisation, de la validation de schéma, des plafonds de coûts, des limites de débit et de la journalisation d'audit. Deuxièmement, la question de l'identité : chaque agent est une identité non humaine (NHI) à part entière, avec son propre cycle de vie des identifiants, des jetons de courte durée et un provisionnement just-in-time. Une erreur de déploiement fréquente consiste à faire tourner un agent « pour que ça marche » sous un compte de service doté de droits équivalents à ceux d'un administrateur. Il est plus sûr d'utiliser l'identité déléguée de l'utilisateur : l'agent agit sous l'identité de la personne et reste limité à ses droits.

Un mot sur l'efficacité de la validation humaine : dans la pratique, ces points de validation se dégradent souvent. L'OWASP en fait un risque à part entière, ASI09 (Human-Agent Trust Exploitation). Le biais d'automatisation et une sortie au ton faisant autorité conduisent à valider les yeux fermés. Des points de validation efficaces imposent donc la vérification indépendante des éléments de preuve, et pas seulement l'approbation de la recommandation de l'agent.

Exemple : les autorisations d'un agent de newsletter

Un agent marketing doit créer et envoyer des brouillons de newsletter. L'Excessive Agency apparaît s'il obtient un accès complet au système de messagerie. Le moindre privilège en pseudocode :

```
agent_role: "newsletter-draft"
tools:

• read_segment: scope=audience.read rate_limit=20/min
• create_draft: scope=campaign.write rate_limit=10/min
• send_campaign: scope=campaign.send rate_limit=2/h
  require_human_approval=true # Gate : vérifier destinataires + contenu
  deny:
• delete_contact, export_audience, billing.*
  budget:
  token_cap=500000/day usd_cap=20/day circuit_breaker=on
  token:
  type=short_lived ttl=15min
  ```

Effet : même en cas d'injection de prompt réussie, l'agent ne peut ni exporter ni supprimer de contacts, ni surcharger une API de masse payante, ni envoyer une campagne sans validation humaine. Le jeton de courte durée et à portée limitée rend sans valeur les identifiants dérobés au bout de 15 minutes.

Pour les agences et le B2B

Si tu exploites des agents IA pour des clients dans le marketing, la vente ou le service client, tu es responsable de la conception de leurs autorisations. Pour démarrer concrètement : recense pour chaque agent chaque outil et chaque portée, désactive l'approbation automatique pour tout ce qui supprime des données, déplace de l'argent ou envoie des messages, et fixe des limites strictes de coûts et de débit avant qu'un agent passe en production. Basée à Vienne, Blck Alpaca accompagne les organisations B2B de toute l'Europe dans la mise en place d'architectures d'agents conformes au moindre privilège, en s'appuyant sur l'OWASP Agentic Top 10. Remarque : cet article a une vocation purement informative et ne constitue pas un conseil juridique ; pour les questions concrètes de conformité et de responsabilité, adresse-toi de préférence à des conseillers qualifiés.