Detecting Account Farming on AI APIs With Device and Network Signals

An account is a row in a database. A device is a physical object someone paid for.

That asymmetry is the whole basis of device-level abuse detection, and it is why a farming operation that can generate 20,000 accounts for free cannot generate 20,000 devices for free. Somewhere underneath the account layer there is a finite pool of real hardware, real network paths, and a set of tricks used to make that small pool look large.

Those tricks have signatures. This post is a walk through the ones Didit's device and network analysis emits, what each one actually means, and how to weight them — for $0.03 per check, or bundled into the $0.33 full verification.

Key takeaways

• Farming operations reuse a small physical substrate behind a large account surface. The reuse is detectable.
• Three signal families matter: duplication (same device or address, more than once), integrity (this is not a normal client), and network (this path is not what it claims to be).
• DEVICE_RECOVERED_HIGH_CONFIDENCE is the highest-value single code for this problem — it catches a device coming back after a wipe, which is the standard regeneration move.
• Integrity codes like AUTOMATION_FRAMEWORK_DETECTED and DEVICE_EMULATOR_DETECTED are strong on their own. Duplication codes are weak on their own and need corroboration.
• Warning actions are configurable per code — decline, review, or record — so the escalation ladder is yours.
• $0.03 per check standalone; included in the $0.33 verification bundle.

The three signal families

Duplication — have I seen this before?

Code	Meaning
DUPLICATED_DEVICE_FINGERPRINT	The same device appears behind more than one verification
DUPLICATED_IP_ADDRESS	The same address appears behind more than one verification
DEVICE_RECOVERED_HIGH_CONFIDENCE	A previously seen device returning after a reset or reinstall
EXPECTED_IP_ADDRESS_MISMATCH	The address differs from the one expected for this session

Didit draws an explicit distinction between a duplicated device and a recovered device, and the difference is the interesting part.

A duplicated device is two verifications from the same device — common, often innocent. A family tablet. A shared workstation. A support agent helping a user through a flow.

A recovered device is a device that was wiped, reset, or had the application reinstalled, and has now come back. Didit still recognises it.

For account farming, that second case is the money signal. The standard operating procedure after a ban is to reset the device and register again — that is precisely what makes a hydra network regenerate faster than it is pruned. DEVICE_RECOVERED_HIGH_CONFIDENCE on a brand-new account says: this hardware has been here before, under a different account, and someone went to the trouble of trying to erase that. Almost nothing legitimate produces that combination on a first verification.

Integrity — is this a normal client?

Code	Meaning
AUTOMATION_FRAMEWORK_DETECTED	The client is being driven by automation, not a person
DEVICE_EMULATOR_DETECTED	An emulated device rather than real hardware
DEVICE_ROOTED_OR_JAILBROKEN	The operating system's security model has been removed
DEVICE_RUNTIME_HOOKING_DETECTED	Runtime instrumentation is attached to the process
DEVICE_APP_TAMPERED	The application binary has been modified
DEVICE_DEBUGGER_ATTACHED	A debugger is attached
DEVICE_INTEGRITY_SIGNALS_MISSING	Expected integrity signals are absent

This family is qualitatively different from duplication, and it is worth being clear about why: these codes describe intent.

DUPLICATED_IP_ADDRESS can happen to anyone at a university. AUTOMATION_FRAMEWORK_DETECTED on a verification flow means someone is driving an identity check with a script. DEVICE_EMULATOR_DETECTED means the "phone" completing your check is software running on a server — the cheapest way to make one machine look like a hundred. DEVICE_APP_TAMPERED means the client binary has been modified, which is what you do when you want it to report things that are not true.

Emulator farms and automation frameworks are the industrial tooling of account farming. When they appear on a verification, the innocent explanation is thin.

DEVICE_INTEGRITY_SIGNALS_MISSING is the subtle one. It does not say anything is wrong — it says the signals that would tell you nothing is wrong did not arrive. Treat absence as a weak negative rather than a neutral, because suppressing telemetry is itself a technique.

Network — is this path what it claims to be?

Code	Meaning
PRIVATE_NETWORK_DETECTED	A private or anonymising network path
COUNTRY_FROM_DOCUMENT_DOES_NOT_MATCH_COUNTRY_FROM_IP	Document and network geography disagree
IP_LOCATION_NOT_ALLOWED	The location falls outside your configured policy
IP_ADDRESS_IN_BLOCKLIST / IP_ADDRESS_IN_ALLOWLIST	The address matched one of your lists
DEVICE_FINGERPRINT_IN_BLOCKLIST / DEVICE_FINGERPRINT_IN_ALLOWLIST	The device matched one of your lists
LOCATION / NO_ACTION	Informational

Network signals are the weakest family and should be weighted accordingly. Privacy-conscious developers use anonymising networks routinely, and the population of an AI API is more technical than average — a higher baseline rate of private network usage is expected, not suspicious.

