Agentic browsers: your customer is now a robot, and that is fine
An agentic browser is automation operated by a real customer. It fails every classic bot test and still deserves to reach your checkout. The answer is to require evidence of a human on particular steps, rather than to judge the client.
For twenty years, bot detection has asked one question: is this a person or a program? The answer decided what you did about it. The question and the action were the same thing.
Agentic browsers break that, because an agentic browser is a program operated by a person and doing what that person asked for — ChatGPT Atlas, Perplexity Comet, and a growing number of Chromium forks with an AI layer bolted to the driver. It fails every classic automation test, and it is also a real customer with a real card.
If you block it, you have blocked a buyer. If you wave it through, you have no control over an automated client hitting your checkout. The question itself has changed.
Why they fail every test
An agentic browser is not trying to deceive you, but it trips the alarms anyway.
No human input. The strongest signs of a human come from the physical act of using a computer. The micro-tremor in a mouse path. The timing between keystrokes. The way a finger lands on a touchscreen. An agent makes its input events in code. There is no hand, so none of those characteristics are there.
Machine-regular timing. People pause, re-read and get distracted, but an agent reads the DOM and acts at an even rhythm.
Remote-control traces. Most agentic browsers drive Chromium through the Chrome DevTools Protocol, or something like it. Driving a browser that way leaves traces in the JavaScript environment. We detect raw CDP evaluation because it is the signature of an instrumented browser. It fires on an agentic browser just as it fires on a Playwright script.
It genuinely is a real browser. The signals that catch crude automation all come back clean: missing APIs, wrong WebGL strings, absent SIMD support, a headless-shaped fingerprint. It is real Chromium on real hardware. The fingerprint half of bot detection has nothing to say about it.
So the behavioural signals say bot. The environmental signals say browser. Both are correct.
Why the user-agent will not save you
The obvious move is to read navigator.userAgent, or the request header, and look for the agent's name. Some agentic browsers do declare themselves, and that helps.
It only works in one direction. A declared user-agent is only a claim, which makes it useful for allowing traffic and useless for blocking it, because anyone who wants to look like a person stops declaring. We have written about why faking a browser is easy but not at scale, and the same point applies here. Treat a declared agent string as a courtesy, so you can be kind to well-behaved agents. Never build a control that assumes a missing string means human.
Web Bot Auth is the proper fix for the identity half of this. The agent signs its requests with a key, so you can check the declaration instead of trusting a string anyone can copy. It is the right foundation for an allow-list. It still says nothing about whether the verified agent should be allowed to buy four hundred tickets.
Agent is not scraper
Two things here both look like automation. Keep them apart, because the right response to each is different.
A scraper is one operator pulling data in bulk for their own ends. Thousands of sessions, spread across residential proxy pools, rotating fingerprints, running non-stop. The harm is in the total.
An agentic browser is usually one user, one task, one session and one address, at about the pace a person would work. The harm is usually zero.
Volume and spread tell these apart far better than any client-side signal. One well-behaved session from a declared agent is a customer. Six hundred sessions at once, all claiming to be the same agent, from a rotating set of addresses, is somebody wearing the agent's name as a costume. Agent user-agents are now widely expected to be allowed, so that costume is getting more popular. Our own logs are full of it. We found five Google Cloud addresses rotating fifteen different AI client user-agents between them. Most of their requests probed for /.env and /.ssh/config.
The policy that actually works
Stop classifying the client. Start classifying the flow.
Almost everything on your site is harmless to automate. Browsing, searching, reading reviews, comparing specifications, checking stock. An agent doing those things is a customer doing research, and a customer with higher intent than average. Let it through. Make your pages machine-readable enough that it gets the right answer about you.
A short list of flows is where automation costs you money: checkout on limited inventory, promotional code redemption, appointment booking, bulk export, account credential changes, free-tier signup. These map onto API6 of the OWASP API Security Top 10, unrestricted access to sensitive business flows. Nothing is broken. The only problem is that software runs the flow at a rate you did not intend.
Only require evidence of a human when somebody reaches one of those steps. The agent still does the browsing and the research, and the person finishes the risky step themselves, which is a minor annoyance at the moment they most want to complete it. A scalper will also be restricted by these rules, whatever they are driving — an agentic browser, a Playwright script or a rented device farm.
This is also the only version of the policy that will survive the next six months. The number of agentic browsers is going up and their fingerprints will keep changing, so one detection rule per product is a treadmill. A rule about which flows require a person is stable, because it describes your business rather than somebody else's software release.
What we do about it
Prosopo's detection is split across layers on purpose. That split is what makes a per-flow policy possible rather than just advisable.
In the browser we collect signals anchored in the hardware: SIMD timing, input characteristics and remote-control traces. These show that the client is being driven, without needing to know which product is driving it. On the server, TCP-layer interrogation and IP intelligence establish whether this is one session or one actor wearing many. In Prosopo Protect, a model scores request intent across the human / agent / bot boundary. That is the distinction that matters once "is it a browser" stops being informative.
Every block names the signal that caused it. In this category that is not a nicety. When an agentic browser is stopped at your checkout and the customer emails to ask why, "risk score 87" is not an answer you can give them.
Seeing agent traffic and unsure what to do with it?
If agentic browser sessions are showing up in your logs and you are deciding what to allow, tell us what you are seeing. We will look at the traffic before we reply.
Frequently Asked Questions
What is an agentic browser?
A browser that can carry out multi-step tasks on a user's behalf rather than only displaying pages. You give it an instruction — find me a flight under this price, fill in this form, compare these products — and it navigates, reads pages, clicks and types by itself. ChatGPT Atlas and Perplexity Comet are the best-known examples. Technically most are Chromium with an AI layer driving it, which means the traffic reaching your server comes from a genuine browser engine.
Is an agentic browser a bot?
It depends on which question you are asking, and that is exactly why it is hard. By behaviour it is automation: no human moved the mouse or typed the characters. By intent it is usually a real customer who has delegated a task. Classic bot detection answers the behaviour question, so it classifies agentic browsers as bots and blocks real buyers. Treating them as human means you have no control over an automated client. Neither answer is right, which is why the category of question has changed from human-or-bot to who-is-this-for.
Should I block agentic browsers?
Not as a blanket policy, because you would be blocking customers who are trying to buy from you. The useful policy is per-flow rather than per-client: let an agent browse, search and compare freely, and require a human-present check at the points where automation causes harm — checkout on limited inventory, bulk export, account changes, anything a scalper would want to run at scale. Block the behaviour you cannot absorb, not the client type.
Can I detect an agentic browser?
Often, yes, but not by reading the user-agent. Some agentic browsers declare themselves in the user-agent string, and that string is a claim anybody can copy, so it is useful for allowing traffic and worthless for blocking it. More reliable signals come from how the automation drives the browser: input events that arrive without the hardware-level characteristics of a hand on a mouse, navigation timing that is too regular, and the traces that a remote-control protocol such as CDP leaves in the JavaScript environment.
How do agentic browsers differ from scrapers?
In who they are working for and at what scale. A scraper is one operator extracting data at volume for their own purposes, typically across thousands of sessions through proxies. An agentic browser is usually one user doing one task in one session from one address. The traffic patterns are very different even though both are automation, and volume and distribution are often the cleanest way to tell them apart.
What is Web Bot Auth and does it solve this?
Web Bot Auth is IETF draft work that lets an automated client cryptographically sign its requests so you can verify which agent it is, instead of trusting a user-agent string. It solves identity and leaves intent untouched — a verified agent can still buy all your inventory. It is the right foundation for an allow-list, and it is not a substitute for scoring what the client then does.