One agent. A thousand accounts. See it as one.
Cloud agents run in persistent virtual machines and rotate through the same home and mobile IPs your customers use. Arkose Agent ID persists inside the machine, so one agent opening many accounts shows up as one agent, however many networks it passes through.
Botnet architecture, built from consumer tools.
A fake account used to need a device, a proxy and a person or a script to run it. Now one operator can hand the work to a lead agent that spawns sub-agents, each with its own free account, each on its own cloud machine, each looking like a different customer on a different home connection.
The same agent products your customers use are the raw material. Add an open-weight agent model with the fraud guardrails stripped, and the cost of running a thousand accounts falls to the cost of the prompts.
We see the building blocks on the network today: single agent instances opening dozens of accounts, sign-ups arriving at oddly flat, steady daily rates, and swarms of free accounts working promo and referral programs. Coordinated swarms at scale are the next step, and the time to be able to see them is before they arrive.
The network rotates. The fingerprint is templated. Neither tells you who is behind it.
Residential proxies are the default.
Agent traffic now exits through home and mobile ISPs, the same pools that carry abuse. One agent device hopped between two ISPs in six minutes. Network origin is context, not identity.
Templated machines look alike.
Agent VMs are built from the same image, so fingerprint clustering merges separate users into one cluster and splits one agent across many. Keying on fingerprint gets the groups wrong in both directions.
Every account checks out on its own.
Each sub-agent holds valid credentials, clears the one-time code and behaves like a customer. Account by account, nothing is wrong. The signal is in the count.
A stable handle on each agent.
Cloud agents run in persistent virtual machines. Arkose Agent ID persists inside them, so the network can rotate from one residential ISP to another to cloud egress while the Agent ID stays the same. When an agent ships a new build, its Agent IDs often carry over, which links an unknown variant back to a known agent so new builds don't start from zero.
Why this matters: IP and fingerprint rules break when agents rotate networks. Agent ID gives you a stable handle on each one.
Count accounts per agent. Act on one agent, not all.
Spot account farms.
Flag agent devices that create or log in to too many accounts.
Recognize returning agents.
A customer's own agent on a new network is not a takeover. Agent ID keeps it recognized instead of misread.
Act on one agent, not all.
Restrict one misbehaving agent while other users of the same product carry on.
Follow the journey.
Link an agent's login, checkout and recovery attempts into one view.
Keep separate users separate.
Keyed on the stateful ID, not fingerprint clusters, so templated machines don't merge real customers.
Raise the cost of running a thousand agents.
Proof of work runs a small computation on the device, timed against the hardware it claims to be. Real users never see it. An operator running a thousand cloud machines pays for it a thousand times, and a machine that finishes at the wrong speed for its claimed GPU gives itself away. Pair it with challenges built and benchmarked against frontier models, and automation at scale stops being free.
See it before you decide.
Two lines of script in the page head. Within 7 days, see which agents are already in your flows, how often, and their share of traffic. Then decide what each one may do.
Frequently asked questions
Is this the same as a bot farm?
Same goal, different machinery. A bot farm scripts a browser. An agent swarm runs real agent products in real cloud machines, with human-like behavior and valid credentials, and the hardest ones to catch are built from the same tools your customers use.
How is this different from a human fraud farm?
A human fraud farm pays people to do the work. An agent swarm pays for compute. The two are converging: solver farms already replay human biometrics, and agents already pass behavioral checks. Arkose treats both as the same problem, many accounts behind one operator, and uses the same identity and compute signals to tie them together.
Do I need to block agents to stop swarms?
No. Agent ID counts accounts per agent, so you can set a threshold and act on the agents that cross it while the rest carry on. Policy is per agent and per step, not all or nothing.
See the operator, not the accounts.
Arkose Titan ties every account an agent touches back to the agent, and lets you decide what that agent may do.
