Denial-of-Wallet: wanneer een kwaadaardige MCP-tool 14.000 keer uw factuur opblaast

De verborgen kosten van vertrouwen

Multi-step LLM-agents die tools aanroepen, bewaren de uitkomst van elke toolcall in hun context-historie. Dat is nodig voor coherentie: de agent moet weten wat er eerder is gebeurd om de volgende stap te bepalen. Maar diezelfde historie wordt bij elke nieuwe turn opnieuw naar de modelprovider gestuurd, en bij elke turn wordt opnieuw gefactureerd. Wanneer een kwaadaardige of gecompromitteerde tool inhoud injecteert die blijft circuleren, ontstaat een structuur die de auteurs persistent billable state noemen: onbetrouwbare data die recursief en herhaaldelijk in rekening wordt gebracht.

Zhang et al. (Chinese Academy of Sciences) presenteren in Persistent Billable State: Denial-of-Wallet Attacks and Defenses in Tool-Calling LLM Agents (arXiv:2609.28585) de eerste systematische studie naar dit post-admissie-leven van tool-output. Zes denial-of-wallet-attackvectors worden afgeleid, geëvalueerd over zes modelfamilies, en de resultaten zijn confronterend. De maximale cumulatieve input over een sessie bereikt 14.293 keer de input van de eerste call. Dit is geen afrondingsfout of edge case; dit is een aanval die elke organisatie met MCP-gebaseerde agents in productie kan treffen.

Hoe persistent billable state werkt

Het mechanisme is eenvoudig maar subtiel. Een agent-runtime roept een externe tool aan, bijvoorbeeld via het Model Context Protocol (MCP). De tool retourneert data. Die data wordt in de context-historie opgenomen en bij elke volgende agent-turn opnieuw als input meegestuurd naar het LLM. De provider rekent per token af. Als de tool kwaadaardige of overmatig lange content injecteert, wordt die content bij elke volgende turn opnieuw gemeten en gefactureerd. De aanvaller hoeft geen credentials te bezitten, geen lokale runtime-privilege te hebben, en hoeft slechts één keer te injecteren. De schade is passief, accumulerend, en volledig aan de kant van het slachtoffer gefactureerd.

De auteurs noemen dit de persistent billable-state boundary: de beslissing van de host-runtime over welke content uit een tool-return de volgende billable context ingaat. Die grens is vandaag de dag in vrijwel geen enkele productieruntime expliciet beheerd. De tool zegt, de runtime voert uit, en het model betaalt.

Zes attackvectors en hun impact

Uit de analyse komen zes concrete aanvalsvormen naar voren. De belangrijkste zijn recursive injection (de kwaadaardige content roept impliciet verdere toolcalls uit die de payload versterken), history poisoning (de historie wordt zo vervuild dat de agent functioneel onbruikbaar wordt terwijl de kosten doorlopen), en cumulative amplification (elke turn voegt meer kwaadaardige massa toe dan de vorige). Deze aanvallen richten zich niet op vertrouwelijkheid of integriteit in de klassieke zin, maar op availability van het budget: de agent wordt duur voordat hij wordt uitgeschakeld.

In DOW-BENCH, het evaluatieframework dat de auteurs bouwden, worden 243 uitvoeringen over zes modelfamilies gemeten. De maximale sessiecumulatie van 14.293× betekent dat een sessie die begint met een input van duizend tokens, kan uitmonden in een factuur voor veertien miljoen tokens zonder dat de gebruiker dit merkt. Dit is geen theoretische limiet; het is een waargenomen maximum.

History-policy: de kosten van onvoorwaardelijk bewaren

De auteurs isoleren het effect van de history-policy door gecontroleerde reruns. Wanneer een runtime de raw history onverkort bewaart, stijgt de gemiddelde effectieve sessiekost met 21,2 tot 35,9%. Dat betekent dat alleen al het onvoorwaardelijk behouden van ruwe historie, zonder enige aanval, een significante kostenopdrijver is.

Wanneer de historie wordt gecomprimeerd in plaats van verwijderd, blijft de functionaliteit veel beter behouden. Op twaalf history-afhankelijke taken slaagt compressie bij tien van de twaalf en elf van de twaalf taken, afhankelijk van de provider, terwijl deletion slechts bij twee van de twaalf taken succesvol is. De les is duidelijk: weggooien werkt niet als de agent zijn werk moet blijven doen, maar ruwe retentie is een kostenval.

