Bot Detection

TRACIO's bot detection identifies automated browsers, headless tools, and scripted attacks using a two-layer architecture: client-side collection in the browser agent and server-side analysis. It covers mainstream automation frameworks, headless browsers, AI browsing agents, and antidetect browsers with near-zero false positives, while automatically allowlisting legitimate search-engine crawlers.

What TRACIO detects

• Automation frameworks — Selenium, Puppeteer, Playwright, Cypress, PhantomJS, NightmareJS and similar tooling.
• Headless browsers — headless Chrome and related runtimes.
• AI browsing agents — Browser-Use, Claude Computer Use, Fellou, Genspark, Skyvern and similar agent runtimes.
• Antidetect browsers — browser builds whose purpose is to spoof or rotate the fingerprint.
• Verified crawlers — Googlebot, Bingbot, Applebot, GPTBot, Yandex, DuckDuckGo and others, verified so that a spoofed user-agent does not pass.

How the verdict is produced

The browser agent runs a broad set of checks and reports their outcomes. On the server, the outcomes are weighted into a bot score, and the score maps to a verdict. A small number of unambiguous indicators are decisive on their own and force a bot verdict regardless of the rest.

Which checks run, how they are weighted, and where the thresholds sit are not published — on any plan. Documenting them would tell bot operators exactly what to change to get past the protection. What you receive instead is the verdict, a bot-type label, and — on Business and above — reason codes that name the class of observation behind the decision.

Result format

Every identification carries a bot verdict. It reaches you as bot.result in the webhook payload and as result.bot in the client SDK.

Verdict values

This maps to the business decision.action field (real, fake or suspicious) used across the dashboard and the webhook payload.

bot.score accompanies the verdict. In webhook payload version 2 it is a 0..100 decimal — the same number the dashboard shows for that visit. (In the frozen version 1 schema it is a 0..1 fraction; see Webhooks.)

Bot types

bot.type is present when the result is bot. It is either the name of a recognized bot or runtime, or a family when naming the specific check would reveal detector internals:

The list is closed by design: a check added to the detector tomorrow surfaces as other rather than leaking its internal name. Treat bot.type as a label to branch on, not as an exhaustive enum to validate against — new named runtimes are added over time.

Reason codes (Business and above)

On Business and Enterprise plans the webhook payload carries a reasons array — at most eight entries, sorted by importance. A code names the class of observation, never the check behind it:

severity is high, medium or low, and it is the share of the verdict this class accounts for on this visit — not a fixed property of the code. The same code can arrive as high on one visit and low on another, so don't cache it as a constant.

privacy_hardening deserves particular care: it fires for ordinary privacy-conscious visitors as much as for evasion. Weigh it together with the rest rather than acting on it alone.

virtual_environment comes from emulator detection. There is no separate "running under a hypervisor" verdict on web: the clues a browser can see — a generic software renderer, an unusually low core count — appear just as often on ordinary machines with no GPU driver and inside remote-desktop sessions, so we do not turn them into a verdict you would have to second-guess.

Availability by plan

Antidetect scoring is still being calibrated. bot.antidetectScore is reported so you can observe it and tune your own policy — treat it as an input to your risk decision rather than as a standalone reason to block.

Mobile-only checks are not effective on web. Root, jailbreak, cloned/dual-app and Frida detection depend on native signals that a browser cannot collect. TRACIO ships browser SDKs only, so rely on the automation, headless, AI-agent, antidetect, emulator and behavioral verdicts, which are fully active on web.

Verified crawlers

Known good bots are recognized by their user-agent and then verified against the connecting IP — a reverse DNS lookup on the IP, a check that the resulting hostname belongs to the operator's domain, and a forward lookup confirming it resolves back to the same IP. This is the verification procedure the crawler operators themselves publish.

A verified crawler resolves to human. A request that claims to be Googlebot while its IP demonstrably belongs to someone else is classified as a bot — a merely missing or timed-out lookup is not treated as proof of spoofing.

Behavioral analysis

Interaction dynamics — pointer movement, keyboard cadence, scrolling — feed the verdict as evidence of whether a human is present, not of which human it is. On Business and above the aggregate is delivered in the webhook behavior block:

{
  "behavior": {
    "score": 87,
    "verdict": "human",
    "confidence": 0.92
  }
}

score runs 0..100 (higher = more human), verdict is human, uncertain or bot, and confidence (0..1) says how much evidence the verdict rests on — a short visit with two pointer movements scores low here even when the verdict looks decisive.

The block is present only when behavioral scoring actually ran for that visit. A missing block means "no data", never "nothing suspicious" — do not read its absence as a clean signal.

Integration examples

Blocking bots at login (client)

The client SDK exposes a convenience boolean, result.bot.detected, plus a confidence on a 0..100 scale:

const result = await tracio.getResult()

if (result.bot.detected) {
  console.warn(`Bot detected (confidence ${result.bot.confidence})`)
  showCaptcha()
  return
}

await login(credentials)

Server-side bot check

On your server, act on the webhook delivery. The bot verdict lives in the bot object — bot.result and bot.type:

// `event` is the webhook delivery body (/docs/webhooks)
app.post("/webhook/tracio", async (req, res) => {
  const event = req.body

  if (event.bot?.result === "bot") {
    await db.blockedRequests.insert({
      visitorId: event.visitorId,
      botType: event.bot.type,
      ip: event.ip,
      timestamp: new Date(),
    })
  }

  res.status(200).send("OK")
})

Zero and empty values are omitted from the payload, so read bot.type defensively rather than requiring it in your schema.

False positive handling

TRACIO's bot detection is designed for near-zero false positives, but edge cases exist:

If you see false positives, review bot.type (and reasons on Business and above) to understand which class of observation fired, then adjust your policy. See Troubleshooting for the common causes.