Spoofed agent user-agents: verifying the request really came from ChatGPT or Claude
Setting a user-agent string costs nothing and requires no permission from the vendor it names. That's the whole vulnerability, and it's why "the UA says ChatGPT" should never be the end of the check.
In short
Any script can set its user-agent to claim it's ChatGPT-User, Perplexity-User, or Claude-User, and security researchers report a meaningful share of traffic making that claim is spoofed. Verifying a claim means checking for corroboration: a Web Bot Auth cryptographic signature where available (the strongest proof), a matching published IP range, and a fingerprint or request pattern consistent with the named vendor's actual client. Rank these, don't rely on any one alone.
Landscape as of September 2026
Why the UA string is a claim, not evidence
A user-agent header is a plain-text field the client sets on every request; nothing about the HTTP protocol authenticates it. A scraper, a competitor, or a bad actor can set Perplexity-User/1.0 just as easily as Perplexity's own infrastructure can - and reports from HUMAN Security and Quantum Metric describe exactly that happening at scale: requests claiming to be well-known agents that do not actually originate from those vendors' infrastructure. Independent researchers have also documented cases where a named vendor's real crawler behavior didn't match its own published documentation - so even a request that genuinely comes from the named vendor isn't automatically doing what its own docs say it does. Two different trust problems, one fix: verify, don't read.
The verification ladder
Method
Strength
Coverage today
Web Bot Auth signature (RFC 9421)
Cryptographic proof - the strongest available
Only where the agent operator has implemented it; still an individual IETF draft as of August 2026, so coverage is partial. See Web Bot Auth explained.
Published IP / ASN range
Strong corroboration when the vendor maintains and publishes one
Better established for crawlers than for acting agents that may route through a user's own network
TLS / client fingerprint match
Moderate - confirms the request came from the kind of client the vendor is known to run
Limited against agents that drive a genuine, unmodified browser (see the directory for which ones do)
Request pattern / behavior
Weak on its own, useful as a tiebreaker
Always available from your own logs, never conclusive alone
Rule of thumb: the UA string tells you what to check for, not what to believe. A claimed identity with zero corroborating signals and high-volume, repetitive request behavior is more likely spoofed traffic or scraping than a genuine agent - treat it accordingly rather than either blanket-trusting or blanket-blocking on the string alone.
Where this connects
Getting this wrong runs in both directions: trusting an unverified claim lets fake "agent" traffic pollute your reporting and possibly your access controls, while treating every unverified claim as automatically suspicious is what causes real agents to get filtered as bot spam. The fix for both is the same composite verification described in how to detect AI agent traffic - this page is the deep dive on the specific, adversarial half of that problem.
Common questions
How common is user-agent spoofing for AI agents, really?
Security researchers (HUMAN Security, Quantum Metric) report a significant share of requests claiming to be ChatGPT, Perplexity, or other named agents are spoofed - the exact rate isn't a single settled figure and varies by site and by vendor's own reporting, so treat any specific percentage you see cited as that source's estimate, not a universal constant. The direction is well established: the UA string alone is not trustworthy evidence.
What's the strongest way to verify a claimed agent identity?
A Web Bot Auth signature (RFC 9421 HTTP Message Signatures, verified against a public key the operator publishes at a well-known URL) is the only cryptographic proof available. Its adoption is still early, so it will only cover a fraction of claimed-agent traffic today.
What if the agent doesn't support Web Bot Auth?
Fall back to corroboration: does the request's IP fall within a range the vendor has published, does the TLS/browser fingerprint match what that vendor's client is known to produce, and does the request pattern match a single purposeful action rather than high-volume automation. No single corroborating signal is proof, but two or more together raise confidence meaningfully above a bare UA match.
Has any AI vendor actually been caught misrepresenting its own traffic?
Independent researchers have publicly reported cases where a vendor's crawler behavior did not match its own published documentation - a reminder that even a vendor's own claims about its user-agent behavior deserve verification, not just third-party spoofers impersonating that vendor.
Verify before you trust or block a claimed agent.
We build the verification ladder - signature check, IP corroboration, fallback scoring - into your request pipeline.