Free Credits Are Compute. Who Is Spending Yours?
How free-credit farming, multi-accounting, key resale and metering gaps drain usage-priced AI and API platforms, with a self-check and how the audit works.
Usage-priced AI and API businesses have a fraud problem that does not show up as fraud. There is no stolen card, no chargeback spike and no angry customer. There is a growth chart full of signups, a free tier that costs real compute, and a gross margin that is a little worse each month than the model said it would be.
For a traditional SaaS product, a fake free-trial account costs almost nothing to serve. For an AI product, every free request is GPU time someone pays for. That changes free-tier abuse from a nuisance into a cost line.
The four ways the money leaks
- Free-credit farming. One operator opens many accounts to claim the signup credit on each, then uses the combined credit for real workloads, or sells it.
- Multi-accounting. When an account hits a rate limit, a ban or the end of a trial, the same person returns under a new email, a new phone number and a new card. Anthropic's September 2026 threat intelligence report describes actors laundering their access through VPNs, foreign phone numbers and rotated accounts. Those are the same tools a free-credit farmer uses.
- Key resale. API keys, often belonging to paying customers who exposed them, are pooled and resold behind a proxy. Sysdig's research on what it named "LLMjacking" found attackers using stolen cloud credentials and a reverse proxy, with the apparent intent to sell LLM access to other criminals while the account owner pays the bill. Sysdig's own worst-case model put the cost to a victim at over 46,000 dollars a day. The same report from Anthropic describes resellers supplied largely by compromised access from legitimate customers.
- Metering gaps. Usage that is served but never billed: requests that bypass the meter, streaming responses counted only when completed, cached results that are free to the user but not free to you, or tiers whose limits are enforced per key instead of per account.
The first three are adversarial. The fourth is usually a bug. All four show up the same way in the finance view: compute cost rising faster than revenue.
Why it hides
Each team sees a piece that looks fine on its own. Growth sees signups and celebrates. Finance sees cloud spend and blames model choice. Engineering sees rate limits working as designed. Trust and safety, if it exists yet, is focused on content misuse rather than on economic abuse. Nobody joins signup data, payment data and usage logs at the level of the person behind the accounts, which is the only level at which farming is visible.
The standard defences also have known gaps. Email verification stops nobody who has a domain with catch-all addresses. Phone verification is weakened by cheap virtual numbers. Requiring a card at signup helps, but prepaid and virtual cards make it a speed bump, and a card check that authorises without capturing proves only that a card exists.
If you are raising money or borrowing against revenue, a measured abuse figure, with the rules that contain it, is a stronger answer to questions about user and revenue quality than an estimate.
A self-check your team can run in a week
- Compute cost per free account by cohort. Split last quarter's free signups by week and compute the inference cost each cohort used before converting or going quiet. A cohort that costs far more than its neighbours, with lower conversion, is where to look first.
- Count accounts per device and network. Group signups by device fingerprint, IP range, and browser and timezone combination. Look at the long tail: how many "people" share one device?
- Normalise emails and phones. Strip dots and plus-suffixes from email addresses and check for catch-all domains. Look up phone numbers for virtual-number carriers. Re-count unique users.
- Look at the shape of usage. Real new users explore. Farmed accounts often burn the full credit quickly, through the API rather than the product, on the same prompt template or model, and then go quiet.
- Check keys for impossible travel. One key used from many networks or countries in a short window, or with a sudden change in request pattern, suggests it has been shared or resold.
- Reconcile metered usage with billed usage. For one day, compare what your serving layer recorded against what billing charged. The difference, if any, is your metering gap, and it is often larger than the fraud.
- Test your own signup. Try to open three accounts from one laptop with a catch-all domain and a virtual number. If all three get credit, so does everyone else.
A developer platform gives new accounts a modest free credit. Signups look healthy. When the team groups accounts by device and normalised email, a few hundred "users" collapse into a handful of operators, each using the free credit through the API on the same batch summarisation job. Their combined usage accounts for a meaningful share of the free tier's compute bill. A rule tying credit to one verified payment method per device cluster removes most of it.
How Riskernel runs this as a fixed-scope assessment
The Signup and Credit Abuse Audit is a fixed-scope forensic audit of your signup, payment and usage logs. It groups accounts by the operators behind them, sizes the loss across free-credit farming, multi-accounting, key resale and metering gaps, and hands over blocking rules your team can put into production.
It is a forensic piece of work on data you already have, not a new product to integrate. The output is a loss figure your finance team can check and rules your engineers can ship. Scope, data access and fees are agreed on a short call.
Signup and Credit Abuse Audit
See the offer on the products page, or email amir@amirshachar.com to scope it.