Every control built to answer "is this a human or a bot?" now returns the wrong answer several times a minute. A shopping assistant filling a cart on a user's behalf is automation. So is a credential-stuffing script. Both arrive headless, both come from a datacenter, and increasingly both claim to be Chrome.
The question worth asking in 2026 is not whether traffic is automated. It is whose intent the automation carries, and what the request is trying to do. Those are different questions, and only the second one maps cleanly onto enforcement.
This piece lays out the three populations you are actually sorting, what each one genuinely leaks, and a policy shape that does not break either your fraud numbers or your traffic from legitimate assistants.
Three populations, not two
Lumping all non-human traffic together is what makes AI agents feel unsolvable. Split it and the problem becomes tractable, because each group leaves a different kind of evidence.
- Declared crawlers and fetchers. Operated by a vendor, identified by a stable user agent, and — for the serious ones — backed by published IP ranges. They want to be identified, because being blocked is bad for them.
- User-driven agents. A human asked for something and an agent runtime is carrying it out: browsing, comparing, filling a form, completing a purchase. Intent is human, execution is automated, and the traffic often egresses from cloud infrastructure rather than the user's home connection.
- Adversarial automation wearing agent clothing. Scrapers, stuffers, and inventory bots that noticed "agent" user agents get allowlisted and started sending them. This population grows in exact proportion to how generously the first two are treated.
Why the user agent is the weakest possible signal
A user agent is a request header. Anyone can send any string. The moment a meaningful number of sites started allowlisting assistant traffic by name, copying that string became the cheapest bypass available — no infrastructure, no tooling, one line of configuration.
This is the same arc that played out with Googlebot fifteen years ago, and the answer is the same one search engines settled on: never trust the claim, verify the origin.
What actually verifies a declared agent
Two mechanisms carry real weight today, and a third is arriving.
- Published IP ranges. The major AI vendors publish machine-readable range lists for their crawlers and fetchers, and refresh them as infrastructure changes. Fetching those lists on a schedule and matching the connecting address is the strongest check available right now, because the attacker would need to actually originate from vendor infrastructure.
- Forward-confirmed reverse DNS. Resolve the connecting IP to a hostname, then resolve that hostname back and confirm it returns the same IP. This is the classic crawler-verification pattern. It is weaker than range matching but useful where ranges are not published.
- Cryptographically signed requests. Work is moving through the IETF on HTTP message signatures for bot and agent identity, which would let an agent prove who it is per-request rather than relying on network position. Treat this as directional rather than deployable — check the current draft status before building on it, and keep range matching as the load-bearing check.
The datacenter trap
Here is where most teams break their own traffic. Legitimate agent runtimes execute in the cloud. So the dch signal — the one that says this address belongs to a hosting provider — fires on the good population and the bad population alike.
If your rule is "datacenter means block," you have just blocked every assistant that might have sent you a customer, while catching only the least sophisticated attackers, because the serious ones moved to residential egress years ago. That is the worst of both trades.
This is why range hits have to add context rather than decide outcomes. In our own pipeline a datacenter hit contributes 40 points toward a 0–100 risk score — meaningful, not decisive, and never a reason to skip tunnel detection. A VPN or proxy tunnel contributes 60. Tor floors the score at 90. A verdict of review starts at 40 and block at 80, so infrastructure alone lands you in review, not rejection. That ordering is deliberate: VPN exit nodes live in datacenters, so a range match must never short-circuit the checks that would have caught the tunnel.
Where agent runtimes genuinely leak
Once you stop asking the user agent, the honest signals are the same ones that catch any automation — plus a few specific to how agents are built.
- Automation surfaces. Agent frameworks overwhelmingly drive a real browser through the DevTools protocol. That leaves detectable traces in the execution environment regardless of what the user agent claims. The same techniques that surface Puppeteer and Playwright apply directly.
- Interaction entropy. Human input carries messy timing: variable dwell, corrected typing, non-linear pointer paths. Agent-driven input is generated. It is not that agents are too fast — many deliberately throttle — it is that the *distribution* is wrong.
- Protocol-layer contradictions. A request claiming a specific browser version should present the TLS and HTTP/2 fingerprint that build actually produces. Agent stacks and HTTP libraries frequently do not match their own claims. See JA3, JA4, and TLS fingerprinting for how to read that mismatch.
- Session shape. Assistants tend to arrive, fetch a small number of specific things, and leave. They rarely browse the way a person shopping does. That is not incriminating by itself — it is a useful prior.
Enforce on action risk, not page views
The single most useful reframing: stop deciding at the edge of the site and start deciding at the edge of the *action*.
Reading a product page is cheap. Nobody is harmed if an unverified agent reads it, and blocking that read costs you a referral. Creating an account, redeeming a promotion, changing an email address, or completing a checkout are expensive and irreversible. Those deserve scrutiny in proportion to what they cost when wrong.
A policy built that way degrades gracefully. A verified assistant reading content is served. The same runtime attempting a bonus redemption gets challenged, because the risk of that specific action justifies it — and no allowlist entry should be able to skip that check.
| Request | Verified declared agent | Unverified automation | Automation + tunnel or tamper |
|---|---|---|---|
| Read a public page | Serve | Serve, rate-limited | Serve, rate-limited |
| Search or query an API | Serve, rate-limited | Rate-limit, log | Challenge |
| Create an account | Challenge | Challenge | Block |
| Redeem promo / bonus | Challenge | Block | Block |
| Checkout / payment | Challenge | Challenge | Block |
Log the reason, not just the outcome
Agent behaviour, vendor infrastructure, and identity standards are all moving faster than your rules will. Whatever you decide this quarter will be wrong by the next one.
The teams that stay ahead record why each decision was made — which signals fired, which verification passed or failed, what the risk score was — not just allow or block. When a vendor rotates ranges or a new runtime appears, that log is the difference between a twenty-minute rule change and a week of guessing which population you broke.
It also protects you in the other direction. When someone reports that an assistant could not complete a purchase, you want to answer from evidence.
The short version
Verify declared agents against published ranges rather than believing headers. Treat datacenter origin as context worth 40 points, never as a verdict. Watch automation surfaces, interaction entropy, and protocol contradictions instead of the user agent. Scale enforcement to what the action costs, not to whether traffic looks automated. And log the reasoning so the policy can move when the landscape does.
Blanket-blocking automation was never a strategy. In 2026 it is an active revenue decision, and usually the wrong one.
Frequently Asked Questions
How do I verify an AI agent is really from the vendor it claims?
Match the connecting IP against the vendor's published range list rather than trusting the user agent, which is a request header anyone can send. The major AI vendors publish machine-readable range files for their crawlers and fetchers; fetch them on a schedule and treat the match as the verification. Where no ranges are published, fall back to forward-confirmed reverse DNS: resolve the IP to a hostname, resolve that hostname back, and require it to return the same IP. Signed-request standards for agent identity are progressing through the IETF but are not yet something to make load-bearing.
Should I block AI agents from my site?
Rarely as a blanket rule, because agent traffic increasingly carries real customer intent and blocking it forfeits those conversions. The better model is to enforce by action risk: serve public content freely, rate-limit queries, and challenge or block expensive irreversible actions such as account creation, promotion redemption, and checkout. Blanket blocks also fail on their own terms, since the adversarial population simply moves to residential egress and copies whatever user agent you allowlisted.
Why does datacenter IP detection flag legitimate AI agents?
Because legitimate agent runtimes genuinely execute in cloud infrastructure, so they share network origin with scrapers and attack tooling. That is why a datacenter match should add risk rather than decide the outcome. In Sentinel's pipeline a datacenter hit contributes 40 points on a 0-100 scale, which lands in the review band rather than the block band, and it never short-circuits tunnel detection — VPN and proxy exits are themselves hosted in datacenters, so skipping those checks on a range hit would miss the harder cases.
Can attackers just copy an AI agent user agent to get allowlisted?
Yes, and this is the predictable consequence of name-based allowlisting. A user agent is a freely settable request header, so once sites began granting privileges to assistant traffic by name, copying the string became the cheapest available bypass. This is the same pattern search engine crawlers faced, and it has the same answer: verify the origin against published IP ranges or forward-confirmed reverse DNS, and never grant privilege on the strength of a claimed identity alone.
What signals distinguish an AI agent from a human user?
Automation surfaces are the most reliable, since agent frameworks generally drive a real browser through the DevTools protocol and leave traces in the execution environment no matter what the user agent says. Interaction entropy is the next strongest: human input has messy, variable timing and corrected typing, while generated input has a different distribution even when it is deliberately slowed. Protocol-layer contradictions also help, such as a request claiming one browser version while presenting a TLS or HTTP/2 fingerprint that build does not produce.
Sort agents from attackers
Get network, tunnel, and automation signals in a single server-side call.
Try Sentinel free →