Bots

Bots are automated, non-human traffic: scripts driving a real browser, headless engines, or full automation frameworks pretending to be human. They show up across every fraud surface: signup farms, credential stuffing, scraping, payment testing.

How Rupt detects bots

Bot detection runs entirely off signals: a mix of behavioral, cryptographic, and platform probes weighed together. No single tell is decisive; the score comes from how many line up at once.

A few illustrative examples:

• A browser that openly reports it's being driven by automation.
• Automation frameworks that leave traces in the page environment.
• Interactions that were dispatched by code rather than a real person.
• Headless-browser giveaways: rendering and hardware details that don't match a real screen.

That's a sample, not the full set. The complete list is deliberately unpublished, since a public checklist is just an evasion guide. Rupt weighs the indicators together into the bot risk category.

Observation-only by default

The bot risk is observation-only: Rupt records the score on every evaluation but doesn't use it to choose a verdict. This is deliberate: bot policy is product-specific. A scraping API wants to block every bot; a search-engine-friendly site wants crawlers to pass.

For now, read the bot score off the evaluation and act on it in your own logic. Matching a policy on the bot risk directly is coming soon. In the meantime, the checks that policies can match catch a lot of automated traffic on their own: ip_is_hosting in particular gates most cloud-run bots.

Pairs well with

• tampering: bots that try to disguise themselves usually trip tampering checks too.
• Hosting IPs: the most aggressive bots run from cloud infrastructure, so ip_is_hosting tends to fire alongside a high bot score.
• anti_fingerprinting: bots that layer anti-fingerprinting tooling surface through the anti_fingerprinting risk.