Comment sécuriser un agent LLM qui utilise des outils et le function calling ?
Réponse courte
Un agent LLM transforme du texte en actions via des outils et des function calls, donc une prompt injection devient une action réelle — le risque d'excessive agency. Sécurisez-le en donnant à chaque outil le moindre privilège et la portée dont il a besoin, en validant et contraignant les arguments d'outils, en exigeant une confirmation humaine pour les actions sensibles ou irréversibles, en sandboxant l'exécution, en limitant le débit et en budgétant les appels, et en journalisant chaque invocation d'outil. Ne laissez jamais la sortie du modèle, influencée par des données non fiables, autoriser directement une action à fort impact.
Un agent est un LLM câblé à des outils — des fonctions qu'il peut appeler pour lire des e-mails, interroger des bases de données, frapper des API, exécuter du code ou déplacer de l'argent. C'est là que la prompt injection cesse d'être un problème de contenu et devient un problème d'action. Si un attaquant peut influencer l'entrée du modèle (directement, ou indirectement via un document ou une page web récupérés), il peut potentiellement lui faire faire des choses. OWASP appelle la version sur-habilitée de cela excessive agency.
La menace
L'excessive agency a trois variantes : trop d'outils (des fonctionnalités dont vous n'avez pas besoin), trop de permissions (un outil avec une portée plus large que la tâche ne l'exige) et trop d'autonomie (des actions irréversibles prises sans confirmation). Combinez l'une de ces variantes avec une injection et vous obtenez de l'exfiltration de données, des opérations destructrices ou du mouvement latéral.
Contrôles
- Moindre privilège par outil. Chaque fonction reçoit la portée la plus étroite, l'accès aux données le plus étroit et les identifiants à la durée de vie la plus courte possibles. Préférez des outils à granularité fine plutôt qu'un outil générique « exécute n'importe quoi ».
- Valider les arguments d'outils. Traitez les arguments générés par le modèle comme non fiables : vérifiez les types, allowlistez et bornez-les côté serveur avant l'exécution.
- Humain dans la boucle pour les actions sensibles ou irréversibles (paiements, suppressions, envois externes).
- Sandboxing pour toute exécution de code ; contrôles de sortie réseau pour limiter l'exfiltration et le SSRF.
- Budgets et limites de débit pour plafonner le denial-of-wallet et les boucles emballées.
- Journalisation d'audit complète de chaque appel d'outil avec ses arguments et le contexte déclencheur.
Ce que recherchent les recruteurs
Une chaîne claire — injection plus outils égale actions réelles — nommer l'excessive agency, et une réponse de moindre privilège, humain dans la boucle, défense en profondeur, plutôt que de compter sur le system prompt pour tenir l'agent en laisse.
Questions de suivi probables
- Qu'est-ce que l'« excessive agency » et comment en réduire la portée ?
- Comment la prompt injection indirecte devient-elle dangereuse spécifiquement dans un agent ?
- Quand un appel d'outil devrait-il exiger une approbation humaine dans la boucle ?