How AI platforms detect ban evasion on new accounts
A ban removes an account, not the person or the setup behind it. On an AI platform the strongest evidence that they are back is how the new account uses your API.
AI signup fraud detection and ban evasion prevention start by comparing each new account with the ones you banned. Combine device intelligence, usage fingerprints and account-link analysis across email, card, network and API behaviour. Act when several signals agree.
Ban evasion is a banned person or operation returning on a new account to carry on where they left off. Nearly every page that ranks for it in search is about chat servers, streaming sites or games, and each assumes the person signs in through a web browser. Customers who use only an API key never do, because they call the API from a script or a server. This guide covers that case. Repeat sign-ups for free credits are a related problem with their own guide, how to stop free trial abuse, and both sit under our guide to token fraud.
At a glance
When Anthropic banned a pool of nearly 5,000 accounts it linked to Alibaba, the traffic moved to a second pool, Anthropic reported in September 2026.
Anthropic linked one lab's accounts through "Identical patterns, shared payment methods, and coordinated timing", it said in February 2026.
OpenCode banned one operator's 8,000 accounts on 20 July 2026 and 7,013 more accounts on 11 August 2026. Its builder later described a scheduled job that "finds scammers in our inference data".
A 2022 study of 8,551 banned and returning account pairs on Wikipedia found that new accounts resembled the banned ones in usernames, the pages they edited and what they wrote.
Device fingerprinting products identify "each device visiting your website". A customer who only calls your API with a key never visits it.
Why doesn't a ban stop the person behind the account?
A ban attaches to one account, and a new account costs the person a few minutes and a new email address. The person, their software and their reasons for using your platform all stay the same.
"It works because the original ban applied to the account, not to the person or the device behind it," ShieldLabs, which sells ban evasion detection, writes in its guide. On AI platforms the operations behind abuse plan for bans. Anthropic said in February 2026 that the proxy services it studied run networks of accounts where, once Anthropic bans one, "a new one takes its place."
Its September 2026 report shows the same thing at scale. "When we banned this pool of accounts, Alibaba quickly shifted its traffic through the second pool." In the same report, after banning one influence operation, Anthropic wrote that "We expect the actors behind this activity to try to create new accounts to continue their activity."
Smaller platforms see it too. dax, who builds OpenCode, posted on 20 July 2026 that "we banned someone operating 8,000 fraudulent OpenCode Go accounts". On 11 August OpenCode banned 7,013 more.
Why do device fingerprints miss customers who only use an API key?
A device fingerprint is read by a script that runs in the user's browser when they load your site. A customer who calls your API from a server or a command-line tool never loads a page, so there is nothing to read.
Fingerprint sells device fingerprinting, and its guide to ban evasion describes the method that most ranking pages share. It collects "more than 100 browser and device signals" to produce "a unique, stable visitor ID for each device visiting your website", and checks each new account's visitor ID against banned ones. The method works well on a consumer chat app, where every session runs in a browser or an app.
On an inference platform the browser appears once, when someone signs up and creates a key in your console. An evader can do that from a fresh browser profile on a different machine, then run the same workload as before from the same servers. The device check sees a new visitor, and the API traffic never passes through it.
What do evaders change, and what do they keep?
Evaders change whatever your ban checks looked at, which is usually the email address, card, network address and browser. They tend to keep what their work depends on, such as the code that calls your API, the prompts it sends, the models it picks and the hours it runs.
Fingerprint lists the usual changes. Evaders rotate IP addresses through VPNs and proxies, switch devices, and clear cookies or use private browsing. Each one defeats a check that relies on it alone.
What stays is harder to change, because changing it costs the evader work. In the Wikipedia study by Manoj Niverthi, Gaurav Verma and Srijan Kumar, returning accounts resembled their banned parents in "usernames and edited pages", in the content they added and in its "psycholinguistic attributes". On an AI platform the equivalents are the client library, the request shapes, the system prompts and the task the account keeps asking the model to do.
Which signals carry over from a banned account to a new one?
Five kinds of signal survive a change of email and network often enough to use. None is proof alone, and the strongest links combine a payment or identity signal with a usage signal.
Signal
What carries over
Strength and caveats
Payment instruments
The same card, a card from the same issuer range, the same billing details
Strong when the card repeats. Stripe says its model can "see if a certain card has been used on converted free trials before". Evaders switch to virtual and prepaid cards.
Identity history
Reused email patterns, phone numbers, usernames and the absence of any history
Medium. Returning accounts had similar usernames in the Wikipedia study. A new address with no history is a weak signal alone.
Usage fingerprints
Client library, request sizes, token ratios, rate profile, the endpoints called
Strong for API-only customers, because the same software sends the same traffic. Teams that share an SDK can look alike.
Prompt and model patterns
Repeated system prompts, the same task, the same model choices
Strong. Anthropic found files "reused almost verbatim across hundreds of sessions" in one operation.
Timing
Sign-up soon after a ban, the same active hours, round-the-clock use
Medium. ShieldLabs lists a sign-up "soon after an enforcement action" as a sign of a deliberate return.
Anthropic's February report shows the signals working together. It said DeepSeek "generated synchronized traffic across accounts. Identical patterns, shared payment methods, and coordinated timing" suggested load balancing across accounts. Anthropic also described prompts that arrived "tens of thousands of times across hundreds of coordinated accounts". The prompt text linked accounts that shared nothing else.
US agencies list usage signals of the same kind. Their joint advisory AA26-251A tells AI companies to watch for shared accounts used from many IP addresses and user agents, and for "24/7 sustained usage without human variation/idle periods".
What is a usage fingerprint?
A usage fingerprint is a profile of how an account uses your platform, built from its API traffic, which you can compare with the profiles of accounts you banned. It recognises the workload and the software behind an account instead of the browser it signed up from.
It works on traffic you already have. Your gateway sees each request's size, model, timing, client and token counts, and the shape of those over days is hard to fake without rewriting the software that sends them. OpenCode's builder described a scheduled job on 20 August 2026 that "finds scammers in our inference data". That is the same idea, run from the platform's own logs.
Anthropic describes the same approach for distillation. It has "built several classifiers and behavioural fingerprinting systems designed to identify distillation attack patterns in API traffic." After banning one operation in its September report, it built "detections around its behavioural signatures to stop this from happening again."
How confident should a link be before you act?
Confident enough that a wrong link costs less than a missed one, which usually means two independent signals from different families. A single matching network address or a single similar prompt should start a watch, not a ban.
The research suggests matching works when you already know an evader exists. The Wikipedia study matched returning accounts to their banned parents with a mean reciprocal rank of 0.97, so the right parent almost always came first. It detected evasion early with an AUC of 0.85, which means it ranked a random evading account above a random non-evading one 85% of the time.
Those figures come from a set where every returning account had a parent. On your platform almost every new account is a real customer, so even a good model will flag some of them. Set your thresholds by measuring how many flagged accounts turn out to be real when your team reviews them.
A practical scale:
One weak signal, such as a shared network range. Watch the account.
One strong signal, such as a repeated card or prompt. Limit spend and send the account to review.
Two independent strong signals, such as a repeated card and a matching usage fingerprint. Block, and keep the evidence for any appeal.
What should you do when a new account matches a banned one?
Block at sign-up when the match is strong and the account has not spent anything yet. When the match comes later from usage, limit the account first and map what else it links to before you ban.
Banning one account at a time teaches an operation which details you caught. Anthropic's Alibaba case shows the cost of banning one pool while a second waits. Before you act on a usage match, look for the other accounts that share its card, prompts or timing, and ban them together.
For a single person who returns, a limit is often enough. A new account held to a low spend cap until it builds history costs a real customer little, and costs an evader most of the value of coming back. Operations that resell your tokens are the exception, because they return at scale. Our token resale guide covers them, and our case on Codex subscription resale shows a provider's own detection flagging real users along with resellers.
How do you avoid banning real customers by mistake?
Expect false matches, and design for them before you switch on blocking. Every signal that links an evader also links some innocent pairs, such as colleagues on one company card or students on one campus network.
The common innocent matches on an AI platform:
Teams. Colleagues share a card, a network, an SDK and often a system prompt, so their accounts look like one operation.
Shared networks. Universities, offices and mobile carriers put many users behind few addresses. Fingerprint warns that "legitimate users often share IPs".
Open-source tools. Everyone using the same open-source coding agent sends similar requests with the same client name.
Former customers. Someone banned in error, or banned years ago for something minor, may come back in good faith.
Give every automatic decision a route to a person. A review queue for middle-band matches, an appeal form for blocks, and a record of which signals fired let your team reverse a wrong decision in minutes. Fingerprint's guide calls for "regular analysis of false positives and false negatives", and that means counting how many appeals you uphold every month.
How do you share ban signals across your own products?
Keep one list of banned accounts across every product you run, keyed by the same hashed details. A person banned from your consumer app for resale should match when they sign up to your API under a new email.
Store the card, phone and email details as keyed hashes, so each product can compare them without holding the raw details. Add the usage fingerprint of each banned API account to the same list. A ban in one product then becomes a signal, not an automatic ban, in the others.
What to check on your platform
Start with data you already hold. These checks belong in your review queue:
Repeat cards. Count new accounts in the last 90 days whose card matches a banned account's card.
Return timing. Plot new sign-ups by hours since your last ban wave and look for a spike in the first day.
System prompts. Hash the system prompt on each account's first 100 requests and match the hashes against banned accounts.
Client and model mix. Compare the client names and model choices of new high-spend accounts with those of accounts you banned.
Active hours. Flag new accounts that run round the clock from their first day.
Appeals. Count how many of last quarter's ban appeals you upheld, to see how often your current checks hit real customers.
Where NoResponse fits
Usage fingerprints are built for this problem. A model in your gateway learns how each account uses your platform, compares new accounts with the ones you banned and sends uncertain matches to your review queue. Fingerprints use account and request-pattern signals in your gateway to identify repeat abuse. NoResponse does not make content-safety decisions.
The sign-up check catches returns earlier, before the account's first request. It looks across about 4,000 sites for the email address, username or phone number and returns a risk score with its reasons in about three seconds. Relay intelligence covers 70+ relay and resale services and shows which of your accounts and API keys supply them. If a banned operation comes back at scale, incident support helps your team contain it.
Book a demo to see how many of your recent sign-ups match accounts you have already banned.
Ban evasion is a banned user returning on a new account to keep doing what got them banned. On AI platforms it is often an operation that resells tokens or runs large automated workloads, and it opens new accounts as fast as the platform bans the old ones.
How do AI providers recognise repeat accounts?
They compare new accounts with banned ones on several kinds of signal at once, such as payment details, identity history, timing and how the account uses the API. Anthropic has described linking accounts through shared payment methods, identical traffic patterns and coordinated timing.
Can device fingerprinting catch API-only users?
Only at the moment they use your website, usually to sign up or create a key. Requests sent to your API from a server carry no browser, so recognising those users depends on payment, identity and usage signals.
What is a usage fingerprint?
A usage fingerprint is a profile of how an account uses an AI platform, built from its API traffic, such as request sizes, models, timing and client software. It lets a platform recognise the same workload on a new account after the email and card have changed.
What should I do if a new account matches a banned one?
Block at sign-up if two independent strong signals match. If the match appears later in usage, limit the account, find the other accounts it links to, and act on them together, with a review and appeal route for mistakes.
