How do you protect a public LLM application from abuse that runs up cost or takes it down?

Put limits at every layer: per-user and per-IP rate limits and quotas, input size limits, max_tokens and timeouts on every call, turn and budget caps on agents, and spend alerts and hard caps for the whole service. Require sign-in or other friction for expensive features, monitor for unusual patterns, and degrade gracefully when limits are hit. OWASP calls this risk unbounded consumption (LLM10:2025).

What the attacks look like

OWASP lists several patterns:

• Input floods: many requests with very long inputs, to exhaust capacity.
• Denial of wallet: running up the bill on a pay-per-use service until it becomes unaffordable.
• Continuous input overflow: inputs that exceed the context window, over and over.
• Resource-heavy queries: prompts designed to cause long outputs or long agent loops.
• Model extraction: very large numbers of queries to copy the model's behaviour.

Controls

Per request

• Maximum input length, checked before calling the model.
• max_tokens on every call; timeouts; a cap on retrieved context.
• For agents: maximum turns, tool calls and tokens per task.

Per user

• Rate limits (requests per minute) and daily quotas (tokens or requests).
• Stricter limits for anonymous users; sign-in, verification or a CAPTCHA for costly features.
• Blocking or slowing clients with abusive patterns.

Per service

• A budget with alerts at, say, 50% and 80%, and a hard cap you choose deliberately. Know what happens at the cap: the provider's spend limit may stop all traffic, legitimate users included.
• Keep your own limits below the provider's rate limits, so one user cannot exhaust capacity for everyone.

Cheaper paths

• Cache common answers; use smaller models for simple requests; batch background work.

Monitoring

• Cost per user, per feature, per hour, with anomaly alerts.
• Distribution of input and output lengths; spikes in long inputs are a warning sign.
• Requests per user and per IP; many near-identical requests may be extraction or scripted abuse.

Degrading gracefully

When limits hit, return a clear message, queue work for later, or fall back to cheaper responses, instead of failing everything.

A worked example

"Our free tier allowed 20 questions a day per signed-in user, 2,000 input characters each, max_tokens 800, and a global daily budget alert. A scripted attack from new accounts hit the per-account and per-IP limits within minutes and cost a few dollars instead of thousands."

Summary: "Every call has a ceiling, every user has a quota, and the service has a budget with an alarm."