A session arrives in a real Chromium build, with a real fingerprint and a logged-in user’s cookies, and a model is doing the driving. Whether that session is welcome depends almost entirely on whether the user authorized it. AI agent detection is bot detection under that condition: identify the agent, attribute it to a user or to nobody, and act on that, ideally without blocking the legitimate agents and without letting unauthorized agentic traffic harvest your product. The 2026 landscape is messier than the 2024 landscape, and the right posture is no longer “block all automation.”

If you are not already familiar with the broader bot detection picture, bot detection is the parent post and bot management covers the policy side.

Data Where AI bot traffic actually goes on your site
Touches a form 64%
Touches a login page 23%
Reaches a checkout flow 5%
Source: DataDome 2025 Global Bot Security Report

Most readers assume AI bots only scrape content. They also fill in forms, hit login pages, and reach checkout, which is why "block all automation" is the wrong posture even on routes you would never expect agentic traffic to touch.

The 2026 agentic browser landscape

There are now five categories of AI agent traffic worth distinguishing, because they need different handling.

1. Identified AI crawlers

The traditional sense of the word: GPTBot, ChatGPT-User, OAI-SearchBot, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Amazonbot, CCBot, Bytespider and a growing list. Each operator publishes its purpose, a User-Agent string, and (for the better-behaved) a JSON IP range file you can use for verification (No Hacks: The AI User-Agent Landscape in 2026).

Detection here is straightforward in principle: check the User-Agent, look up the source IP in the published range, and you have a verified identification. The hard part is that there are dozens of these now and the verification mechanism differs per operator.

2. AI agents in cloud-hosted browser sessions

OpenAI’s Operator, Browserbase-hosted sessions, Anthropic Computer Use running in a hosted container, Google Project Mariner. The agent reasons in the cloud and drives a cloud-hosted Chromium instance over the web.

These are easier to detect than local agents because:

  • The Chromium instance is in a datacenter ASN.
  • The browser sometimes has identifiable framework signals (Browserbase ships a slightly different User-Agent per session, sometimes coherent and sometimes deceptive, as Stytch’s research has documented; Stytch: Detecting AI agent use & abuse).
  • The TLS fingerprint and HTTP/2 settings often differ from real consumer Chrome.
  • Google Project Mariner specifically identifies itself with the Google-Agent User-Agent in 2026 (No Hacks: Agentic Browser Landscape).

3. AI agents in locally-run browsers

Anthropic Computer Use running on a user’s laptop, OpenAI Operator running through a local browser extension, Browser Use running locally, and a long tail of open-source agentic frameworks. The agent drives a normal local Chrome with the user’s normal session cookies, local IP, and local fingerprint.

These are the hardest to detect because every infrastructure signal looks like a real user. The agent’s presence shows up only in browser-level behavioral signals and in framework-specific tells.

4. Vision-based agents

Anthropic Computer Use, OpenAI Operator and Browserbase’s Open Operator all support a vision-first interaction mode: the agent takes a screenshot, reasons about what it sees, and decides where to click in pixel coordinates. They do not parse the DOM or run scripts in the page context.

This sounds like a strength but is a detection opportunity. Vision agents are blind between screenshots. They do not respond to fast page changes, popovers that auto-dismiss, or events that fire in JavaScript only. Behavioral analysis that watches the rhythm of click-then-screenshot-then-click can identify them (WebDecoy: Detecting Vision-Based AI Agents).

5. Signed agents via Web Bot Auth

A small but growing population of agents now cryptographically sign their requests using HTTP Message Signatures (RFC 9421). Cloudflare proposed and is operating Web Bot Auth; Anthropic and OpenAI are early adopters on the agent side (Cloudflare: Forget IPs, using cryptography to verify bot and agent traffic). A signed agent presents Signature-Input and Signature HTTP headers; the server verifies against the agent’s published public key. The agent is identified cryptographically rather than by IP or User-Agent string.

This is the category to encourage because it makes the rest of the detection problem easier. An agent that wants to be a good actor can prove its identity. The signed-request format and the policy treatment of signed agents are covered in more depth in bot management.

What detection looks like per category

The detection signals stack differently for each category. The right architecture is to classify into the categories first, then apply the appropriate downstream logic.

Identified crawlers (category 1)

The check chain:

  1. User-Agent matches a known crawler string.
  2. Source IP appears in the operator’s published IP range JSON.
  3. Reverse DNS resolves to the operator’s domain (where applicable).

If all three match, the request is verified. If the User-Agent matches but the IP does not, it is a spoofed crawler. Block.

The operators that publish IP ranges as of 2026 include OpenAI (separate files per bot: gptbot.json, searchbot.json, chatgpt-user.json), Google (the Googlebot ranges plus the new Google-Extended ranges), Bing, Perplexity, and Common Crawl. Anthropic’s verification approach uses reverse DNS rather than published IP ranges.

Cloud-hosted agents (category 2)

The check chain:

  1. Source IP is in a hosting ASN (AWS, GCP, Azure, OVH, Hetzner, DigitalOcean, Cloudflare Workers, Vercel).
  2. Framework-specific tells: Browserbase’s User-Agent variation pattern, Operator-specific Client Hints, Anthropic-hosted session identifiers.
  3. TLS fingerprint matches the framework’s distribution rather than a real consumer browser distribution.

If all three converge, the session is a cloud-hosted agent. The verdict is then sub-classified by which framework, because some are signed and some are not.

Locally-run agents (category 3)

