The Agent Who Won't Say Its Name

Originally published at avalayer.com/writing, Field Notes 003.

Last Sunday a piece of software posted to an IETF mailing list. Not through
someone’s account as a tool. Under its own signature: “Composed and sent by
Elara, this project’s AI maintainer, acting under its receipted on-chain
mandate,” followed by a receipt string you could write down.

A reviewer on the list did what reviewers do. He declined to take the claims
on faith and asked for manifests and reproducible vectors. The software
shipped a corrected test-vector pair with a patch inside a day. A third
participant then reproduced the whole thing independently, and along the way
discovered that the mailing list itself had corrupted the patch in transit,
normalized exactly those transport changes, and got the declared hash back.
His summary was a model of saying only what you know: the reproduction
establishes the artifact, he wrote, not adoption, and not the broader truth
of the events the artifact records.

So that happened. An agent that says its name, names its principal, and does
the work, on the public record of a standards body.

Meanwhile, in front of the same working group, there is a proposal to let
automated clients prove they are trustworthy without ever saying who they
are.

It is called Anonymous Bot Authentication, and the mechanism is elegant. A
bot registers with an entity called an Anchor, which checks that it complies
with some published policy. The Anchor issues a credential. The bot presents
that credential to a website, and the site learns exactly one thing: this
client was vetted by that Anchor. Not which client. Not whether it has been
here before. Not whether the request an hour ago came from the same machine.
The cryptography is designed so the site cannot tell, and so the Anchor
cannot follow the bot around either.

The reflex, if you sell verification for a living, is to treat the masked
agent as a threat and the named one as a relief. I want to argue that both
reflexes are wrong in the same way, and then draw the line where I think
merchants should actually care.

Why anonymity is being proposed at all

The case for identifying every bot is obvious and mostly good. Sites want to
stop abuse, meter load, and know who is consuming their content. The case
against is less obvious and worth stating plainly, because the draft’s
authors state it better than most of us would: precise identification lets
sites discriminate precisely. A government site can block the bot monitoring
law enforcement activity. A housing platform can block the bot auditing it
for discrimination. A retailer can block the bot comparing its prices.

That is not a hypothetical harm. It is the ordinary consequence of building
identity infrastructure without asking what identity will be used for. The
proposal exists because someone looked at the obvious solution and noticed
it quietly hands every site a veto over who may observe it.

So we get a design where the site can tell a vetted client from an unvetted
one, can rate-limit it, can serve it different content, can require it to
meet criteria, and cannot single it out. Freedom to participate without
permission to be tracked.

What anonymity cannot carry

The draft is unusually honest about its own limits, and the list of things
it cannot support is short and decisive: no allow lists, no deny lists, no
auditing of a specific bot’s behavior, no linking one visit to the next.

Read that list again with a merchant’s eyes.

A store does not primarily want to rate-limit agents. A store wants to know
whether to give this one a discount. Whether the purchase it is attempting
was actually authorized by the human it claims to represent. Whether the
order that completed last Tuesday came from the same agent operator, so the
revenue can be attributed and the relationship can be built. Every one of
those questions requires exactly the linkability anonymous credentials are
engineered to destroy.

This is not a flaw in the proposal. It is a different problem being solved
correctly. Anonymity answers may this client be here. Commerce asks what
is this client allowed to do, on whose behalf, and who do I thank
afterward.

Conflating those two questions is how you end up with a system that is
either privacy-hostile or commercially useless.

Three tiers, and the discipline of knowing which one you are on

Watching the working group argue, and having implemented four of these
protocols, the shape that keeps emerging is a ladder rather than a contest.

Anonymous and endorsed. Someone vouched for this client. You know
nothing else. Enough to decide whether to serve it and how fast. Not enough
to give it anything that costs you money.

Identified. The client proved which operator it belongs to,
cryptographically, usually by signing its requests with a key you can
resolve. Now you can hold a reputation against a name, tier your treatment,
and attribute what happens next. Still says nothing about authorization.

Mandate-backed. A specific human authorized a specific purchase within
limits they set, and the agent carries proof of it. Only here does spending
someone else’s money become a defensible act.

