Unbounded consumption : définition - LLM10 OWASP expliqué

Unbounded Consumption est l'item LLM10 du OWASP LLM Top 10 2025. Le terme, introduit en 2025 (remplaçant l'ancien "Model Denial of Service" de 2023), recouvre deux classes de risques souvent confondues : (1) la consommation abusive de ressources (DoS économique, DoS de service, saturation), et (2) le vol du modèle par extraction via requêtes massives. Les deux partagent un vecteur commun : un attaquant qui envoie énormément de requêtes pour épuiser ou dupliquer. Ce guide définit unbounded consumption, détaille les deux dimensions, présente les attaques concrètes 2023-2026 (Tay bombing, model extraction academic, DoS économique sur API), et donne les défenses opérationnelles (rate limiting, quotas, watermarking, monitoring).

1. Définition précise

1.1 Formulation OWASP LLM10:2025

L'OWASP 2025 définit l'unbounded consumption comme :

"Unbounded Consumption refers to the process where a LLM application allows users to conduct excessive and uncontrolled inferences, leading to risks such as denial of service (DoS), economic losses, model theft, and service degradation."

Deux risques en un : consommation (DoS, coûts) et extraction (model theft).

1.2 Évolution depuis 2023

• OWASP LLM 2023 : "Model Denial of Service" (LLM04). Focus DoS uniquement.
• OWASP LLM 2025 : "Unbounded Consumption" (LLM10). Élargi pour inclure model theft et economic attacks.

Cet élargissement reflète l'évolution du paysage :

• 2023 : inquiétude sur saturation services.
• 2024-2025 : émergence d'attaques économiques (consommation massive d'API payantes), démonstrations d'extraction de modèles propriétaires.

1.3 Les deux dimensions

2. La dimension DoS - attaques sur les ressources

2.1 Le coût opérationnel d'un LLM

L'inférence LLM est coûteuse : GPU/TPU, mémoire, énergie. Un token généré coûte réellement quelques fractions de cents. À l'échelle, ça compte.

Ordre de grandeur en 2026 pour modèles commerciaux :

• GPT-4o : 2,50 USD / 1M tokens input, 10 USD / 1M tokens output.
• Claude Sonnet 4 : 3 USD / 1M tokens input, 15 USD / 1M tokens output.
• Gemini 2 Flash : 0,10-0,30 USD / 1M tokens.

Pour un agent qui fait 10 appels LLM par requête utilisateur avec contexte riche :

• Par requête : 5 000 tokens input + 500 tokens output = quelques cents.
• Pour 10 000 requêtes/jour : 40 à 150 USD.
• Une attaque qui force 10 millions de requêtes : 40 000 à 150 000 USD de facture.

2.2 DoS économique

L'attaquant n'a pas besoin de faire tomber le service. Il suffit de faire exploser la facture de l'opérateur.

Vecteurs :

• Création de comptes jetables : inscription massive avec emails temporaires.
• Abuse du free tier : 100 comptes gratuits = 100x la limite gratuite par jour.
• Credential stuffing : usage de comptes légitimes compromis.
• Bot farm : scale énorme depuis nombreux devices.

2.3 DoS de service

L'attaquant sature le service pour le rendre indisponible ou très lent pour les autres users.

Vecteurs :

• Volume : milliers de requêtes simultanées.
• Complexité : requêtes gourmandes (long context, tool calls multiples, reasoning agents).
• Queue flooding : saturer la queue d'inférence.

2.4 Attaques par inputs construits

Certains types d'inputs forcent le modèle à consommer beaucoup plus de ressources :

Long context attacks :

• Input de 100k tokens remplis de texte redondant.
• Force le modèle à traiter massivement.
• Avec context windows modernes (Claude 200k, Gemini 1M), l'attaque devient viable.

Recursive tool calls en agents :

• L'agent se voit demander une tâche qui déclenche un tool.
• Le tool retourne un contenu qui demande un autre tool call.
• Boucle qui consomme tokens.

Infinite loops :

• Prompt injection qui force l'agent à entrer en boucle.
• L'agent reflète les instructions et se répète.
• Classique avec AutoGPT early versions.

Reasoning amplification :

• Inputs qui déclenchent du chain-of-thought massif.
• Le modèle consomme des milliers de tokens pour "raisonner".
• Utilisable avec modèles reasoning (GPT-o1, Claude 3.5 Sonnet, DeepSeek R1).

