If your AI product gives free credits, some of your signups are the same person
Stripe looked at first-party fraud across its merchants and found that AI startups with self-serve signup and direct API access see about 10x more attempted abuse than enterprise AI products (source: https://stripe.com/blog/analyzing-first-party-fraud-trends-account-free-trial-and-refund-abuse).
The reason is plain economics. On a normal SaaS a fake free account costs a database row. On an AI product it costs GPU time the moment it sends a prompt. One person running a hundred trial accounts is a hundred compute allocations on your bill. It also skews your activation and trial-to-paid numbers, because part of the funnel was never a real prospect.
How the farming usually works
It goes by many names (trial cycling, trial farming, multi-accounting, account farming), but the mechanics are the same. For every new account the person swaps:
- the email (a disposable inbox, or just a second and third address)
- the IP (a VPN or a residential proxy)
- the cookies (cleared, or a fresh browser profile)
What does not change is the machine behind all of it.
Why the usual checks miss it
- Email verification proves someone owns an inbox, not that they are a new person.
- IP limits break the moment one proxy subscription hands out thousands of addresses.
- Cookie checks are undone in one click.
Each of these looks at one surface detail, and farming works by changing exactly those details.
What helps, cheapest first
- Small starter credit, unlock the rest later. Give a new account enough to see the product, and unlock the bigger balance once the account looks real: a card on file, a verified phone, a few days of normal use. A farmed account never reaches the expensive models on day one.
- Spend caps per key and per org. One account, farmed or leaked, should never be able to run away with your budget. This lives in your API gateway.
- Score the signup before you issue the key. Read the device and the network at registration: is the same device behind several "new" accounts, is it an anti-detect browser, is it a VPN or a residential proxy, did five signups come from one footprint in ten minutes. No single signal decides anything. Several agreeing is the case.
- Aim for unprofitable, not impossible. You do not need to catch everyone. You need running a hundred accounts to cost more than the credits are worth.
One distinction that saves a lot of arguments
Free-trial abuse is a signup problem: one person, many accounts. API-key abuse is a usage problem: one key used in a way it should not be. Rate limits fix the second and do nothing for the first. Signup scoring fixes the first and does nothing for the second. You want both layers.
Is it even illegal?
Usually not. Opening extra accounts to get more free credits breaks your terms of service, and in most places that is a contract matter, not a crime. You are still allowed to enforce your terms. Just base it on evidence (linked accounts, a shared device, timing) rather than a hunch, so real users do not get caught in it.
Disclosure: I'm the CMO at ShieldLabs, which covers the signup-scoring layer. A JavaScript snippet returns a risk score from 0 to 100 with the 300+ signals behind it and flags multi-accounting directly. The full guide, with the signal table and an example API response, is here: https://shieldlabs.ai/blog/how-to-prevent-free-trial-abuse-ai
How do you handle it on your product: gate credits, require a card up front, or treat it as a marketing cost?
Great breakdown. What feedback have you had from early users?
Interesting. How are you measuring whether it is working?
Great breakdown. One lightweight layer that helped in a similar case: ask for one thing at signup that's annoying to fake at scale but easy for a real user, like the project or use case in a sentence. Farmers paste junk or the same text across accounts, which becomes a useful signal alongside device fingerprinting, and real users don't mind.
One thing I've found useful is treating activation as a verified first outcome, not a signup or a completed onboarding. For a product with expensive inference, I’d instrument (1) the first meaningful result, (2) repeat use within a few days, and (3) whether the user reaches the point where extra credits are actually valuable. Then issue more credits after that behavior, not just after a card or phone check. It limits farming without punishing legitimate users upfront. Device and network signals seem useful as a backstop, but I’d keep them out of the main product experience and measure false positives by cohort.
This is great work — reminds me of some of the calls I've had to make building Xstream4K. What would you do differently if you started over?