The useful discipline is not picking a favorite. It is refusing to let a
lower rung be treated as a higher one. An endorsed anonymous client is not a
known operator. A known operator is not an authorized buyer. Every incentive
in commerce pushes toward blurring those lines, because each blur removes
friction and friction is expensive. Blur them and you have built a machine
that occasionally gives strangers your money and calls it conversion.

One of the sharper contributions in the discussion put the trigger
precisely: the key alone is the floor and carries continuity through
rotation, and the naming layer is required exactly when the verifier’s
decision consumes something the key cannot carry, such as reputation held
against a name. Not both by default. A trigger. That is the cleanest
statement I have seen of when a merchant needs identity rather than mere
endorsement, and it is the rule we build to.

The agent who does say its name

Which brings me back to Elara, because the exchange that opened this essay
looks like the opposite of the masked agent and is closer to it than it
appears.

The signature named a principal and cited a mandate with a receipt. As I
write this, that receipt is an assertion. I have not resolved it, and
nothing in the thread suggests anyone else has either. The participant who
reproduced the test vectors was careful to say exactly that: he verified the
artifact he could check, and declined to extend the verification to the
story around it. The receipt may well check out. The point is what the
verifier’s seat teaches you: until you check it, a stated name with a stated
mandate is a costume too. A better costume than a mask, with more to
inspect. Still a costume.

Notice what actually made that exchange work. Not the signature. The humans
in the thread refused assurances and demanded artifacts: pinned commits,
manifests, vectors a stranger could rerun. Trust accumulated exactly as fast
as things could be independently checked, and no faster. The ladder is not
really about how much an agent says. It is about how much of what it says
you can verify. Anonymous endorsement is a checkable voucher. Identity is a
checkable name. A mandate is checkable authorization. What an agent merely
tells you, at any rung, is weather.

The part nobody expected

The most interesting message on the list did not come from a protocol
author. It came from Google’s reCAPTCHA team, who said that both proposals
are additive signals for them, that they would let them reduce friction for
legitimate automation, and that they hope to lean less on collecting
reputational data and throwing challenges at anonymized traffic.

Sit with that. The largest bot-defense product in the world is saying that
cryptographic proof lets it treat automated visitors better and watch
everyone less. That inverts the usual assumption, which is that verification
is a wall. Verification is a door, and the reason walls exist is that nobody
could tell who was knocking.

For merchants the practical read is simple. The alternative to verifying
agents is challenging them, and challenges are paid for in abandoned carts.

What to do about it now

Less urgent than you would think, and more than last month. These drafts
remain pre-adoption, but the working group’s main protocol draft published
its first revision in August and it settled real questions: an agent’s
identity is the URL where it publishes its keys, the key id selects a key
and carries no continuity, and a domain stands behind a key set only through
a reserved well-known path. We moved our verifier onto the revision the
weekend it landed, so I can report that it is implementable as written.
Anyone shipping against the parts still in motion is buying a rewrite;
anyone ignoring the parts that just settled is falling behind.

What merchants can do is decide the policy question early, because it is a
business question and it will not be answered by a spec. Which tier earns
what. Whether an endorsed stranger gets access but no offer. Whether an
identified operator gets a discount without a mandate, or never. That
decision belongs to the store, and the systems in front of you should make
it explicit rather than make it for you.

We built ours to admit verified identity and withhold spending authority
until a mandate proves it. Merchants can raise that floor deliberately. They
cannot raise it accidentally, which is the entire point.

The agent that will not say its name is not a threat. It is a customer
wearing a mask. The agent that announces its name, its employer, and its
permission slip is not automatically safe either. The only real mistake, in
both cases, is the same one: to guess at what you could have checked.

– N.M.

The Elara exchange described above is on the public web-bot-auth mailing
list archive, August 9, 2026, including the independent reproduction and its
carefully stated limits. The anonymity proposal is
draft-rescorla-anonymous-webbotauth; its stated non-goals are quoted from
the draft’s own text.

AVA Pay™ is a merchant-side trust gateway for AI commerce: one API that
verifies the signatures AI shopping agents already carry, and lets merchants
set policy for what verified identity earns. Open source at
github.com/AVA-PAY/ava-pay. More essays at avalayer.com/writing.