How to Stop Bots From Running Up Your AI App's Bill

A traditional web app costs roughly the same whether a visitor loads one page or fifty. An AI-powered app doesn't. Every time a user asks your chatbot a question, generates an image, or summarises a document, you pay the AI provider for it. That changes the threat model in a way that catches a lot of builders out.

The worst case isn't someone stealing your data. It's someone — or something — using your app as a free front end to an AI model, at your expense. Security people call it denial of wallet: the app stays up, and the bill is the attack.

How it happens

The API key is in the frontend. The most expensive version. If your app calls the AI provider directly from the browser, the key is in the page source, and anyone can copy it and use it for anything, from anywhere. This isn't abuse of your app; it's theft of your key. (How to Keep API Keys Out of an AI-Built App covers why and how to fix it.)

Your API endpoint is open. The key is safely on the server, but your /api/chat endpoint answers anyone who calls it — no login, no limit. A script can call it ten thousand times.

Free accounts are unlimited. Login is required, but signing up is free and instant, and each account can use as much as it likes. A bot creates accounts.

Prompts are unbounded. Someone pastes a 200-page document into every request, or asks for the longest possible response. Cost scales with input and output length.

A loop you wrote. Not every surprise bill is an attacker. A retry loop that never gives up, a background job that runs every minute instead of every day, or an agent that keeps calling tools can do it too.

Layer 1: keep the key on the server

Non-negotiable. The browser talks to your server; your server talks to the AI provider. The key never leaves the server. Everything below depends on this, because once the key is public, none of your limits apply.

Layer 2: require an account

Anonymous access to anything that costs you money per request is an invitation. Put AI features behind login, so every request is tied to a user you can limit, and ban if needed. (How to Add Login to an AI-Built App covers doing that properly.)

If you want a free trial experience for logged-out visitors, make it small and strictly limited per IP address.

Layer 3: rate limits

A rate limit caps how many requests a user (or IP address) can make in a period: say, 20 requests a minute and 200 a day. When they hit it, they get a polite "slow down" instead of another expensive call.

Limit per user, and per IP address as a backstop for unauthenticated routes and sign-up.
Apply limits on the server, on the endpoint that calls the AI. A limit in the frontend is a suggestion.
Store counts somewhere shared — a database or Redis — not in the server's memory, so they survive restarts and work across multiple instances.
Limit sign-ups too. Rate-limit account creation, and consider email verification or a bot check on the sign-up form, so bots can't just create fresh accounts.

Layer 4: usage caps and quotas

Rate limits stop bursts. Quotas stop slow, steady overuse.

Give each plan a budget — a number of messages, generations, or tokens per day or month. Free users get a small one.
Track usage per user in your database, recording the tokens each request used (AI providers return this with every response).
Cap input and output size. Truncate or reject oversized inputs, and set a maximum output length on every call. This bounds the cost of a single request.
Pick the model per task. Not every feature needs the most expensive model. A cheaper, faster model for simple tasks can cut costs dramatically.

Layer 5: spending limits at the provider

Your code will have bugs. The last line of defence lives outside it: set a spending limit with your AI provider. Most providers let you set a monthly spend cap or budget alert on your account or workspace. Set an alert well below what would hurt, and a hard limit at the level that would. If everything else fails, the damage is capped.

Also set a budget alert with your hosting provider, if it bills by usage.

Layer 6: watch for it

A daily cost check. A glance at your provider's usage dashboard, or an automated alert when daily spend exceeds a threshold.
Top users by usage. A query that lists your heaviest users each day. Abuse is usually obvious — one account with a thousand times the usage of the next.
Unusual patterns. Sudden spikes in sign-ups, many accounts from the same IP range, requests arriving at machine speed.

Error tracking and alerting help here too — see How to Know When Your App Is Down.

If it happens

Rotate the API key if there's any chance it leaked. This stops key theft instantly.
Block the abusing accounts or IPs.
Tighten limits temporarily while you work out what happened.
Contact your AI provider. Explain what happened. Providers are often understanding about genuine abuse incidents, especially if you can show what you've changed.

The checklist

AI provider key only on the server; never in frontend code or VITE_/NEXT_PUBLIC_ variables
AI features require login; any anonymous access is tiny and IP-limited
Server-side rate limits per user and per IP
Sign-up rate-limited, with verification or a bot check
Per-user quotas, tracked in the database
Maximum input size and output length on every call
Spending limit and budget alerts set with the AI provider
A daily look at cost and top users

The goal isn't to make abuse impossible. It's to make sure the worst day costs you an amount you can shrug off.

EasySpawn runs your app's backend on a real server, so AI keys stay in server-side environment variables and rate limits can live in a managed Postgres or Redis instance — on flat, predictable infrastructure pricing. See how it works for AI-built apps or join the waitlist.