Unbounded Consumption (LLM10) : DoS et coûts des agents IA

Qu'est-ce que l'Unbounded Consumption (LLM10:2025) ?

C'est la catégorie du Top 10 OWASP pour les applications LLM 2025 qui regroupe les abus de consommation de ressources. Elle remplace et élargit l'ancien risque de déni de service du modèle. L'OWASP y liste sept types de vulnérabilités :

1. Variable-Length Input Flood : saturer le système avec des entrées de tailles variées.
2. Denial of Wallet (DoW) : faire grimper les coûts par un volume élevé d'opérations sur un service facturé à l'usage.
3. Continuous Input Overflow : envoyer sans cesse des entrées qui dépassent la fenêtre de contexte.
4. Resource-Intensive Queries : soumettre des requêtes qui épuisent les ressources.
5. Model Extraction via API : reproduire un modèle partiel ou « fantôme » à partir de requêtes ciblées.
6. Functional Model Replication : utiliser les sorties du modèle comme données synthétiques pour en entraîner un équivalent.
7. Side-Channel Attacks : exploiter les filtres d'entrée pour obtenir des informations sur le modèle.

Pour une PME qui consomme un modèle via une API, les trois premiers et le quatrième sont les plus concrets : disponibilité du service et facture. L'extraction de modèle concerne surtout ceux qui exposent un modèle propriétaire.

Pourquoi un agent IA multiplie-t-il le risque ?

Parce qu'une seule requête peut déclencher une chaîne de dizaines d'appels, dont l'attaquant n'a pas à payer le coût. Un chatbot répond une fois. Un agent planifie, appelle des outils, relit les résultats et recommence.

Les mécanismes d'amplification :

• Boucles. L'agent retente indéfiniment une action qui échoue, ou deux agents se renvoient la tâche.
• Historique renvoyé à chaque étape. Dans une API sans état, chaque appel renvoie tout le contexte : plus l'exécution s'allonge, plus chaque étape coûte cher.
• Résultats d'outils volumineux. Un outil qui renvoie une page web ou un fichier entier gonfle le contexte.
• Fan-out. Un agent qui lance des sous-agents ou des appels parallèles multiplie la dépense.
• Outils payants en aval. Recherche, génération d'image, envoi de SMS ou d'e-mails, appels d'API tierces : le coût sort du budget du modèle.
• Tâches déclenchées par des tiers. Un formulaire public, un e-mail entrant ou un webhook lance l'agent sans contrôle de volume.

Ce dernier cas est le plus dangereux : l'attaquant n'a pas besoin de compte, il lui suffit de déclencher l'agent. Notre étude de cas sur un webhook n8n montre comment un point d'entrée exposé permet de lancer des workflows par n'importe qui.

Comment un attaquant provoque-t-il un déni de service ou une explosion de coûts ?

Il envoie des entrées conçues pour coûter cher à traiter, ou il fait boucler l'agent par un document piégé. Les scénarios que nous testons :

Les deux premiers sont du déni de service classique. Les suivants exploitent la nature agentique de la charge, et sont souvent combinés avec une injection de prompt indirecte : le document piégé ordonne de boucler. Voir l'injection de prompt.

Quelles mesures de prévention l'OWASP recommande-t-il ?

Une défense en profondeur sur les entrées, le débit, le temps et la surveillance. La page LLM10:2025 liste notamment :

• Validation des entrées : limites de taille raisonnables.
• Limitation du débit et quotas par utilisateur.
• Gestion de l'allocation des ressources pour qu'un seul utilisateur ne consomme pas tout.
• Délais d'expiration et ralentissement pour plafonner le temps des opérations coûteuses.
• Bac à sable : restreindre l'accès du LLM au réseau, aux services internes et aux API.
• Journalisation, surveillance et détection d'anomalies de l'usage des ressources.
• Dégradation gracieuse : conserver un service partiel sous forte charge.
• Limitation des files d'actions et mise à l'échelle robuste.
• Limitation de l'exposition des logits et logprobs pour freiner l'extraction.

Ces points sont génériques. Pour un agent, il faut les traduire en plafonds propres à chaque exécution.

Comment plafonner un agent concrètement ?

En posant des limites dures, appliquées par le code autour du modèle, à cinq niveaux. Le modèle ne doit jamais être celui qui décide d'arrêter.

1. Par exécution : nombre maximal d'étapes, d'appels d'outils, de jetons consommés et durée totale. Au-delà, arrêt et message d'erreur.
2. Par outil : quota d'appels et délai d'expiration pour chaque outil, avec un plafond plus bas pour les outils payants ou lents.
3. Par utilisateur et par client : budget quotidien et mensuel, débit maximal, nombre d'exécutions simultanées.
4. Par point d'entrée : authentification, limitation du débit et file d'attente bornée sur les webhooks, formulaires et e-mails entrants.
5. Globalement : plafond de dépense chez le fournisseur du modèle, alerte à plusieurs seuils et coupe-circuit qui désactive les fonctions coûteuses.

Quelques règles de conception en plus :

• Détecter les boucles : même outil appelé avec les mêmes arguments plusieurs fois de suite, ou mêmes états qui reviennent.
• Tronquer ou résumer les sorties d'outils avant de les remettre dans le contexte, avec une taille maximale.
• Limiter la profondeur des sous-agents et le parallélisme.
• Choisir un modèle adapté à chaque étape : un petit modèle pour les tâches simples réduit la dépense.
• Séparer les clés par application ou par client, pour isoler une dérive et pouvoir la couper sans tout arrêter.

Comment tester la résistance d'un agent à l'Unbounded Consumption ?

Avec des charges contrôlées, sur un environnement de test ou avec un budget plafonné à l'avance, jamais en production sans accord écrit. L'objectif est de trouver les limites manquantes sans faire tomber le service.

1. Entrées extrêmes. Envoyer un message de la taille maximale acceptée, puis au-delà, et observer le rejet.
2. Boucle. Demander une tâche impossible ou circulaire et vérifier que l'agent s'arrête au plafond d'étapes.
3. Sortie d'outil énorme. Faire renvoyer un très gros fichier ou une très longue page et observer la troncature.
4. Fan-out. Demander une tâche qui nécessite de nombreux sous-appels et mesurer le plafond effectif.
5. Quotas. Répéter des requêtes depuis un compte jusqu'à atteindre la limite, puis vérifier qu'elle protège les autres clients.
6. Point d'entrée public. Déclencher un webhook ou un formulaire à répétition, avec des volumes faibles, et vérifier l'existence d'un quota.
7. Alerte. Contrôler qu'une dépense anormale déclenche bien une alerte, et dans quel délai.

Pour chaque test, relevez le nombre de jetons, d'appels et le coût estimé : c'est le chiffre qui parle à une direction. Les métriques de consommation recommandées dans notre article sur la journalisation des agents permettent de les retrouver.

Quelle place pour l'humain ?

Au-delà d'un seuil de dépense ou de volume, une exécution doit demander une validation. Un agent qui s'apprête à envoyer des milliers d'e-mails ou à lancer une longue tâche est typiquement une action de niveau élevé. Voir quelles actions valider.

Comment CleanIssue évalue ce risque ?

Nous cartographions les points d'entrée qui déclenchent votre agent, ses outils payants et ses plafonds, puis nous testons chaque limite avec des charges bornées. Le Red Team Agent Express à 1 900 € couvre ce volet pour un agent en 5 jours, avec les plafonds manquants chiffrés en jetons et en coût. Notre approche est décrite sur la page méthode, et le cadre sur le pilier red team d'agent IA. Le premier échange est un rendez-vous découverte de 30 minutes, gratuit.