Sponge Examples & Denial-of-Wallet: Exhausting AI Systems

What happened

Sponge examples (Shumailov et al., 2020) are inputs deliberately crafted to maximize the energy and time a neural network spends per inference — soaking up compute the way a sponge soaks up water. Against a hosted model this degrades throughput and can deny service to legitimate users.

On today’s metered LLM APIs, the same principle becomes denial-of-wallet: an attacker sends queries engineered to trigger maximum output length or worst-case compute, driving the operator’s bill up or exhausting rate/quota so the service throttles. It’s a low-glamour but practical attack on availability and cost rather than confidentiality — and it’s cheap to launch.

Why it maps to ATLAS

• AML.T0046 — Spamming AI System with Chaff Data: high volumes of expensive/worst-case inputs are pushed at the service.
• AML.T0034 — Cost Harvesting: the attack runs up the operator’s compute/API costs.
• AML.T0029 — Denial of AI Service: availability degrades for legitimate users.

Detection notes

This is one of the easier attacks to see: per-request latency, token counts, and cost are strong signals. Enforce per-account compute/token budgets and rate limits, cap output length, time out worst-case inference, and alert on cost/latency outliers. Expensive endpoints should sit behind authentication and quotas by default.

Detection

Log sources

• Per-request latency + token/compute metrics
• API cost + rate telemetry per account

Signals

• Inputs that maximize output length or compute per request
• Sharp rise in cost/latency from a small set of crafted queries
• High volume of long-output or worst-case-timing requests

Mitigations

• Per-account token/compute budgets and rate limits
• Cap output length; timeout worst-case inference
• Anomaly-detect cost/latency outliers; require auth on expensive endpoints