Free-trial abuse vs API-key abuse vs rate limiting: which layer stops what

A self-serve AI product gets a surprise five-figure compute bill, and the incident channel calls it "API abuse." Sometimes that is right. Often the real cause sits one layer upstream, at signup, where one person quietly farmed a hundred free-trial accounts and every one of them minted a valid key. In 2025, Stripe found that AI startups with self-serve sign-ups and direct API access saw 10x more attempted abuse than enterprise AI solutions, and a lot of that pain comes from blaming the wrong layer. Free-trial abuse, API-key abuse, and rate limiting get treated as one thing. They are three problems, on three layers, with three owners, and the fix for one does almost nothing for the others.

Key takeaways

• Free-trial abuse is an identity problem at signup: one user opening many accounts to claim free credits. You stop it before a key is ever issued.
• API-key abuse is a usage problem after a key exists: a key, often a leaked legitimate one, called at a volume or in a pattern it should not be.
• Rate limiting and spend caps are ceilings, not an identity check. They cap any single key, but they do not know that one person is behind a hundred of them.
• The layers complement each other. Identity scoring keeps farmed accounts from minting keys; gateway limits contain the damage of any key that slips through or leaks later.
• A CAPTCHA gates obvious bots at the form. It does not catch a human operator running many real-looking signups, and it is a different control from device-and-network identity.

The three problems people blame for one bill

These three get conflated because they all end in the same place, a bigger-than-expected bill or a degraded service, but they start in different places. Naming where each one starts is the whole game, because the cheapest fix lives at the layer where the problem begins, not where the symptom shows up.

• Free-trial abuse starts at the signup form, before any account or key exists. One user creates many accounts to claim the free credits each new account gets.
• API-key abuse starts after a key is issued: a valid key gets shared, leaked, or pointed at the API in a way it was never meant for.
• Rate limiting is not a problem at all; it is the gateway control that caps how hard any one key or org can hit you. It contains damage, but it does not identify who is behind the traffic.

Conflating them is how a team ends up with a gap: they tighten rate limits and rotate keys after a bad week, feel safer, and never notice that the farmed accounts minting those keys are still arriving at the front door untouched.

Free-trial abuse vs API-key abuse vs rate limiting at a glance

Here is the boundary in one view. Read down each column to see that these are genuinely different problems, not three names for one.

	Free-trial (signup) abuse	API-key abuse	Rate limiting and spend caps
What it is	One user opens many accounts to claim free credits repeatedly	A key, often a leaked or shared legitimate one, used at the wrong volume or pattern	A ceiling on how many calls or how much spend any one key or org is allowed
When it happens	At signup, before the account or key exists	After a key is issued, during usage	Continuously, as a guardrail on every key
What is behind it	A human (sometimes automated) farming identities; the device repeats while the email and IP rotate	A leaked credential, a scraper, or a legitimate key pushed past its intent	Nothing; it is your own enforcement, not an adversary
The layer	Signup identity	Key usage	Gateway
Who owns the fix	Identity scoring at registration	Key rotation, scoping, per-key monitoring	Your API gateway or proxy
What it costs you if missed	Compute burned across a hundred farmed accounts, plus polluted growth metrics	A single key running away with your budget or exfiltrating data	Without it, one key can drain the whole bill

The diagram below is the same split, drawn as the three layers a signup request passes through.

What is free-trial abuse?

Free-trial abuse is one user creating many accounts to claim the same free offer more than once, scored and stopped at the registration before any credits or keys are provisioned. It hides because the user changes the surface details, a fresh email, a new IP, a cleared cookie, while the device and network behind the accounts repeat. An email check or an IP rule never sees that repetition; reading the device does.

We measured this by rebuilding a signup the way a farmer does, rotating a new email, a fresh IP, and an emptied cookie on each pass, and the device underneath kept pointing at the same identifier every time. The surface details are meant to be disposable; the device is the part that repeats. That gap only widened in 2020, when Safari began blocking third-party cookies by default, leaving a cookie an even weaker anchor for a signup than the device beneath it.

This is the only one of the three layers that is about who is signing up rather than what a key is doing. The advantage is timing: scoring the registration is far cheaper than chasing the compute after a hundred trials are already calling the model. The signals, the credit-gating, and the economics of how to prevent free-trial abuse at an AI company all turn on that timing; the point here is just where it sits: upstream of the key, at identity.

What is API-key abuse?