This is the hard case because the infrastructure looks like a real user. Detection relies on:

  1. Framework-specific browser-environment tells. Browser Use’s specific evaluate hooks. Computer Use’s specific tab-management patterns. Local Operator builds have characteristic webdriver-flag handling.
  2. Behavioral patterns. Agent-driven interaction has different timing distributions from human-driven interaction. The pause between perceiving the page and acting is characteristically longer and more uniform.
  3. Session-level patterns. Agents read pages more quickly than humans, click links in patterns consistent with a goal rather than browsing, and rarely backtrack.

The detection is probabilistic. A confident identification requires the joint signal across all three categories.

Vision agents (category 4)

The vision-blindness creates specific signals:

  1. The agent waits a characteristic 500 to 2000 ms between screenshot and click as the model reasons.
  2. The agent does not react to popovers that appear and disappear faster than its screenshot cycle.
  3. The agent’s click coordinates land in the middle of clickable elements at a higher rate than human users (who often click near the edge).
  4. The agent does not produce mouse-move events between clicks; cursors teleport.

A behavioral classifier trained on these can identify vision agents with high confidence.

Signed agents (category 5)

The check chain:

  1. Request includes a Signature-Input and Signature header.
  2. Resolve the Signature-Agent URI to find the agent’s metadata and public key.
  3. Verify the signature against the request URI and creation timestamp.
  4. Check the agent’s identity against the per-route allow-list.

A valid signature plus an allowed agent identity is the cleanest verification possible. The signature is per-request and includes a creation/expires window, so replay is bounded.

Why “block all agents” is the wrong default

In 2024 the default policy for many sites was to treat any automation as hostile. Many products are still mid-shift away from that posture, and reasonably so, but it increasingly fails to reflect how they are being used:

  • A growing share of legitimate users are arriving via authorized agents (a user asking Claude to summarize a paywalled article they have access to, a user asking Operator to book a flight, a user asking Browser Use to fill in a form they would rather not fill in by hand).
  • Search and discovery is shifting from Google to AI answer engines for a non-trivial fraction of users; refusing to be crawled by AI engines reduces traffic from those engines.
  • The line between “browser automation” and “browser automation on behalf of a user with permission” is increasingly meaningful.

The mature policy is to classify every agent (which framework, identified or unidentified, signed or unsigned) and attribute every action to either an authorized user account or a public anonymous context. The decision tree is then:

  1. Verified-identified crawler with published purpose -> allow (per per-route policy) with throttling.
  2. Signed agent (Web Bot Auth) with an allowed identity -> allow.
  3. Cloud-hosted unidentified agent attached to a logged-in user with recent step-up -> allow.
  4. Cloud-hosted unidentified agent attached to no user -> challenge or block per route.
  5. Locally-run agent with framework signature, attached to a logged-in user -> allow with logging.
  6. Locally-run agent with framework signature, no user -> the same posture as anonymous browser traffic.
  7. Vision agent on a high-trust route (checkout, signup) -> require step-up regardless of session attachment.

Different products will pick different rules. The common thread is that automation alone no longer decides the outcome; classification and attribution do. And where the answer is “challenge,” the challenge should be one an authorized agent or its user can actually pass (proof-of-work, or step-up to the owning account) rather than a legacy image CAPTCHA; see CAPTCHA alternatives.

Account attachment is half the answer

For agentic traffic, the most useful question to answer at the API boundary is: is this session attached to a known user account and was that user recently active in a way that suggests they authorized this agent?

The signals for that:

  • The session cookie or auth header maps to an account.
  • The account had a human-driven login within a recent window (less than 60 minutes for high-trust actions, longer for low-trust).
  • The account’s normal device fingerprint matches the current session.
  • The action being requested is consistent with the user’s history.

A session that fails all four of these is anonymous, regardless of whether it looks human or agentic. A session that passes all four is high-trust regardless of whether the active driver is a human or an authorized agent.

This is the architecture the major financial and e-commerce platforms are converging on: identity is what matters, and agency is treated as a property of the identity rather than a replacement for it.

What the SDK has to collect

A bot detection SDK that wants to handle agents has to collect everything it already collected for bots, plus:

  • HTTP message signatures (Web Bot Auth headers).
  • Framework-specific browser tells for each known agentic framework.
  • Vision-agent behavioral signals (click-coordinate distributions, click timing relative to screenshot intervals).
  • Session-attachment metadata: which account, when did they last authenticate as a human, how does the current device fingerprint compare to known.

The Foil SDK collects all of these, and agent traffic surfaces through attribution.labels: an actor label with the value ai-agent, plus organization, tool, and product labels carrying values like openai, anthropic, and browser-use, and provider labels for hosted-infrastructure sessions (Browserbase-style cloud browsers), each with a confidence score. User attachment is handled separately: client.sessions.attachClientUser(sessionId, clientUserId) ties a session to one of your accounts, and client.gate.agents.verify(...) verifies an authorized agent’s token.

How Foil thinks about agent traffic

Foil’s posture is that bot detection and AI agent detection are the same product served two different ways. The same SDK collects, the same scorer evaluates, and the same verdict structure is returned, but the attribution labels carry agent-specific evidence alongside the traditional framework classes. The labels name the operator and tooling where possible, and the user-attachment status is reported separately.

The decision tree above is left to the application. We do not auto-block any agent class by default because the correct decision is product-specific. We give the data and the verdict that lets you implement the right policy.

For the broader bot-detection picture, bot detection is the parent. For the response side, bot mitigation. For signed agent identity, bot management covers the Web Bot Auth detail.

Further reading