Denial of wallet

Wat is denial of wallet?

Denial of wallet is een aanval, of een ongeluk, die je geld kost in plaats van je beschikbaarheid. Iemand jaagt het verbruik op van iets waar je per gebruik voor betaalt, je factuur loopt op, en de dienst gaat nooit plat. Alle dashboards blijven groen terwijl de teller loopt.

De verschuiving zit in hoe je rekenkracht koopt. Wie een server huurde, moest die uitputten om je pijn te doen: genoeg verkeer om de CPU vol te zetten en je site lag eruit. Wie per token, per function invocation of per API-call betaalt, heeft niets om uit te putten. Het platform schaalt netjes mee en elk extra verzoek is een extra lijn op de factuur. Dat vlotte schalen is hier geen neveneffect, het is precies het mechanisme.

De term komt uit de serverless-hoek. Een team van de University of Galway omschreef hem in een paper uit 2021 als het richten van verkeer op endpoints die per gebruik afgerekend worden, om de factuur van de eigenaar op te drijven, en toonde dat verdedigingen tegen denial of service dit niet noodzakelijk opvangen. Generatieve AI maakte het idee veel aantrekkelijker, want een verzoek aan een groot model kost een veelvoud van een function invocation.

OWASP heeft het op de lijst staan. In de OWASP Top 10 for LLM Applications noemt het item Unbounded Consumption denial of wallet expliciet als aanvalsvorm: aanvallers die het per-gebruik-model van AI-diensten uitbuiten tot de factuur niet meer houdbaar is. Dat item was LLM10 in de editie van 2025 en schoof op naar LLM06 in de editie van 2026, gepubliceerd in augustus 2026, dus vermeld altijd het jaartal bij het nummer.

De drie manieren waarop het gebeurt

Drie oorzaken leveren dezelfde factuur op, en ze vragen een ander antwoord.

1. Een bewuste aanval op een publiek endpoint. Je demo-chatbot, je gratis API, je publieke zoekvenster. De aanvaller heeft geen kwetsbaarheid nodig en moet nergens binnenraken. Gewone, geldige verzoeken sturen is de volledige aanval, en daarom ziet niets in je logs er verkeerd uit.

2. Een gestolen sleutel die het werk van iemand anders draait. Een sleutel in een publieke repository, een gelekt configuratiebestand, een besmette laptop. De aanvaller gebruikt jouw betaalde modeltoegang en verkoopt ze vaak door. Dat patroon heeft een eigen naam: LLMjacking.

3. Je eigen bug, zonder plafond erop. Een retry-loop zonder bovengrens, een agent die beslist dat hij nog twintig rondes nodig heeft, een geplande job die om de tien minuten op een lege wachtrij afvuurt.

Die derde is veruit de meest voorkomende, en net daar plant niemand aandacht voor in. Security-mensen denken na over aanvallers, bijna niemand over zijn eigen retry-logica. Heb je maar plaats voor een controle, zet ze dan waar ze alle drie afdekt, en dat is bij de uitgave zelf, niet bij de aanvaller.

De grens tussen de drie is dun. In 2024 kreeg een ontwikkelaar op twee dagen een rekening van zowat 1.300 Amerikaanse dollar op een lege S3-bucket, door bijna 100 miljoen schrijfverzoeken van een open source tool waarvan de standaardconfiguratie toevallig die bucketnaam gebruikte. De verzoeken werden geweigerd als niet-geautoriseerd en toch aangerekend. AWS paste die regel in mei 2024 aan, maar het punt blijft: een publiek endpoint met een prijs per verzoek staat open voor verkeer dat niemand bewust op jou richtte.

Een publiek demo-endpoint over een weekend

Vier eigenschappen samen maken een endpoint de moeite waard om te misbruiken: het staat publiek en zonder authenticatie, de antwoordlengte is onbegrensd, er hangt een duur model achter, en de kost per verzoek ligt hoog genoeg dat een bescheiden tempo pijn doet. Een demo-assistent op je website heeft die meestal alle vier, want een login vragen helpt de demo om zeep.

Zeg dat elk verzoek ongeveer 1.500 input-tokens meestuurt en dat het antwoord begrensd is op 2.000 output-tokens. Aan de lijstprijs van Anthropic voor Claude Sonnet 5 op 4 september 2026, 2 Amerikaanse dollar per miljoen input-tokens en 10 per miljoen output, is dat 0,003 dollar aan input en 0,02 aan output. Zeg 2,3 cent. Tarieven bewegen, dus maak de som opnieuw met wat jouw leverancier vandaag vraagt.

