Un assistant répond. Un agent agit. Il lit une demande, choisit un outil, appelle une API, modifie une donnée, envoie un message — puis recommence. C’est tout son intérêt. C’est aussi ce qui fait de chaque faille un incident réel.
Qu’est-ce que l’« agence excessive » ?
L’OWASP consacre une catégorie entière à ce risque (LLM06:2025 Excessive Agency). Il survient lorsqu’un système fondé sur un LLM peut accomplir des actions dommageables à la suite d’une sortie inattendue, ambiguë ou manipulée du modèle. Il a trois sources :
- Trop de fonctionnalités : l’agent dispose d’outils dont il n’a pas besoin (un outil de lecture qui permet aussi de supprimer).
- Trop de permissions : les outils s’exécutent avec des droits plus larges que ceux de l’utilisateur (le fameux compte de service administrateur).
- Trop d’autonomie : des actions à fort impact s’enchaînent sans confirmation humaine.
Le scénario type
Une équipe construit un agent de support client. Pour aller vite, elle le connecte au CRM et à la messagerie avec un compte technique qui a tous les droits. L’agent peut lire les tickets, consulter les contrats, appliquer des remises, envoyer des e-mails.
Un client malveillant glisse dans son ticket une instruction formulée comme une note interne. L’agent la suit : il applique une remise, modifie un contrat, envoie un récapitulatif à une adresse externe. Il n’y a pas eu d’intrusion au sens classique. L’agent a simplement fait ce que ses permissions lui permettaient.
Un agent sans garde-fous n’est pas un outil. C’est un collaborateur sans contrôle, avec vos accès.
Outils, connecteurs, MCP : la surface qui s’élargit
Les agents se branchent de plus en plus facilement à des outils, notamment via des protocoles de connexion standardisés comme le Model Context Protocol (MCP). C’est un progrès pour l’intégration — et un changement d’échelle pour la sécurité : chaque serveur d’outils ajouté est du code tiers, avec ses propres permissions, ses propres descriptions lues par le modèle, et donc sa propre surface d’injection.
Un connecteur installé en quelques minutes mérite la même revue qu’une intégration applicative : provenance, droits accordés, données exposées, mises à jour.
Un projet d’agent ou de RAG en cours ?
GenAI Security by Design : threat model, architecture, contrôles — avant la mise en production.
Les garde-fous à poser avant la production
- Inventaire des outils : chaque outil disponible pour l’agent est justifié par un besoin. Les autres sont retirés.
- Permissions minimales et déléguées : l’agent agit avec les droits de l’utilisateur qu’il sert, dans le périmètre de la tâche — jamais avec un compte global.
- Actions graduées : lecture libre, écriture limitée, actions irréversibles ou externes soumises à confirmation humaine.
- Bornes : plafonds de montant, de volume, de fréquence ; liste blanche de destinataires et de domaines.
- Journalisation complète : chaque décision, chaque appel d’outil et ses paramètres, chaque résultat — exploitable par votre SOC.
- Arrêt d’urgence : un moyen simple et testé de suspendre l’agent et de révoquer ses accès.
- Tests d’attaque : scénarios d’injection et d’abus d’outils rejoués avant chaque mise en production.
Une question de gouvernance autant que de technique
Qui a validé la liste des actions qu’un agent peut effectuer ? Qui est responsable s’il se trompe ? Qui surveille son comportement dans le temps ? Ces questions doivent avoir une réponse écrite avant la mise en production — c’est aussi ce que demandent l’ISO/IEC 42001 et, pour les systèmes concernés, l’AI Act en matière de supervision humaine.
À retenir
- L’agence excessive combine trop d’outils, trop de droits et trop d’autonomie.
- Un agent compromis agit avec ses permissions : réduisez-les à la tâche et à l’utilisateur.
- Chaque connecteur ou serveur d’outils est du code tiers à qualifier.
- Confirmation humaine, bornes, journaux et arrêt d’urgence avant toute mise en production.
