Updated 16 September 2026
01 · why validation cannot catch this
Why validation cannot catch this
A signup form checks that an address is well-formed, that a password meets a policy, and perhaps that the address is not on a disposable-domain list. A script filling that form satisfies all three, because those are properties of the data and the data is real.
The usual next step is a CAPTCHA, which moves the contest from whether the data is plausible to whether the submitter is human. That helps, and it has two known costs: solving services price a bypass in fractions of a cent, and every legitimate person pays the friction whether or not anyone was ever going to attack the form.
Email confirmation is the third layer, and it filters exactly the accounts that never needed a working inbox. An operation farming free-tier resources or seeding a forum has one.
02 · what the request says that the form does not
What the request says that the form does not
- 1 Whether the form was loaded at all. A submission that arrives without the page it belongs to having been fetched did not come from somebody reading it.
- 2 How long the form was open. A person reads labels and types; a script posts. The distribution of those two is not the same shape.
- 3 Where the submission came from, and whether that address has been submitting forms elsewhere on the same site.
- 4 Whether the client is what it claims. The same handshake mismatch that names an automated browser names an automated signup.
- 5 Whether many registrations share one fingerprint. Individually unremarkable accounts that were all created by the same client are the pattern that field validation structurally cannot see.
03 · automation tooling the catalogue names
Automation tooling the catalogue names
| Bot | Operator | Default policy | Verifiable |
|---|---|---|---|
| GoogleAgent-Mariner | Google DeepMind | Observe | By user agent |
| Manus-User | Butterfly Effect | Observe | By user agent |
| AccessibleWebBot | Accessible Web | Allow | By user agent |
| Acunetix | Invicti Security | Challenge | By user agent |
| AITrustRadar | AI Trust Radar | Allow | By user agent |
| AliyunSecBot | Alibaba | Allow | By user agent |
| Arachnid Shield API | Canadian Centre for Child Protection | Allow | Signed requests |
| Black Duck Fast Dynamic | Black Duck | Allow | By user agent |
| BlackVeil-Security-Scanner | BlackVeil | Allow | By user agent |
| Blockaid | Blockaid | Allow | By user agent |
| Bushbaby | Cloudflare | Allow | By user agent |
| CensysInspect | Censys | Observe | By user agent |
Read live from the Botscope crawler catalogue. Default policy is the catalogue default; every agent can be overridden per site.
04 · what this does not do
What this does not do
Botscope classifies the request, not the person. It cannot tell you that an account is fraudulent, only that the request which created it was automated, and those are different claims — a legitimate customer scripting their own onboarding produces the first signal without the second being true.
It also does not read the form. Addresses, names and passwords are not visible to it, which rules out the checks that depend on them and is the reason the signals above are all about the request.
Most spam registration traffic carries no name, so the table above is the named minority rather than the population. The classification does not depend on a name being present.
Questions
Do I still need email confirmation?
Yes. It filters accounts created without a working inbox, which is a different population from accounts created by a script. Both layers remove something the other keeps.
Can I keep my CAPTCHA?
Yes, and many sites reduce how often it is shown instead of removing it — asking only the requests that already look automated, so the rest of the queue is not charged friction for them.
What if a real customer automates their own signup?
They are classified as automated, correctly, and whether that is allowed is your policy rather than ours. The record shows which signal applied, so an exemption can be written against something specific.
Does this work without JavaScript on the form?
The connection-level and behavioural signals apply either way. The browser-reported ones need the page’s script to have run, so a form that loads none has fewer signals available.
Can I see this before enforcing anything?
That is the default. Observation mode classifies submissions and blocks nothing, which on a signup form is the sensible order.
See which of these reach your site
Free plan, no card: 100,000 events a month with every feature on. Nothing is blocked until you turn enforcement on.