API Key Farming: Stopping Free-Tier Key Harvesting on AI Platforms

Every AI platform with a free tier eventually meets the same customer: someone who signs up forty times, creates a key in each account, and puts the forty keys behind a small rotating proxy. To the platform it looks like forty light users. To the operator it is one meaningful workload running on your GPUs at no cost, sometimes resold to others as “cheap API access.”

Key farming differs from ordinary free-credit abuse in one important way: the abuse happens on your API, where there is no browser, but the setup happens on your dashboard, where there is. That asymmetry decides where detection has to live.

How a key farm is built

The mechanics are mundane, which is why they scale:

1. Account creation. Emails come from plus-addressing, catch-all domains or disposable providers. Signups are done by hand, by a script driving a real browser, or by a mix.
2. Key generation. Each account visits the API keys page and creates a key, often within minutes of signing up.
3. Pooling. Keys go into a gateway that round-robins requests across them, keeping each one under your per-key rate limit and free quota.
4. Replacement. When a key is revoked or exhausted, the operator creates a new account and a new key. The pool is designed to absorb losses.

Step 4 is why per-key enforcement fails. You can revoke keys all day; what you need is to make each new account expensive.

Why the API layer is the wrong place to look

At call time, you see an API key, a server IP and a request body. The calls come from the operator’s gateway, often a cloud host, so every key in the pool shares an egress IP. That is a useful correlation, but a weak one: legitimate customers also call from AWS, GCP and shared CI runners, and a careful operator spreads traffic across residential proxies.

The browser session where the account was created carries much richer evidence: a stable device identifier, the network it came from, whether it was automated, and how many other accounts that device has created. Score there, and the API traffic becomes something you attribute rather than something you have to classify.

The signals that expose a farm

Accounts per device

The strongest single signal. Run the Prynt agent on your signup page and on the page that creates API keys, verify the event server-side, and read accountsOnDevice: every account id you have linked to that device. A farmer creating accounts from one machine shows up as a device with ten, twenty, forty accounts, regardless of how many emails or IPs they burned.

On paid plans the risk engine also computes this over time: multiAccount fires at two or more distinct accounts on a device within 30 days, and accountSharing at more than three in 24 hours, with the reason codes MULTI_ACCOUNT and ACCOUNT_SHARING.

Network origin

Farm operators rarely sign up from a home connection. Look at datacenter, proxy, residentialProxy, vpn and tor in smartSignals. None of these is damning on its own, because developers use VPNs and cloud desktops, but a fresh account on a datacenter IP that creates a key within two minutes is a different animal from a developer who has been browsing your docs for a week.

Automation

Scripted signups leave tells: bot, tlsFingerprint mismatches (reason code TLS_AUTOMATION), and robotic interaction from behavioral analysis (AUTOMATION_BEHAVIOR). The fake account farm guide covers how these combine.

Key-creation velocity

Your own data matters here. Keep a counter of keys created per visitorId per day, and the time between account creation and first key. A legitimate developer creates one or two keys over weeks. A farm creates one per account, immediately, many times a day from the same device.

Wiring it into key creation

Identify on the key creation page with the user already known, so the event is linked at the moment it is created:

const prynt = await Prynt.load({ apiKey: 'pk_live_…', extendedResult: true }); // compute Smart Signals + decision
const { requestId } = await prynt.identify({
  tag: { action: 'create_api_key' },
  linkedId: currentUser.id,
});
await fetch('/api/keys', { method: 'POST', body: JSON.stringify({ requestId }) });

Then decide on the server before minting the key:

import { PryntServer } from '@prynt/node';
const prynt = new PryntServer({ secretKey: process.env.PRYNT_SECRET_KEY });

export async function canCreateKey(user, requestId) {
  const event = await prynt.getEvent(requestId);
  const ss = event.smartSignals || {};
  const hostedNetwork = ss.datacenter?.result || ss.residentialProxy?.result || ss.proxy?.result;
  const siblings = event.accountsOnDevice.accounts.filter(a => a.linkedId !== user.id);

  if (event.decision === 'block') return { ok: false, reason: 'blocked' };
  if (siblings.length >= 3) return { ok: false, reason: 'device_has_many_accounts', siblings };
  if (siblings.length >= 1 && hostedNetwork) return { ok: 'verify', reason: 'shared_device_hosted_ip' };
  return { ok: true, visitorId: event.visitorId };
}

Store the visitorId on the key record. That single column is what lets you answer “which other keys came from this machine?” later.

Act on the cluster, not the key

When a key trips your API-side alarms (quota exhaustion on day one, identical prompt patterns, the shared gateway IP), look up the device that created it and pull every sibling account from accountsOnDevice. Review and act on the cluster together: revoke all keys, freeze free credits, or require a card on file to continue. The operator loses the pool in one move instead of a key at a time.

Report the confirmed abuse back through POST /v1/outcomes. Labeled outcomes feed Prynt’s reputation, so a device you confirmed bad is recognized as a known abuser on its next attempt, and with the opt-in reputation network, devices burned elsewhere arrive already flagged.

Make the next account expensive

Detection is half the job; the other half is choosing friction that farms hate and real developers tolerate:

• One free tier per device. A second account on the same device can exist, but it does not get fresh credits.
• Card or phone verification for accounts that trip a soft signal, before credits unlock.
• Delayed credits. Grant the free quota after a short activity window, which breaks the “sign up, mint key, drain” loop.
• A proof-of-work challenge on signup for high-risk sessions, which raises the cost of scripted creation.

For the broader API abuse picture, including scraping through legitimately issued keys, see stopping API scraping abuse.

Start small

You do not need a fraud team to shut down most key farming. Identify on signup and key creation, link the account, store the visitorId with every key, and cap free tiers per device. Review the devices with the most accounts weekly; the farms will be near the top of that list.