# The Agent Who Won't Say Its Name > Source: > Published: 2026-08-10 18:37:14+00:00 *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. 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. 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. 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. 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 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. 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.*