Ce que l'OWASP rate à propos des agents LLM

L’OWASP Top 10 pour les applications LLM était un bon début. Il a donné aux équipes un vocabulaire, une checklist et, surtout, la permission d’avoir la conversation sécurité à propos de fonctionnalités IA que le produit allait livrer de toute façon. Je l’ai utilisé dans des revues. Je l’ai recommandé à des clients. Je l’ai imprimé et collé sur un tableau blanc pendant une rétrospective de sprint particulièrement tendue.

Mais il a un angle mort, et il est structurel : la liste a été écrite pour des applications qui utilisent des LLM, pas pour des agents qui sont des LLM. La distinction compte plus qu’il n’y paraît.

L’agent n’est pas une fonctionnalité

Quand vous greffez une fenêtre de chat sur votre produit SaaS, le LLM est une fonctionnalité. Il prend une entrée, retourne une sortie, et l’application autour de lui décide quoi faire de cette sortie. La surface d’attaque est bornée par ce que l’application laisse le modèle faire, ce qui, dans un système bien conçu, n’est pas grand-chose.

Un agent, c’est différent. Un agent a des outils. Il peut lire des bases de données, appeler des API, envoyer des e-mails, exécuter du code. Le modèle ne produit pas des suggestions qu’un humain doit approuver ; il prend des décisions et agit en conséquence. La surface d’attaque n’est plus bornée par l’application. Elle est bornée par l’ensemble des capacités de l’agent, qui, dans la plupart des systèmes que j’ai audités, est bien trop large.

La colonne que j’ajouterais : Surprivilège de capacités

La liste comporte « Excessive Agency » (LLM07), mais le cadrage est trop doux. Il parle d’accorder une fonctionnalité, des permissions ou une autonomie excessives. Ce qu’il devrait dire, clairement, c’est : la plupart des agents ont accès à des outils dont ils n’ont pas besoin pour le tour en cours, et c’est la propriété la plus exploitable du système.

Le correctif n’est pas un prompt qui dit à l’agent de ne pas utiliser certains outils. Le correctif, c’est de ne pas lui donner les outils en premier lieu, pas globalement, mais tour par tour. Du cadrage dynamique des capacités. Le même principe que le moindre privilège pour les modèles de langage, appliqué à un système qui décide de ce qu’il veut faire en lisant de l’anglais. Donnez-en un de trop et le rayon d’explosion devient celui de l’agent qui a lu votre fichier env.

La colonne que je retirerais discrètement

Je rétrograderais « Insecure Output Handling » (LLM02) de son statut de catégorie autonome. Pas parce qu’elle n’a pas d’importance, elle en a, mais parce que c’est un symptôme, pas une cause racine. Dans une architecture d’agent, le traitement non sécurisé des sorties est ce qui arrive quand vous avez déjà échoué à la tâche plus fondamentale de séparer la couche de décision du modèle de la couche d’exécution du système.

Si vous réussissez l’architecture, si le modèle propose et le système dispose, alors le traitement des sorties devient un problème d’ingénierie classique. Si vous la ratez, aucune dose de sanitisation des sorties ne vous sauvera, parce que le modèle trouvera un moyen d’exprimer son intention dans un format que votre filtre n’anticipe pas, et c’est là que le XSS revient.

À quoi ressemblerait une liste révisée

Je ne vais pas tout réécrire. Mais si je conseillais le groupe de travail, je pousserais pour trois changements :

1. Scinder la liste en deux pistes : une pour le LLM-comme-fonctionnalité, une pour le LLM-comme-agent. Les modèles de menace sont suffisamment différents pour qu’une liste combinée impose des compromis maladroits.
2. Ajouter le Surprivilège de capacités dans le top 3 de la piste agent. C’est l’équivalent architectural de faire tourner votre serveur web en root.
3. Ajouter une catégorie « Confused Deputy » qui traite explicitement le cas où un agent disposant d’un accès légitime est manipulé pour utiliser cet accès au profit d’un adversaire. C’est le problème de 1988, et il revient pour votre pipeline RAG.

La liste de l’OWASP est une bonne fondation. Il lui faut juste rattraper ce que les équipes construisent réellement. En attendant, les checklists pragmatiques qui circulent côté builder, par exemple la liste de trente minutes avant de lancer une app vibe-codée, font une partie du travail que l’OWASP ne fait pas encore : traduire le standard en gestes opérationnels avant le déploiement.