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.

AI agents

Agentic browsers and automation frameworks run in a clean environment and look like a person on the wire. What gives them away is how their input arrives: pointer jumps, clicks on the exact center of a target, keys with no time between them, text that appears without typing, or input delivered to a tab that is not visible. The web SDK observes how input arrives on the page and sends only timing and geometry aggregates with each evaluation. It never sends what was typed, the contents of a field, or the path the pointer took.

Every evaluation carries an agent object with the result:

{
  "agent": {
    "classification": "ai_agent",
    "name": "Claude in Chrome"
  }
}

• human: the input looks like a person. Signals that people also produce, such as an assistive technology click or a password manager filling a field, never decide this on their own.
• ai_agent: an agent product drove the browser, such as Claude in Chrome, Comet or the ChatGPT browser extension, or the request declared an agent identity. Agents that run their own cloud browser and declare nothing, such as Meta's Muse, are recognised from the environment that browser presents. name says which, and operator who runs it.
• automation: a script or a driver drove the browser and nothing identifies it as an agent. name is set when the framework left a trace, such as Puppeteer or Selenium.

Two booleans say how the identity is known:

• declared: the request carried an agent identity, as a Web Bot Auth signature, an agent header or a user agent token. A declaration is a claim anyone can make.
• verified: the signature checked out against the key directory the operator publishes. Only operators that sign (ChatGPT agent, Google-Agent, Browserbase, Anchor, Amazon Bedrock AgentCore, Cloudflare Browser Run, Kernel, Manus and a few more) can be verified. A signature that fails, or that is replayed, classifies the visitor as automation with declared true and verified false.

When there is nothing to judge, the evaluation has no agent object. That is the normal case for an access evaluation at page load, before any form has been filled.

Policies match on it with the visitor condition, so a rule can challenge automation while letting agents through, or the reverse. visitor_declared and visitor_verified match the two booleans, which is how a policy lets verified agents in and challenges the rest.

If the SDK runs behind your own domain (a proxy), the Host header must reach Rupt unchanged. A signature covers the authority the agent sent the request to, and rewriting it fails every verification.

The classification reads the interaction since the previous evaluation on the page, so the login or signup evaluation at submit carries the form fill that decides it. Construct the SDK at page load rather than right before calling evaluate, or there is nothing to observe.

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.