Zet daar nu een tempo op dat elk scriptje moeiteloos haalt: twee verzoeken per seconde. Iemand start het vrijdagavond en jij merkt het maandagochtend, 62 uur later. Dat zijn 446.400 verzoeken, en 446.400 keer 0,023 is ongeveer 10.270 dollar. Er ging niets plat en de reactietijden waren in orde.

Twee ingrepen verzetten dat flink. Begrens het antwoord op 300 output-tokens en het weekend kost nog zowat 2.680 dollar. Stuur anoniem verkeer daarbovenop naar een goedkoop model, bijvoorbeeld Claude Haiku 4.5 aan 1 en 5 dollar per miljoen, en het kost ongeveer 1.340 dollar, ruw een achtste van waar je begon. Een harde uitgavenlimiet doet beter dan allebei: de Start-tier van Anthropic legt de maandelijkse spend cap op 500 dollar en stopt de verzoeken daar, zo een drie uur nadat dit weekend begon.

Denial of wallet versus denial of service

Op het netwerk zien de twee er identiek uit. Het verschil zit in wat de aanvaller probeert uit te putten.

Een denial of service put een eindige bron uit: connecties, CPU, geheugen, een rate limit, een aantal licenties. Het succes is zichtbaar, want de bron raakt op en gebruikers krijgen foutmeldingen. Je monitoring is gebouwd om net dat op te merken, en je autoscaling bestaat om het te voorkomen.

Een denial of wallet put je budget uit, en dat is op geen enkele manier eindig die je infrastructuur kent. De autoscaling die je van de eerste aanval redt, is wat de tweede bij je aflevert, en het ideale verkeerspatroon voor de aanvaller is er een dat onder al je drempels blijft. Anti-DDoS-bescherming telt verzoeken en vangt een vloedgolf op, maar heeft geen idee wat een verzoek jou kost.

De controles, in de volgorde waarin ze helpen

Eerst authenticatie. Alles hieronder veronderstelt dat je bellers uit elkaar kan houden. Staat je dure endpoint publiek, zet er dan een login, een uitgegeven sleutel of een mailstap voor.

Een hard plafond dat stopt, niet een dat waarschuwt. Dit bepaalt je worstcase, en leveranciers verschillen hier sterk. Anthropic legt per tier een maandelijkse spend cap op en laat je zelf een lagere zetten, per organisatie of per workspace, waarna verzoeken falen. Google Cloud heeft spend cap budgets die nieuw verbruik van een dienst pauzeren, voorlopig voor een korte lijst waaronder de model-API's en Cloud Run. Azure is er duidelijk over dat zijn budgetten dat niet doen: er vertrekken meldingen, en in de eigen bewoording van Microsoft worden resources niet geraakt en wordt je verbruik niet gestopt.

Quota per sleutel en per gebruiker. Een globale limiet zegt je niets over wie het geld uitgaf. Een quotum per API-sleutel of per sessie maakt van een kwaadwillende bezoeker een geblokkeerde sleutel in plaats van een storing voor iedereen. Een rate limit helpt, maar volstaat niet op zich, want een tempo dat laag genoeg is om de factuur te beschermen is vaak te laag om bruikbaar te zijn.

Een plafond op de antwoordlengte. Zet bij elke call een maximum aantal output-tokens. Een parameter, geen kost, en het verzet je worstcase meer dan de meeste slimme controles.

Een goedkoper model voor onbetrouwbaar verkeer. Stuur anoniem verkeer naar een klein model en hou het dure voor aangemelde gebruikers.

Zet je alarm op het tempo van de uitgaven, niet op het maandtotaal. De helft van je maandbudget op in een namiddag: dat is het signaal. Negentig procent op dag 27 is normaal.

Waar moet je op letten bij denial of wallet?

Facturatiedata komen te laat om je te redden. Azure documenteert dat kostendata doorgaans binnen 8 tot 24 uur beschikbaar zijn en dat budgetten om de 24 uur nagekeken worden, en AWS ververst budgetinformatie tot drie keer per dag. Het signaal moet dus van een teller komen die van jou is: verzoeken per sleutel per minuut, tokens per uur, calls per endpoint, uit je eigen applicatie of uit een gateway.

Stel de vraag over het harde plafond voor je iets publiek zet. Of je leverancier een stop biedt dan wel enkel een waarschuwing, verschuift je worstcase van een paar honderd euro naar een open bedrag. Stel ze terwijl je nog aan het kiezen bent, samen met wie het plafond mag optrekken.

Gebeurt het toch, werk dan in deze volgorde. Roteer de sleutel, begrens of zet het endpoint uit, en zoek daarna pas uit welke van de drie oorzaken het was. Eerst diagnosticeren is de dure fout, want de teller loopt door terwijl je zoekt.