What is a denial-of-wallet attack?

It is an abuse pattern unique to metered AI APIs where an attacker drives up your provider bill rather than taking you offline. Because each call costs real money, a flood of expensive requests can be financially damaging even at modest request rates — which is why cost caps matter as much as rate limits.

Why are AI endpoints riskier than ordinary APIs?

Each call can be expensive and slow, outputs can leak system prompts via prompt injection, and the endpoint is attractive for scraping model behaviour. Standard rate limiting is necessary but not sufficient; you also need cost caps and content-level controls.

Should public AI endpoints exist at all?

They can, but only with strict limits, a hard daily cost cap, bot defences, and ideally a lightweight challenge. Unauthenticated access to a metered model is the highest-risk configuration, so the advisor tightens its recommendations sharply when there is no auth.

How are the suggested numbers derived?

They start from your expected per-user volume and scale it by a safety multiplier, then cross-check against your cost per call so the daily cap stays within a sane budget. They are sensible defaults to start from, not guarantees — tune against real traffic.

Do rate limits stop prompt injection?

No. Rate limits slow abuse but do not prevent a single crafted request from manipulating the model. You also need input/output filtering, system-prompt isolation, and not trusting model output as commands, which the advisor lists alongside the limits.

AI API Rate Limit Security Advisor

AI API rate limit security advisor

A metered AI endpoint has a failure mode ordinary APIs don’t: an attacker can run up your bill — a denial-of-wallet attack — without ever taking you offline. On top of that, AI endpoints invite prompt injection and behaviour scraping. This advisor takes a short description of your endpoint and returns a concrete starting configuration: per-minute and per-day rate limits, a daily cost cap, authentication requirements, and the abuse controls that match your risk.

How it works

You tell the tool whether the endpoint is public or authenticated, the expected requests per user per day, and your provider cost per call. It scales your expected volume by a safety multiplier to set rate limits that absorb legitimate bursts while cutting off floods, then uses your cost-per-call to propose a daily spend cap that keeps a worst-case day within budget. Public endpoints get much tighter limits, mandatory bot defences, and a recommendation to add auth. Alongside the numbers it lists the content-level controls — input/output filtering, system-prompt isolation, never trusting model output as commands — that rate limiting alone cannot provide.

Tips and notes

Cap cost, not just rate. A few expensive calls can hurt more than many cheap ones; a hard daily spend cap is your real backstop.
Authenticate metered endpoints. Per-key limits and attribution are far stronger than per-IP on a public route.
Rate limits don’t stop injection. Layer input/output filtering and treat model output as data, never as commands.
Start strict, loosen with data. It’s easier to relax a limit than to recover from a runaway bill.