Excessive Agency (LLM06) : limiter un agent IA

Qu'est-ce que l'Excessive Agency (LLM06:2025) ?

C'est la vulnérabilité qui permet des actions dommageables en réponse à des sorties inattendues, ambiguës ou manipulées d'un modèle, quelle que soit la cause du dysfonctionnement. L'OWASP cite parmi les déclencheurs courants l'hallucination et l'injection de prompt.

Le point clé : la faille ne vient pas du modèle qui se trompe, mais du fait qu'on lui a donné le pouvoir d'agir sans garde-fou. Un modèle se trompera toujours de temps en temps, et un attaquant pourra toujours tenter de le manipuler. Ce qui détermine la gravité, c'est ce que l'agent peut faire quand cela arrive.

L'OWASP identifie trois causes racines, que nous reprenons dans la suite de l'article.

Comment réduire les fonctionnalités de l'agent ?

Retirez tout outil que le cas d'usage n'exige pas, puis réduisez les fonctions de chaque outil conservé. L'OWASP demande de minimiser les extensions que l'agent peut appeler et les fonctions que chacune implémente.

Méthode simple, en trois passes :

1. Inventaire. Listez chaque outil, chaque fonction exposée et chaque serveur MCP connecté. Les outils ajoutés « pour essayer » sont les plus fréquents.
2. Justification. Pour chacun, écrivez la tâche métier qui en dépend. Sans justification, on le retire.
3. Découpage. Remplacez un outil généraliste par plusieurs outils étroits : « lire une facture » et « créer un brouillon d'avoir » valent mieux que « accéder à l'ERP ».

Évitez surtout les extensions ouvertes : exécution de commandes shell, accès à une URL arbitraire, requête SQL libre. L'OWASP recommande des outils granulaires à la place. Un outil qui accepte n'importe quelle URL transforme chaque injection en possibilité d'exfiltration ; un outil qui accepte n'importe quelle requête SQL transforme l'agent en client de base de données pour l'attaquant. Pour les serveurs MCP, voyez notre page sécurité MCP.

Comment réduire les permissions en aval ?

Donnez à chaque outil les droits minimums sur le système qu'il atteint, et faites agir l'agent avec les droits de l'utilisateur qui l'a appelé. L'OWASP recommande d'exécuter les actions dans le contexte de l'utilisateur, avec des scopes à moindre privilège.

Cas typiques à corriger :

• Compte de service unique et puissant : toutes les requêtes passent par un compte administrateur. Un utilisateur sans droits particuliers obtient alors, via l'agent, ce qu'il ne pourrait pas obtenir seul.
• Jeton OAuth trop large : l'agent de tri d'e-mails détient un accès complet à la boîte alors qu'une lecture seule suffirait. Nous détaillons ce cas dans notre article sur les agents connectés à Gmail et Outlook.
• Base de données en lecture-écriture pour un agent d'analyse : un compte en lecture seule, limité aux vues nécessaires, supprime une classe entière d'incidents.
• Accès réseau libre : un agent qui n'a besoin que de deux API n'a pas à joindre tout Internet.

Comment encadrer l'autonomie de l'agent ?

Placez une approbation humaine devant toute action à fort impact, et faites vérifier les droits par le système en aval plutôt que par le modèle. L'OWASP insiste sur ce second point : l'autorisation s'applique dans les systèmes en aval, avec une médiation complète de chaque requête.

Pour définir ce qui demande une approbation, posez trois questions :

• L'action est-elle irréversible (envoi, paiement, suppression) ?
• Touche-t-elle un tiers (client, fournisseur, partenaire) ?
• Porte-t-elle sur des données sensibles (santé, finance, identifiants) ?

Si la réponse est oui à l'une d'elles, un humain valide. Soignez l'écran d'approbation : il doit montrer l'action réelle (destinataire, montant, contenu exact) et non une paraphrase générée par le modèle, sinon l'attaquant peut agir sur la paraphrase.

Évitez aussi la fatigue d'approbation. Si l'utilisateur doit confirmer trente actions par heure, il cliquera sans lire. Mieux vaut peu de validations, bien placées, que beaucoup de validations ignorées.

À quoi ressemble un agent bien borné ?

Prenons un agent de support qui répond aux clients. Version risquée : il lit tous les tickets, accède à la base clients en écriture, peut rembourser et envoyer des e-mails. Version bornée : il lit uniquement le ticket en cours et la fiche du client concerné, rédige un brouillon, et propose un remboursement que l'agent humain valide dans une interface qui affiche le montant exact.

Dans la seconde version, une injection réussie dans un ticket produit au pire un brouillon de mauvaise qualité, que la personne relira. La différence ne tient ni au modèle ni au prompt, mais à ce que l'architecture autorise.

Quelles mesures de réduction des dégâts ajouter ?

Ajoutez de la journalisation, de la surveillance et de la limitation de débit : elles n'empêchent pas la faille, mais elles réduisent ce qu'un détournement peut causer. C'est la distinction que fait l'OWASP entre prévention et limitation des dégâts.

• Journaliser chaque appel d'outil avec ses paramètres, l'utilisateur et le contenu qui l'a déclenché.
• Limiter le débit : nombre d'actions par minute et par heure, plafond de montant, plafond de destinataires.
• Alerter sur les écarts : première utilisation d'un outil, nouveau destinataire, volume inhabituel.
• Prévoir l'arrêt : un interrupteur et une révocation rapide des jetons.

Comment tester l'Excessive Agency ?

Testez en cherchant ce que l'agent peut faire au-delà de son rôle, par la voie directe (un utilisateur qui demande) et par la voie indirecte (un contenu piégé qui demande). L'objectif est de prouver ou de réfuter que les limites tiennent hors du modèle.

Un plan de test minimal :

Jouez chaque test plusieurs fois et vérifiez dans les journaux d'API, pas seulement dans la réponse du modèle. Notre page injection de prompt détaille la variante indirecte, la plus productive en test.

Documentez chaque constat avec la séquence exacte qui l'a produit : l'entrée, l'outil appelé, les paramètres et l'effet. Un constat qu'on ne peut pas rejouer est difficile à corriger et impossible à vérifier après correction. Une fois les limites en place, rejouez les mêmes scénarios pour confirmer que chacun échoue désormais au niveau du code.

Comment faire valider ses limites par un tiers ?

Faites attaquer l'agent par quelqu'un qui n'a pas défini ses limites : il testera les hypothèses que l'équipe tient pour acquises. C'est le cœur d'un test d'intrusion d'agent IA.

Le Red Team Agent Express (1 900 €, 5 jours) cartographie les outils, les permissions et les points d'autonomie d'un agent, puis tente de les dépasser avec des scénarios réalistes. Pour un périmètre plus large, la prestation sur mesure se chiffre sur devis, avec un rendez-vous découverte de 30 minutes gratuit pour cadrer le besoin.