API-key abuse is a valid key being used at a volume, from a place, or in a pattern it was never meant for, and it lives entirely after the key is issued. The key might be a leaked secret committed to a public repo, a shared credential passed around a team, or a legitimate key repointed at scraping the model's output. Whatever the source, the control surface is the key itself, and the standard moves are the gateway's:

• Scope and rotate keys. Short-lived, narrowly scoped keys limit the blast radius of any one that leaks. Broken authentication is one of the most common API risks for a reason, and it is squarely an API-security concern, not a signup one.
• Per-key spend caps. A hard ceiling on spend per key and per org means no single credential, abused or not, can run away with your budget. The OWASP API Security Top 10 calls the missing version of this "unrestricted resource consumption."
• Anomaly monitoring on usage. Watch for a key whose call volume, geography, or endpoint mix suddenly changes, the signature of a credential that has left its owner's hands.

None of this reads the human at the front door, and it does not need to. API-key abuse is downstream of identity. By the time a key exists, the farmed-account question was already answered, or missed, one layer up.

What is rate limiting (and spend caps)?

Rate limiting caps how many requests a key or org can make in a window, and spend caps cap how much it can cost; both are essential guardrails, and neither knows who is behind the traffic. They are about volume, not identity. A rate limiter will happily throttle one key at a thousand requests a minute, which is exactly what you want when a single credential goes rogue.

The gap is structural: a rate limit applies per key. The free-trial farmer's whole technique is to spread the load across a hundred keys, each one comfortably under the limit. A hundred accounts each making polite, well-behaved calls is invisible to a per-key ceiling, because no individual key ever misbehaves. Spend caps have the same blind spot. They stop one key from draining the budget; they do nothing about a hundred keys each spending a small, allowed amount that sums to the same loss. Rate limiting contains the runaway-key problem and leaves the farmed-account problem completely open. That is not a flaw in rate limiting; it is just a different layer.

Where CAPTCHA and bot-gating fit

A CAPTCHA sits at the signup form and tries to separate humans from scripts, which makes it a bot control, not an identity one. It raises the cost of fully automated, headless signup floods, and for that narrow job it helps. Two things it does not do: it does not stop a human operator, or a lightly automated one driving a real browser, from completing many real-looking signups, and it does not tell you that two solved-CAPTCHA signups trace back to one machine. CAPTCHA asks "is this a bot?"; the identity layer asks "have we seen this device before?". They answer different questions, and a serious farming operation passes the first while failing the second.

Which layer stops what: the honest map

Put together, the picture is simple and the layers do not substitute for each other:

• Signup identity catches the farmed account before a key is minted. It is the cheapest place to act, because nothing has been provisioned yet.
• Key scoping, rotation, and monitoring contain a key after it exists, whether it was farmed past the identity layer or leaked later.
• Rate limits and spend caps are the backstop that keeps any single key, abused or not, from running away with the bill.
• CAPTCHA thins out crude automation at the form, and leaves the human-operated farm for the identity layer.

A team that only hardens the gateway, more rate limits, tighter key scopes, is defending the second and third layers while the first stays open. A team that only scores signups stops the farm but still needs ceilings for the key that leaks next week. The two halves are complementary by design.

Where ShieldLabs fits, and where it does not

ShieldLabs reads exactly one of these layers: the signup-identity one. You add a JavaScript snippet to your signup or trial-activation page, and on the first visit it returns a risk score from 0 to 100 with the anonymity signals and a persistent device identifier behind it, before a single credit or key is provisioned. When a "new" signup traces back to a device you have already seen, that linkage is the farmed-account tell a fresh email is meant to hide.

To be plain about scope: ShieldLabs scores the signup on a 0 to 100 risk score, names the anonymity signals that fired, and provides pre-built patterns, so your team can keep farmed accounts from minting keys in the first place and the layer downstream has less to contain. Key usage monitoring, secret rotation, and spend-cap enforcement are your gateway's job, and they should stay there. You read the risk score and named anonymity signals through the API and webhooks and decide, by your own rules, whether to gate credits, ask for a verification step, or let a clean signup through. It complements the gateway. The same identity layer carries into new-account fraud prevention and free-trial abuse prevention.

Sources

1. Stripe: Analyzing first-party fraud trends: account, free-trial and refund abuse (2025)
2. OWASP: API Security Top 10 (2023): API2:2023 Broken Authentication, API4:2023 Unrestricted Resource Consumption
3. Wikipedia: Rate limiting