Vier host-side invarianten

Om de billable-state-grens te beheersen, formuleren de auteurs vier deterministische host-side invarianten die elke runtime zou moeten afdwingen vóór een tool-return opnieuw in de context wordt ingevoerd:

1. Prompt-mass: de totale massa van een tool-return mag niet groter zijn dan een vooraf gedefinieerd maximum.
2. Context-growth: de groei van de context per turn mag niet oneindig accumuleren; er moet een bovengrens zijn.
3. Recursive-opportunity: de kans op recursieve herinjectie moet beperkt worden door transformatie van de return voordat die de context ingaat.
4. Cumulative-spend: er moet een maximale cumulatieve uitgave per sessie worden afgedwongen, onafhankelijk van functionele voltooiing.

Deze invarianten zijn niet optioneel. De auteurs tonen aan dat een progress-authorized policy die deze invarianten combineert, op 24 Mistral Small 4-workflows 22 van de 24 orakel-geverifieerde taken succesvol afrondt zonder voorafgaande onderbreking, tegenover slechts 13 van de 24 onder een fixed-cap-beleid. Dat betekent dat beveiliging en functionaliteit hier geen trade-off vormen, mits de invarianten correct worden geïmplementeerd.

Het MCP-safeguard-gap

De auteurs scanden 3.830 publieke MCP-server- en transportrepositories. Slechts 71 daarvan, minder dan 2%, bevatten enige vorm van zichtbare safeguard-proxy in de code. Geen enkele dekt alle vier de safeguard-families die nodig zijn om persistent billable state te mitigeren. Dit is geen implementatietekort van één framework; dit is een ecosysteem dat systematisch de post-admissie-fase negeert.

Voor organisaties die vandaag MCP-tools in productie draaien, betekent dit dat de runtime die tussen tool en model zit, waarschijnlijk geen enkele van de vier invarianten afdwingt. De grens is open.

Een availability-aanval onder NIS2 artikel 21

Onder NIS2 artikel 21 lid 2(c) vallen supply-chain-security en het beheer van vertrouwensrelaties met leveranciers. Maar de kwalificatie van denial-of-wallet als availability-aanval is even relevant: artikel 21 vereist dat essentiële en belangrijke entiteiten maatregelen nemen om de beschikbaarheid van hun diensten te waarborgen. Wanneer een gecompromitteerde MCP-tool via persistent billable state het AI-budget van een organisatie opvreten tot het punt waarop agentische diensten onbetaalbaar of onbruikbaar worden, is dat een directe aantasting van availability.

De aanval vereist geen DDoS-infrastructuur, geen botnet, geen credential-diefstal. Eén gecompromitteerde toolserver, één injectie, en de kosten lopen passief op. De drempel is zo laag dat elke organisatie die externe MCP-tools gebruikt, zorg, overheid, financiën, energie, dit risico moet beoordelen als onderdeel van zijn NIS2-risicomanagement.

Wat u vandaag kunt doen

De eerste stap is inzicht. Inventariseer welke externe toolservers uw agent-runtime aanroept en of die retourwaarden ongefilterd in de context-historie worden opgenomen. De tweede stap is het invoeren van de vier invarianten als runtime-policy, niet als naafhankelijke code-review. De derde stap is beperkt de blast radius: geen enkele toolserver mag onbeperkte context-growth veroorzaken.

Voor organisaties die nog geen agent-runtime security review hebben uitgevoerd, is dit een concrete actie met een helder bereik: een review van de billable-state-grens en de bijbehorende policies kost doorgaans tussen de 25.000 en 50.000 euro en levert een direct beheersbaar risico op dat anders maandelijks ongemerkt in de cloudfactuur doorsijpelt.

Het is verleidelijk om dit af te doen als "een kostenprobleem, geen security-probleem". Maar de cijfers spreken voor zich: 14.293×, 21-35% kostenstijging door louter retentie, en een ecosysteem waar 98% van de publieke servers geen enkele safeguard heeft. Dit is geen kostenprobleem. Dit is een onbeheerde trust-grens die rechtstreeks in de portemonnee van de aanvaller uitmondt.

Referenties

Zhang, Xia, Wu, Yue, Zhang, Cheng, Tu et al., Persistent Billable State: Denial-of-Wallet Attacks and Defenses in Tool-Calling LLM Agents, arXiv:2609.28585, Institute of Information Engineering, Chinese Academy of Sciences, 23 september 2026.