COUNTRY_FROM_DOCUMENT_DOES_NOT_MATCH_COUNTRY_FROM_IP is more useful than raw geography because it is a contradiction rather than a location. People travel and people relocate, so it is not damning on its own, but combined with a duplication signal it sharpens considerably.

The blocklist and allowlist codes are the enforcement half — covered in depth in the post on blocklist propagation.

Weighting: what is strong, what is weak

The most common implementation mistake is treating every warning as equivalent. They are not remotely equivalent.

Strong on their own — reasonable basis to decline or hard-review:

DEVICE_EMULATOR_DETECTED · AUTOMATION_FRAMEWORK_DETECTED · DEVICE_APP_TAMPERED · DEVICE_RUNTIME_HOOKING_DETECTED · IP_ADDRESS_IN_BLOCKLIST · DEVICE_FINGERPRINT_IN_BLOCKLIST

Strong in context — escalate when combined with anything else:

DEVICE_RECOVERED_HIGH_CONFIDENCE · DEVICE_ROOTED_OR_JAILBROKEN · COUNTRY_FROM_DOCUMENT_DOES_NOT_MATCH_COUNTRY_FROM_IP

Weak alone — corroborate before acting:

DUPLICATED_IP_ADDRESS · PRIVATE_NETWORK_DETECTED · DUPLICATED_DEVICE_FINGERPRINT · DEVICE_INTEGRITY_SIGNALS_MISSING

The pattern is consistent: codes describing deliberate manipulation of the client are strong; codes describing shared resources are weak. Shared resources have thousands of innocent explanations. A modified binary does not.

Configuring the response

Warning actions are configurable per code, so you can build a real escalation ladder rather than a single pass/fail gate.

A workable default for an AI API:

• Decline on DEVICE_APP_TAMPERED, DEVICE_EMULATOR_DETECTED, AUTOMATION_FRAMEWORK_DETECTED, and any blocklist hit. A blocklist match forces a decline by design.
• Review on DEVICE_RECOVERED_HIGH_CONFIDENCE and on DEVICE_ROOTED_OR_JAILBROKEN.
• Record only on DUPLICATED_IP_ADDRESS, PRIVATE_NETWORK_DETECTED and LOCATION — capture them for correlation, but never act on them alone.

The recorded-only codes are not wasted. They are what make an investigation possible six weeks later when your traffic layer flags an account and you need to know what else it touches. Collecting them at the cheapest tier, as described in the risk-tiered access architecture, is what makes later correlation work at all.

Reading the signals in a session

Device and network results arrive with the session decision:

curl -X GET 'https://verification.didit.me/v3/session/{sessionId}/decision/' \
  -H 'x-api-key: YOUR_API_KEY'

Route on warnings, not just on the top-level status. An approved session carrying DUPLICATED_DEVICE_FINGERPRINT and DEVICE_RECOVERED_HIGH_CONFIDENCE is approved and worth a closer look — and if you only read the status you will never know.

Didit also surfaces cross-session matches, which is how you get from a single warning to the set of other sessions sharing that device or address. That is the pivot from one account to a cluster.

Use cases

AI API platforms collecting device and network signals at the cheapest paid tier so that correlation data exists before it is needed.

Free-trial and credit programmes where emulator farms are the dominant abuse vector and DEVICE_EMULATOR_DETECTED alone removes most of the volume.

Marketplaces and gig platforms detecting removed sellers or couriers returning on wiped hardware.

iGaming enforcing single-account rules and self-exclusion, where device recovery is the standard evasion.

Frequently asked questions

Does this work on web, or only in mobile apps?

Both. The depth of the integrity signals is greater on native mobile, where the operating system exposes more — codes like DEVICE_ROOTED_OR_JAILBROKEN and DEVICE_APP_TAMPERED are native-app concepts. Web sessions still produce network and device-correlation signals.

Can a determined attacker defeat device fingerprinting?

Yes, partially — that is why it is one family among several rather than the whole answer. The goal is not perfect identification, it is cost. Each layer of evasion an operator adds costs them money and engineering time, and evasion tooling itself trips integrity codes. An attacker who has defeated device fingerprinting is usually visible in one of the other signal families.

What does $0.03 actually buy?

One IP and device analysis check on one session, returning the full warning catalogue. It is billed per successful check with no minimum, and it is already included when you run the $0.33 full verification bundle.

Is a private network signal enough to decline?

No, and declining on it will cost you real developers. On a technical audience, anonymising networks are ordinary. Record it and use it as corroboration.

How does this relate to detecting distillation in traffic?

It does not detect distillation. Device and network signals tell you about the client and the account, never about the content of your API traffic. Semantic detection is a separate layer that lives in your own stack. These signals tell you how many accounts an operator is running; your traffic layer tells you what they are doing with them.

Ready to get started?

Device and network analysis is a single check on any verification session.

• Read the docs — IP & Device Analysis overview and the full warning catalogue.
• See the product — User Verification.
• Check the pricing — $0.03 per check, included in the $0.33 bundle, no minimums.
• Start free — business.didit.me, 500 KYC verifications a month at no cost.