Traditional Bot Detection Is Broken. What's Actually Working Now?

Bot detection on a SaaS signup form used to mean a CAPTCHA plus a honeypot field. Most of what gets through now is a real browser driven by a script or an AI agent, often on a residential IP, and it fills the form the way a person would.

Cloudflare said this summer that automated traffic is now more than half of all web requests. On a signup form that shows up as spam signups that never activate, bounced welcome emails, free credits burned by accounts nobody owns, and an activation rate that looks worse than it is.

Here's where each standard fix breaks: CAPTCHA reliably stops your real users on a phone. Honeypot fields don't catch headless browsers that render the page properly. Rate limits by IP catch a university but miss a residential proxy service. Email verification proves someone controls an inbox, not that a person is behind the signup.

And there's a new wrinkle: not every bot is bad anymore. Some of these are AI agents a real customer sent to sign up or book something for them. "Block all bots" used to be the safe default. Now it can mean turning away a paying user who just delegated the task.

So, for anyone running a signup form: what finally cut spam signups for you, and what was the first sign bots were getting in? Do you add friction for everyone or only when something looks off? And do you let AI agents sign up on behalf of real users?

Comments

[Furqan Ashraf]

Friction only when something looks off. The catch is that "looks off" has to be cheap enough to compute at submit time, before the welcome email goes out, because a bounce is a lagging signal and by then the credits are gone.

The order I'd try:

1. Hold the free credits until the first real action. Farmed accounts rarely get that far, so the payoff disappears even when detection misses.
2. Ask what the IP is, not how often it shows up. Your university vs residential proxy example is where per-IP counting fails in both directions. A lookup that says "VPN exit", "residential proxy", "Tor" or "cloud host" lets you challenge those and let the campus NAT through untouched.
3. Give agents their own lane. Many hosted agents run from cloud IPs, so a cloud-provider flag plus an email magic link (instead of a CAPTCHA) keeps the delegated signups working while you watch whether they activate.

For step 2, full disclosure, I'm on the team at IPGeolocation.io. Our IP Security API returns those flags along with a 0 to 100 threat score, and the docs list every field: IPGeolocation.io/documentation/ip-security-api.html

It's on paid plans only, so if you're pre-revenue a free datacenter ASN list plus a disposable-email check gets you part of the way.

None of this catches a real browser on a clean home connection. That's where the behavior signals you mentioned earn their keep.

[Mohith kumar]

Good overview of why CAPTCHA plus a honeypot stopped being enough. From building chatform.in I'd add that the form's shape matters: a multi-step conversational flow gives more behavioural signal per submission than a single POST, since each answer has its own timing and context. Have you seen LLM-driven bots get through multi-step flows yet?

[IP99]

Residential IPs break a lot of CAPTCHA-first heuristics. We've had better luck treating proxy/VPN/dial-up-pool evidence as time-bounded rather than a permanent label, and combining that with shared-exit context so you don't ban a whole CGNAT range for one bad actor.

We open-sourced the lookup shape at IP99 (ip99.com) if useful as a second opinion next to your bot signals — free tier, no key: curl ip99.com/v1/ip/8.8.8.8