Skip to main content

Denial of Wallet Attacks: Protecting Against AI Cost Exploitation

Denial of wallet attacks are the financial version of denial of service. The goal is not to crash your system. The goal is to make it expensive to keep running. In AI systems that can mean oversized prompts, intentionally long completions, retry storms, tool loops, or shared-key abuse that quietly drives spend until somebody notices the invoice. Keeptrusts changes that economics by putting reserve-and-settle wallet controls, rate limits, and auditable identity-based enforcement in front of the provider call instead of behind it.

Use this page when​

  • You suspect an attacker or abusive user can turn AI usage into uncontrolled spend even without stealing data.
  • You need a cost-abuse defense model that blocks at runtime rather than alerting after the money is gone.
  • You want to combine wallet enforcement with rate limiting and request-boundary controls.

Primary audience​

  • Primary: Technical Engineers, FinOps owners, and platform operators
  • Secondary: Technical Leaders, Security teams, AI Agents

The control map​

The shortest cross-check set for this topic is Rate Limits, Audit Logger, Prompt Injection Detection, Block Prompt Injection Attacks Before They Reach Your Models, and Prevent Sensitive Data Leaks in AI Requests.

The problem​

Most organizations think about AI abuse in security terms first and cost terms second. That order is a mistake. An attacker does not always need to exfiltrate data to create real damage. They can simply force you to pay for work you never wanted.

The attack paths are straightforward.

  • Inflate prompt size with irrelevant or repeated text so each request becomes expensive.
  • Trigger long or repeated completions by asking for huge structured outputs.
  • Exploit shared API keys so one abusive actor is hidden inside normal traffic.
  • Generate retry loops or degraded fallback behavior that multiplies requests.
  • Drive parallel agent actions that stay technically valid while burning budget quickly.

Provider-side rate limits do not solve this by themselves. They protect provider capacity, not your internal budget boundaries. A request can be fully allowed by the provider and still be a denial-of-wallet event for you.

Soft budgets also do not solve it. Alerts at 80 percent or 95 percent are useful only if somebody sees them and acts in time. In a fast-moving workflow, that often means the alert arrives while the attack is still spending money.

The real control point is before dispatch. If the gateway can estimate cost, check wallet capacity, and reject or hold the request before the upstream provider meter starts, the attack surface changes completely.

The solution​

Keeptrusts gives you two complementary defenses.

The first is spend enforcement. Spend & Wallets describes the runtime flow clearly: the gateway estimates cost, reserves against the effective wallet, forwards the request only if the reserve succeeds, then settles to the actual amount after the provider responds. If no eligible wallet in the user, team, or organization cascade has enough balance, the request is held and a cost ticket can be queued instead of allowing uncontrolled overspend.

The second is capacity enforcement. Rate Limits stop a single user, team, or abusive client from monopolizing request volume, token budget, or parallel execution. That matters because cost abuse is often amplified by concurrency. Even with wallet enforcement, you want a predictable upper bound on how quickly one identity can consume capacity.

You should also keep request-boundary defense active. Prompt Injection Detection blocks inputs that try to rewrite instructions or trigger adversarial behavior. Cost abuse and prompt abuse are often related. A malicious input that forces huge outputs or repeated tool behavior is still an input-boundary problem.

Finally, keep the decision stream observable. Audit Logger is not a spending control on its own, but it makes audit visibility an explicit part of the chain so later event analysis, evidence export, and reviewer workflows are easier to trust.

Implementation​

This configuration does three things at once: it constrains request volume by identity, it keeps prompt-boundary protection active, and it marks the decision stream for audit visibility.

pack:
  name: denial-of-wallet-defense
  version: 1.0.0
  enabled: true

rate_limits:
  per_user:
    rpm: 10
    tpm: 30000
    max_parallel_requests: 2

  per_team:
    rpm: 100
    tpm: 250000
    max_parallel_requests: 15

  global:
    rpm: 300
    tpm: 900000
    max_parallel_requests: 40

user_rate_limit:
  header: "X-User-Id"
  strategy: sliding_window
  window_seconds: 60

distributed_rate_limit:
  enabled: true
  redis_url_env: REDIS_URL
  key_prefix: "kt:rl:wallet-defense:"
  window_ms: 60000
  sync_interval_ms: 50
  local_fallback: true

policies:
  chain:
    - prompt-injection
    - audit-logger

policy:
  prompt-injection:
    use_embedding: false
    detection:
      attack_patterns:
        - "ignore.*previous.*instructions"
        - "loop.*until.*complete"
        - "repeat.*the.*entire.*context"
    encoding:
      decode_base64: true
      normalize_unicode: true
      detect_homoglyphs: true
    boundaries:
      enforce_delimiters: true
      reject_fake_boundaries: true

  audit-logger: {}

That YAML controls how fast one user, one team, or the whole gateway can consume request and token capacity. It does not replace wallet enforcement. It makes wallet enforcement more effective by reducing the speed at which a single actor can burn through the available balance.

Use the API and CLI to verify the money side of the control plane as well:

curl -s "$KEEPTRUSTS_API_URL/v1/wallets/balance" \
  -H "Authorization: Bearer $KEEPTRUSTS_API_TOKEN"

kt events tail --since 1h --verdict blocked --json

Those two checks answer different questions. The wallet balance call tells you whether the effective wallet scope is still healthy. The event tail tells you whether limits or other controls are actively blocking abusive patterns.

There is also an identity lesson here. If per-user rate limiting relies on a spoofable header in a hostile environment, the attacker can rotate identities and spread the burn across buckets. That is why production rollouts should prefer authenticated identity binding instead of treating user headers as inherently trustworthy.

Results and impact​

The first result is that cost abuse becomes bounded. A malicious or careless actor can no longer turn one burst of AI traffic into unlimited financial exposure.

The second result is that spend anomalies become attributable. Because rate limits and wallet checks operate at scoped identities, you can answer who hit the cap, which team was affected, and whether the traffic looked like misuse or ordinary demand.

The third result is that you stop confusing monitoring with enforcement. Dashboards and budgets remain valuable, but they stop carrying the impossible job of preventing the event they can only describe after the fact.

This is the practical security point: AI cost governance is not separate from AI security. If an attacker can predictably turn your AI stack into a budget sink, that is a real control failure even if no data is stolen.

Key takeaways​

  • Denial of wallet attacks exploit spend, concurrency, and retry behavior rather than only uptime.
  • Wallet reserve-and-settle controls stop overspend before dispatch; alerts alone do not.
  • Rate Limits reduce how quickly one identity can burn capacity and budget.
  • Prompt Injection Detection still matters because some cost-abuse patterns begin as adversarial inputs.
  • Audit Logger helps preserve a clean evidence trail around blocked or held traffic.

Next steps​