How Tactical detects AI agents
Tactical identifies AI agents in two layers. A deterministic layer matches agents by the name they declare in their user agent and, with a server-side install, checks that the request came from the operator's published IP range. A behavioural layer scores sessions from agent browsers that don't name themselves. The first layer is a lookup; the second is a probability, and we show it as one.
Layer 1: agents that say who they are
Most AI crawlers and fetchers announce themselves: GPTBot, ChatGPT-User, PerplexityBot, ClaudeBot, Google-Extended and so on. Tactical keeps a registry of them (28 entries as of 19 September 2026), each with its operator and a category:
| Category | What it does | Examples |
|---|---|---|
| Training crawler | Collects pages to train models | GPTBot, ClaudeBot, CCBot |
| Search indexer | Builds an AI search index | OAI-SearchBot, PerplexityBot |
| User fetcher | Fetches a page because a person asked an assistant about it | ChatGPT-User, Perplexity-User |
| Browsing agent | Drives a browser on a person's behalf | OpenAI Operator |
A user agent is easy to fake, so where an operator publishes the IP ranges its crawler uses, a server-side install (the WooCommerce plugin, the Cloudflare connection or the Node middleware) checks the request against them and marks the visit verified. The ranges are refreshed nightly. A registry change goes live without waiting for a release of the plugin or the snippet.
Crawlers don't run JavaScript, so a snippet-only install never sees them. That is why the crawler numbers need a server-side install.
Layer 2: agent browsers that don't
An agent browser such as Meta's Muse drives a real browser, and it doesn't have to say it is an agent. For those sessions the snippet sends interaction counters, never content: whether the mouse moved and how often, how the page was scrolled, how regular the time between pages was, whether the browser reports automation, and what the browser environment looks like. Our classifier turns those signals into a score between 0 and 1 for each session, and the score firms up as the session goes on: one page view says little, six say a lot more.
Every session gets a class (agent, human or ambiguous) and a confidence. Where a decision rests on that confidence, it is read in tiers:
| Tier | Meaning |
|---|---|
| Verified | A declared agent whose IP matched its operator's published ranges |
| High | A behavioural score of 0.85 or more |
| Likely | A score from 0.6 to 0.85, or a declared agent we couldn't verify |
| Uncertain | Everything else |
The classifier is rules we can read and test. We try every change against a labelled set of sessions before it ships; a model-based second opinion we evaluated in September 2026 didn't beat the rules on that set, so the rules stay in charge.
Timing
Sessions are classified as their events arrive and reach your dashboard in batches, within about 15 minutes. A crawler visit through a server-side install is identified on the request itself.
What we don't claim
- An accuracy figure. We haven't published one. Our labelled set doesn't yet hold enough sessions from real agent browsers for a number to mean much, and we'd rather say so than print one.
- A Muse fingerprint. No request-layer signature for Meta's Muse is published, and we haven't confirmed a real Muse session on a store. What our September test showed.
- Signed agents. Signed requests (Web Bot Auth) aren't checked yet.
- What agents do elsewhere. Tactical sees your store. It can't see an agent's prompt, the other stores it visited or the prices it compared.
- Certainty about behaviour. A behavioural score can be wrong both ways: a person who only uses the keyboard, or browses through a datacenter VPN, can look automated, and a careful agent can look human. That's why the score is shown as a probability, with its confidence, rather than as a verdict.