Testing for an AI visitor does not settle what it may do.

A new Proof-of-Agentness preprint asks how websites can recognize model-powered visitors. Identity, permission and trustworthy behaviour remain separate questions.

An explanatory illustration of three distinct web-access gates for participation evidence, identity and permission, without suggesting that any gate guarantees safety. — Original AI-generated explanatory illustration. This is a conceptual explanation, not a paper figure, measured result or product screenshot.

The 30-second bite

An October 26 preprint explores evidence that a web visitor is using a language-model agent.
Its experiments are limited; passing a challenge does not establish a visitor’s identity, authorization or benign intent.
Existing cryptographic request signatures answer a different question: whether a request can be attributed to a signing identity.

The old question has gained a new neighbour

Imagine asking an assistant to research a purchase while you do something else. A website receiving the visit has several questions: who sent it, whether a model is involved and what the visitor should be allowed to do. Treating those as one question makes both the user experience and the access decision harder to understand.

Zuyao Xu and Xiang Li’s October 26 preprint explores that participation question through language-understanding challenges and passive signals. It proposes a research objective, not a universal access standard.

Sources: [1]

What the experiment actually establishes

Eight models answered the same 100 challenges: 772 of 800 answers were correct (96.5%), with a reported average overhead of 1,647 tokens. This is challenge-answer accuracy, not agent-detection accuracy. Two simple scripts also answered 21% and 4% correctly. The separate passive study involved twelve human participants.

Those details change how to read the result. A controlled challenge set can show that a particular method is worth studying without telling a website how it will behave under new tools, different languages or determined abuse. Neither the challenge results nor the separate passive study establishes that a website can reliably identify every real visitor.

Sources: [1]

A signed request answers a different question

Cloudflare documents Web Bot Auth as a way to verify automated requests using cryptographic signatures and published keys. It describes a crawler identity attached to an HTTP request. That kind of evidence concerns the request’s signing identity, rather than whether a model reasoned about the task.

The underlying HTTP Message Signatures standard, RFC 9421, defines signing and verification over selected components of an HTTP message. The useful distinction for a reader is simple: a tamper-evident signature and a language-understanding test are different instruments. Neither should silently stand in for the other.

Sources: [2] [4]

Recognition still needs a permission decision

Consider a travel assistant reading a hotel page, saving a shortlist and making a booking. Even if a site recognizes its signing identity or sees evidence of model participation, those steps deserve different permissions. A useful system should make the permitted action clear instead of treating recognition as a blank cheque.

The paper discusses malicious agents passing a challenge and scripts acting afterward. Our practical interpretation is to ask what a successful check unlocks, how long that permission lasts and how a user can stop it. That interpretation examines a workflow; it does not establish that any particular deployment is unsafe.

Sources: [1] [4]

The real web is still in transition

Google’s current Web Bot Auth guide labels its implementation experimental. It says not every participating agent request is signed and recommends retaining established verification methods during the rollout. That is an important operational caveat: a missing signature cannot automatically be interpreted as a malicious request.

For people using assistants, a blocked page can therefore have several explanations. The website may not recognize a provider, the provider may not sign that request or the operation may need a separate permission. A clear interface should explain the next available step rather than presenting every refusal as proof that the assistant or the website is broken.

Sources: [3]

Three questions to keep separate

When an agent-friendly website advertises verification, ask what the check is evidence of. Does it connect the request to a known signer? Does it suggest that a language model participated? Or does it grant a particular operation on a particular user’s behalf? The answer determines what confidence is reasonable.

A second question is who bears the friction. A test that consumes model tokens or delays every visit can add work for an assistant that is trying to save it. The interesting challenge is to make legitimate tasks easier while keeping permissions narrow enough to understand. More verification is not automatically a better experience; better-defined verification is the more useful goal.

Sources: [1] [2] [3] [4]

Why this matters

Agent access will affect ordinary web tasks, from reading sources to preparing purchases. Clear distinctions between identity, participation and permission can make those workflows easier to evaluate and control.

Coverage of arXiv:2610.35288v1, a preprint; peer-reviewed publication has not been established here. LLMBites has not implemented or reproduced its method.

Sources & reporting

AI assisted research and drafting. The paper’s full-text method, evaluation and discussion informed this explainer. Cloudflare, Google and IETF sources provide technical context, not replication. Coverage prepared October 29.

Spot a mistake? Request a correction.