2.5 Cas réels DoS

OpenAI incidents 2023-2024 : plusieurs incidents de saturation, partiellement dus à des abusers coordonnés.

Crypto mining via LLM API : attaquants qui utilisent des APIs LLM volées pour générer du contenu monétisable (SEO spam massif), consommant des tokens volumineux.

Microsoft Tay (2016) : l'exemple historique de "bombing" - Tay a été submergé par des inputs coordonnés pour le corrompre.

ChatGPT scrapers 2023-2024 : outils qui scrapent ChatGPT en passant par le front-end (vs l'API) pour bypasser les limits, consommant énormément de capacité service.

3. Model theft - vol de modèle via queries

3.1 Définition

Model extraction (ou model theft, model stealing) désigne l'attaque où un adversaire recrée un modèle propriétaire en l'interrogeant massivement et en utilisant les réponses pour entraîner son propre modèle.

3.2 Pourquoi c'est possible

Les LLMs sont fonctionnellement imitables : donner un grand volume de couples (input, output) à un modèle élève permet d'apprendre à approximater les capacités du modèle maître.

C'est la base de la distillation - technique légitime utilisée par les labs pour créer des modèles plus petits depuis des gros modèles. Mais elle peut être abusée par un attaquant pour copier un modèle fermé.

3.3 Types d'attaques model extraction

Functional extraction :

• Copier les capacités du modèle (répondre à des questions, écrire du code) sans copier les poids.
• Entraîner un modèle élève sur les outputs du modèle maître.
• Exemples : Stanford Alpaca a été créé en distillant GPT-3.5 (avec permission discutable).

Parameter extraction (plus rare) :

• Reconstituer les poids du modèle via analyse mathématique des réponses.
• Beaucoup plus difficile, possible en théorie avec accès white-box partiel.
• Recherches académiques : Carlini et al. 2024 ont démontré une forme d'extraction partielle sur ChatGPT.

Membership inference :

• Déterminer si un échantillon particulier était dans le dataset de training.
• Risque privacy (détecter si une donnée personnelle a été utilisée).
• Moins critique que full extraction mais réglementairement sensible.

Model inversion :

• Reconstituer des données d'entraînement à partir des réponses.
• Particulièrement dangereux pour données sensibles (santé, finance).

3.4 Cas concrets model extraction

Stanford Alpaca (2023) : modèle fine-tuné sur 52 000 instructions générées par GPT-3.5 via API. Résultat : modèle qui imite GPT-3.5 à une fraction du coût. OpenAI a réagi en clarifiant ses ToS (interdisant d'utiliser leurs outputs pour entraîner des modèles concurrents).

Vicuna, WizardLM et autres : série de modèles open source 2023 entraînés en distillant ChatGPT. Question juridique ouverte.

DeepSeek R1 (2025) : le lancement a suscité des allégations que le modèle aurait été entraîné en partie via extraction d'OpenAI (non prouvé publiquement, débats en cours).

Carlini et al. 2024 : chercheurs de Google DeepMind ont démontré comment extraire partiellement les paramètres de la dernière couche de ChatGPT via requêtes API. Preuve académique que le modèle theft est possible à bas niveau.

Tramèr et al. 2016-2024 : série de papers sur model extraction depuis 2016, démontrant feasibility sur modèles de classification, puis LLMs.

3.5 Impact commercial du model theft

Si un concurrent parvient à extraire ton modèle :

• Perte de differentiation : ton avantage concurrentiel s'évapore.
• Pricing pressure : le concurrent peut offrir à moins cher (il n'a pas payé l'entraînement).
• Investissement gaspillé : millions de dollars de training récupérés pour le prix des requêtes.
• Fuite de connaissance : training data, fine-tuning insights, capabilities émergent.

Pour les labs frontier (OpenAI, Anthropic, Google, xAI), le model theft est un risque stratégique majeur.

4. Pourquoi c'est critique en 2026

4.1 La démocratisation

• APIs LLM partout (OpenAI, Anthropic, Mistral, DeepSeek, Groq, ensemble autres).
• Intégration massive dans les produits SaaS.
• Usage growing chez les développeurs et les end-users.

Conséquence : surface d'attaque énorme.

4.2 Économie des LLMs

Avec des milliards de dollars dépensés en training et inference annuellement, le coût est un enjeu business majeur. Une attaque économique sur un LLM peut :

• Saturer la capacité allouée à un client.
• Augmenter les coûts au point de menacer la viabilité.
• Déclencher des alertes finance qui retirent le service.

4.3 Commoditisation vs differentiation

Les modèles open source (Llama, Mistral, DeepSeek) rattrapent les frontier commerciaux. Pour OpenAI/Anthropic/Google, la différence s'affine. Un model theft qui capture quelques % d'avantage devient commercialement dangereux.

4.4 Régulation émergente

EU AI Act et équivalents commencent à exiger :

• Audit de l'usage des modèles.
• Traçabilité des appels API.
• Quotas pour usages "significant risk".

Plus les acteurs sont régulés, plus l'unbounded consumption devient un sujet compliance.

5. Défenses contre le DoS

5.1 Rate limiting multi-niveaux

Par IP : limite brute, facile à contourner via IP rotatives.

Par API key / compte : limite par utilisateur. Plus robuste mais nécessite auth.

Par tenant : limite par organisation (B2B).

Par endpoint : endpoints coûteux plus limités.

Configuration typique 2026 :

rate_limits:
  - scope: per_api_key
    requests_per_minute: 60
    requests_per_day: 10000
  - scope: per_ip
    requests_per_minute: 20
    requests_per_day: 1000
  - scope: per_endpoint
    endpoint: /v1/agents/autonomous
    requests_per_minute: 5

5.2 Token quotas

Le rate limiting par requête n'empêche pas une requête coûteuse. Token quotas ajoutent la dimension consommation :

• Limite de tokens input par requête (ex. 8000).
• Limite de tokens output par requête (ex. 2000).
• Quota quotidien/mensuel par utilisateur.
• Budget max par tenant.

Alertes quand X % du budget consumé.

5.3 Input validation

Rejeter les inputs anormaux :

• Longueur max (ex. 50 000 caractères).
• Patterns suspects (répétitions massives, caractères de padding).
• Detection chain-of-thought malicieux : inputs qui forcent reasoning excessif.

5.4 Request timeout

• Timeout par requête (ex. 60 secondes).
• Cancellation gracieuse.
• Circuit breakers pour éviter cascade failures.

5.5 Bot detection

Combat des bots automatisés :

• CAPTCHA (classique, mais friction UX).
• Device fingerprinting.
• Behavioral analysis (patterns humains vs automatisés).
• Plateformes dédiées : DataDome, Cloudflare Bot Management, Imperva Advanced Bot Protection, Akamai Bot Manager.

5.6 Queue management

Quand la charge augmente :

• Priority queues : users premium traités en premier.
• Backpressure : ralentir les consommateurs.
• Graceful degradation : version plus légère du service quand saturé.

5.7 Financial monitoring

• Budget alerting à plusieurs seuils (50%, 80%, 95%).
• Daily spend caps avec arrêt automatique si dépassé.
• Analytics par user/tenant pour identifier abus.

6. Défenses contre model theft

6.1 Limitations d'API strictes

• Limites par compte très restrictives pour free tier.
• Identification forte (payment method, phone, etc.) pour limits élevés.
• Monitoring des patterns : détecter les extractions de volumes atypiques.

6.2 Output filtering

• Limiter la longueur des réponses.
• Refuser certains types de prompts qui visent la distillation (ex. "give me 10,000 examples of X").
• Détecter les patterns de scraping automatisé.

6.3 Watermarking

Technique émergente : insérer un watermark invisible dans les outputs générés par le LLM.

• Permet de détecter si un autre modèle a été entraîné sur des outputs watermarkés.
• Recherches actives : Google (Watermarking for LLMs 2023), Aaronson et al.

Limites : techniques de bypass existent (resampling, paraphrasing).

6.4 Differential privacy

Injecter du bruit calibré dans les réponses pour limiter ce qu'on peut extraire :

• Reduire les fuites via membership inference.
• Compromis : qualité des réponses légèrement dégradée.
• Adopté partiellement par Apple Intelligence, certains modèles de Google.

6.5 Monitoring patterns d'extraction

Signatures typiques d'extraction :

• Volume massif de requêtes depuis un compte.
• Patterns systématiques : "Explain X in detail", "Write 10 examples of Y", répétés.
• Topic distribution cohérente avec un training dataset.
• Time patterns : automated, non-human.

Alertes + rate limiting adaptatif + investigation manuelle.

6.6 Termes de service et légalité

• ToS explicites : interdiction d'utiliser les outputs pour entraîner des modèles concurrents.
• Action légale possible si extraction prouvée (historique OpenAI vs plusieurs acteurs).
• Procédures formelles : cease and desist, account termination, litigation.

Limitations : difficile à prouver, juridictions variées, IP laws en évolution pour l'AI.

6.7 Obfuscation et model hardening

Recherches académiques :

• Randomisation des outputs pour rendre extraction plus coûteuse.
• Model hardening contre specific extraction techniques.
• Detection layers qui flaggent les queries suspectes.

État de l'art en évolution.

7. Protection par architecture

7.1 Chatbot public (free tier)

Risques principaux : DoS économique via comptes jetables, scraping.

Défenses :

• Rate limit strict par IP et par compte.
• CAPTCHA pour high-volume.
• Quota daily par compte gratuit.
• Premium tier avec auth + monitoring.

7.2 API pour développeurs (paid)

Risques : DoS économique, model extraction via volumes élevés.

Défenses :

• Rate limits par API key (burst + sustained).
• Token quotas hard.
• Usage-based billing avec alerts.
• ToS explicites.
• Pattern detection pour extraction.

7.3 Agents autonomes (voir aussi excessive agency)

Risques : boucles infinies, consommation explosive, tool abuse.

Défenses :

• Max iterations par agent.
• Token budget par session.
• Timeout par tâche.
• Circuit breakers si coût dépasse seuil.
• Monitoring coût par user.

7.4 RAG

Risques : retrieval massif, context inflation, DoS via queries complexes.

Défenses :

• Limit documents retrieved par query.
• Max context size.
• Query normalization et caching.
• Detection patterns d'extraction de données indexées.

7.5 Enterprise internal

Risques moindres (employees trusted) mais real :

• Abuse accidentel (script mal conçu).
• Malicious insider.
• Compromis credentials (infostealer).

Défenses :

• Identity-based quotas.
• Anomaly detection sur usage patterns.
• Per-team budget caps.

8. Outils et ressources

8.1 Rate limiting et API management

• Kong, Apigee, AWS API Gateway, Azure API Management : gateways traditionnels, adaptés LLM.
• Portkey, Helicone, LangDB : LLM-specific API gateways avec features token tracking.
• OpenAI usage dashboard, Anthropic Workbench : natifs, pour monitoring de base.

8.2 Token tracking et cost management

• LangSmith (LangChain) : observabilité LLM complète.
• Langfuse : open source, self-hostable.
• Weights and Biases : tracking for ML/LLM.
• Helicone, Portkey, Traceloop : alternatives commerciales.

8.3 Bot detection

• DataDome, Cloudflare, Imperva, Akamai : anti-bot mainstream, adaptés LLM API.
• Arkose Labs : spécialisé en friction challenges.

8.4 Watermarking research

• "A Watermark for Large Language Models" (Kirchenbauer et al. 2023).
• "Provable Robust Watermarking" (Liu et al. 2024).
• Google SynthID : watermarking pour texte et images.
• OpenAI C2PA implementation pour DALL-E.

8.5 Defenses académiques

• Carlini et al. papers sur model extraction.
• Shokri et al. papers sur membership inference.
• MITRE ATLAS : mapping des attaques, incluant extraction.

9. Misconceptions

9.1 "Ma clé API est sécurisée donc pas de risque"

Faux. Même avec une clé unique, un attaquant qui la vole peut exploser ta facture en quelques minutes. Et un utilisateur légitime malveillant (insider, compromis) aussi.

9.2 "OpenAI/Anthropic me protègent"

Partiellement. Ils ont des limits globales, mais :

• Dans les limites autorisées, ils te factureront.
• Les attaques qui restent sous les limites passent.
• Responsabilité du consommer est sur toi.

9.3 "Personne ne va essayer de voler mon modèle fine-tuné"

Dépend du modèle. Un fine-tuning custom trained sur data propriétaires peut être très ciblé. Même petit acteur peut être victime.

9.4 "Rate limiting seul suffit"

Insuffisant. Sans quotas de tokens, un attaquant peut envoyer peu de requêtes mais chacune très coûteuse (long context, chain-of-thought massif).

9.5 "Watermarking résout le model theft"

Non. Watermarking est une couche de défense, contournable et détectable. Utile mais pas suffisant seul.

9.6 "C'est juste un bug, pas une sécurité"

Faux. Une consommation sans limite est une vulnérabilité de sécurité. Impacts : financier, disponibilité, réputation.

10. Checklist unbounded consumption mitigation

Pour toute application LLM en production :

Rate limiting

• Rate limit par IP
• Rate limit par API key / user
• Rate limit par endpoint sensible
• Adapté selon tier (free vs premium)

Quotas tokens

• Tokens input max par requête
• Tokens output max par requête
• Token quota daily / monthly par user
• Budget cap par tenant

Input validation

• Longueur max d'input
• Pattern detection (repetition, padding)
• Rejet inputs anormaux

Monitoring financier

• Budget alerts (50%, 80%, 95%)
• Spending cap automatique
• Per-user cost tracking
• Daily report au FinOps / Finance

Bot detection

• CAPTCHA sur high-volume
• Device fingerprinting
• Behavioral analysis
• Plateforme anti-bot si besoin

Model theft protection

• Rate limits très restrictifs pour free tier
• Auth forte pour limits élevés
• Pattern detection (extraction queries)
• ToS explicites
• Output length limits
• Watermarking si feasible

Agents et RAG

• Max iterations par agent
• Timeout par session
• Circuit breakers
• Max documents retrieved

Incident response

• Kill switch pour couper un compte abusif
• Processus d'investigation rapide
• Coordination FinOps / Security

Compliance

• Audit logs des usages
• Traçabilité par requête
• Rapports conformité (EU AI Act)

11. Évolution 2026-2028

11.1 Reasoning models et cost amplification

Les reasoning models (GPT-o1, Claude 3.7, DeepSeek R1) consomment 10-100x plus de tokens qu'un modèle classique pour la même question. Le risque DoS économique est démultiplié.

Déploiement en prod de reasoning models nécessite quotas plus stricts.

11.2 Multi-agents et cascading costs

Multi-agent systems peuvent multiplier les coûts par le nombre d'agents × la complexité des interactions. Un système mal calibré coûte facture catastrophique sans attaque externe.

11.3 Legal clarification model theft

Décisions judiciaires attendues 2026-2028 sur :

• Est-ce que l'output LLM est de la propriété de l'opérateur ?
• Est-ce que l'entraînement d'un modèle sur des outputs constitue de la violation IP ?
• Jurisprudence émergente aux US, EU, Chine.

11.4 Régulation compute

Discussions internationales sur compliance compute monitoring pour limiter l'utilisation de très grands modèles à des acteurs autorisés.

11.5 Watermarking standards

Standards (ex. C2PA content provenance) en cours de définition pour tracer l'origine des outputs AI.

12. Verdict et posture Zeroday

L'unbounded consumption est sous-estimé mais devient critique en 2026. La plupart des équipes cyber se concentrent sur prompt injection et data poisoning, négligeant les dimensions économiques et IP (model theft). Pourtant :

• Une facture 6 chiffres suite à attaque = incident majeur.
• Un service saturé = perte de clients.
• Un modèle extrait = avantage concurrentiel évaporé.

Pour un développeur : implémenter les 5 contrôles minimaux (rate limit, quotas, budget cap, alertes, logging) est non-négociable pour toute app LLM en prod.

Pour un FinOps / Finance : intégrer la surveillance LLM dans les outils FinOps habituels. Pas un sujet annexe - les coûts LLM peuvent exploser rapidement.

Pour un RSSI : inclure unbounded consumption dans le threat modeling des apps LLM. Red team aussi bien sur le DoS que sur le model theft.

Pour un architecte : budgeter explicitement les coûts LLM par feature et par user tier. Faire de la gestion de coûts une exigence non-fonctionnelle au même titre que les performances.

Pour approfondir : sécurité des LLM - définition pour le contexte général, OWASP Top 10 LLM expliqué pour les autres items, excessive agency définition pour le sujet voisin des agents, data poisoning définition pour la composante données, pourquoi les API sont attaquées pour l'articulation avec la sécurité API classique qui sous-tend les LLMs, service accounts : risques et bonnes pratiques pour les identités qui portent la consommation.