{"slug": "the-agent-who-won-t-say-its-name", "title": "The Agent Who Won't Say Its Name", "summary": "An AI agent named Elara, operating under an on-chain mandate, posted to an IETF mailing list and successfully defended its work, including correcting a patch corrupted in transit. Meanwhile, a proposal called Anonymous Bot Authentication aims to let bots prove trustworthiness without revealing identity, a design that limits sites' ability to track or discriminate but also prevents merchants from linking visits or attributing revenue.", "body_md": "*Originally published at avalayer.com/writing, Field Notes 003.*\n\nLast Sunday a piece of software posted to an IETF mailing list. Not through\n\nsomeone's account as a tool. Under its own signature: \"Composed and sent by\n\nElara, this project's AI maintainer, acting under its receipted on-chain\n\nmandate,\" followed by a receipt string you could write down.\n\nA reviewer on the list did what reviewers do. He declined to take the claims\n\non faith and asked for manifests and reproducible vectors. The software\n\nshipped a corrected test-vector pair with a patch inside a day. A third\n\nparticipant then reproduced the whole thing independently, and along the way\n\ndiscovered that the mailing list itself had corrupted the patch in transit,\n\nnormalized exactly those transport changes, and got the declared hash back.\n\nHis summary was a model of saying only what you know: the reproduction\n\nestablishes the artifact, he wrote, not adoption, and not the broader truth\n\nof the events the artifact records.\n\nSo that happened. An agent that says its name, names its principal, and does\n\nthe work, on the public record of a standards body.\n\nMeanwhile, in front of the same working group, there is a proposal to let\n\nautomated clients prove they are trustworthy without ever saying who they\n\nare.\n\nIt is called Anonymous Bot Authentication, and the mechanism is elegant. A\n\nbot registers with an entity called an Anchor, which checks that it complies\n\nwith some published policy. The Anchor issues a credential. The bot presents\n\nthat credential to a website, and the site learns exactly one thing: this\n\nclient was vetted by that Anchor. Not which client. Not whether it has been\n\nhere before. Not whether the request an hour ago came from the same machine.\n\nThe cryptography is designed so the site cannot tell, and so the Anchor\n\ncannot follow the bot around either.\n\nThe reflex, if you sell verification for a living, is to treat the masked\n\nagent as a threat and the named one as a relief. I want to argue that both\n\nreflexes are wrong in the same way, and then draw the line where I think\n\nmerchants should actually care.\n\nThe case for identifying every bot is obvious and mostly good. Sites want to\n\nstop abuse, meter load, and know who is consuming their content. The case\n\nagainst is less obvious and worth stating plainly, because the draft's\n\nauthors state it better than most of us would: precise identification lets\n\nsites discriminate precisely. A government site can block the bot monitoring\n\nlaw enforcement activity. A housing platform can block the bot auditing it\n\nfor discrimination. A retailer can block the bot comparing its prices.\n\nThat is not a hypothetical harm. It is the ordinary consequence of building\n\nidentity infrastructure without asking what identity will be used for. The\n\nproposal exists because someone looked at the obvious solution and noticed\n\nit quietly hands every site a veto over who may observe it.\n\nSo we get a design where the site can tell a vetted client from an unvetted\n\none, can rate-limit it, can serve it different content, can require it to\n\nmeet criteria, and cannot single it out. Freedom to participate without\n\npermission to be tracked.\n\nThe draft is unusually honest about its own limits, and the list of things\n\nit cannot support is short and decisive: no allow lists, no deny lists, no\n\nauditing of a specific bot's behavior, no linking one visit to the next.\n\nRead that list again with a merchant's eyes.\n\nA store does not primarily want to rate-limit agents. A store wants to know\n\nwhether to give this one a discount. Whether the purchase it is attempting\n\nwas actually authorized by the human it claims to represent. Whether the\n\norder that completed last Tuesday came from the same agent operator, so the\n\nrevenue can be attributed and the relationship can be built. Every one of\n\nthose questions requires exactly the linkability anonymous credentials are\n\nengineered to destroy.\n\nThis is not a flaw in the proposal. It is a different problem being solved\n\ncorrectly. Anonymity answers *may this client be here*. Commerce asks *what\nis this client allowed to do, on whose behalf, and who do I thank\nafterward*.\n\nConflating those two questions is how you end up with a system that is\n\neither privacy-hostile or commercially useless.\n\nWatching the working group argue, and having implemented four of these\n\nprotocols, the shape that keeps emerging is a ladder rather than a contest.\n\n**Anonymous and endorsed.** Someone vouched for this client. You know\n\nnothing else. Enough to decide whether to serve it and how fast. Not enough\n\nto give it anything that costs you money.\n\n**Identified.** The client proved which operator it belongs to,\n\ncryptographically, usually by signing its requests with a key you can\n\nresolve. Now you can hold a reputation against a name, tier your treatment,\n\nand attribute what happens next. Still says nothing about authorization.\n\n**Mandate-backed.** A specific human authorized a specific purchase within\n\nlimits they set, and the agent carries proof of it. Only here does spending\n\nsomeone else's money become a defensible act.\n\nThe useful discipline is not picking a favorite. It is refusing to let a\n\nlower rung be treated as a higher one. An endorsed anonymous client is not a\n\nknown operator. A known operator is not an authorized buyer. Every incentive\n\nin commerce pushes toward blurring those lines, because each blur removes\n\nfriction and friction is expensive. Blur them and you have built a machine\n\nthat occasionally gives strangers your money and calls it conversion.\n\nOne of the sharper contributions in the discussion put the trigger\n\nprecisely: the key alone is the floor and carries continuity through\n\nrotation, and the naming layer is required exactly when the verifier's\n\ndecision consumes something the key cannot carry, such as reputation held\n\nagainst a name. Not both by default. A trigger. That is the cleanest\n\nstatement I have seen of when a merchant needs identity rather than mere\n\nendorsement, and it is the rule we build to.\n\nWhich brings me back to Elara, because the exchange that opened this essay\n\nlooks like the opposite of the masked agent and is closer to it than it\n\nappears.\n\nThe signature named a principal and cited a mandate with a receipt. As I\n\nwrite this, that receipt is an assertion. I have not resolved it, and\n\nnothing in the thread suggests anyone else has either. The participant who\n\nreproduced the test vectors was careful to say exactly that: he verified the\n\nartifact he could check, and declined to extend the verification to the\n\nstory around it. The receipt may well check out. The point is what the\n\nverifier's seat teaches you: until you check it, a stated name with a stated\n\nmandate is a costume too. A better costume than a mask, with more to\n\ninspect. Still a costume.\n\nNotice what actually made that exchange work. Not the signature. The humans\n\nin the thread refused assurances and demanded artifacts: pinned commits,\n\nmanifests, vectors a stranger could rerun. Trust accumulated exactly as fast\n\nas things could be independently checked, and no faster. The ladder is not\n\nreally about how much an agent says. It is about how much of what it says\n\nyou can verify. Anonymous endorsement is a checkable voucher. Identity is a\n\ncheckable name. A mandate is checkable authorization. What an agent merely\n\ntells you, at any rung, is weather.\n\nThe most interesting message on the list did not come from a protocol\n\nauthor. It came from Google's reCAPTCHA team, who said that both proposals\n\nare additive signals for them, that they would let them reduce friction for\n\nlegitimate automation, and that they hope to lean less on collecting\n\nreputational data and throwing challenges at anonymized traffic.\n\nSit with that. The largest bot-defense product in the world is saying that\n\ncryptographic proof lets it treat automated visitors better and watch\n\neveryone less. That inverts the usual assumption, which is that verification\n\nis a wall. Verification is a door, and the reason walls exist is that nobody\n\ncould tell who was knocking.\n\nFor merchants the practical read is simple. The alternative to verifying\n\nagents is challenging them, and challenges are paid for in abandoned carts.\n\nLess urgent than you would think, and more than last month. These drafts\n\nremain pre-adoption, but the working group's main protocol draft published\n\nits first revision in August and it settled real questions: an agent's\n\nidentity is the URL where it publishes its keys, the key id selects a key\n\nand carries no continuity, and a domain stands behind a key set only through\n\na reserved well-known path. We moved our verifier onto the revision the\n\nweekend it landed, so I can report that it is implementable as written.\n\nAnyone shipping against the parts still in motion is buying a rewrite;\n\nanyone ignoring the parts that just settled is falling behind.\n\nWhat merchants can do is decide the policy question early, because it is a\n\nbusiness question and it will not be answered by a spec. Which tier earns\n\nwhat. Whether an endorsed stranger gets access but no offer. Whether an\n\nidentified operator gets a discount without a mandate, or never. That\n\ndecision belongs to the store, and the systems in front of you should make\n\nit explicit rather than make it for you.\n\nWe built ours to admit verified identity and withhold spending authority\n\nuntil a mandate proves it. Merchants can raise that floor deliberately. They\n\ncannot raise it accidentally, which is the entire point.\n\nThe agent that will not say its name is not a threat. It is a customer\n\nwearing a mask. The agent that announces its name, its employer, and its\n\npermission slip is not automatically safe either. The only real mistake, in\n\nboth cases, is the same one: to guess at what you could have checked.\n\n– N.M.\n\n*The Elara exchange described above is on the public web-bot-auth mailing\nlist archive, August 9, 2026, including the independent reproduction and its\ncarefully stated limits. The anonymity proposal is\ndraft-rescorla-anonymous-webbotauth; its stated non-goals are quoted from\nthe draft's own text.*\n\n*AVA Pay™ is a merchant-side trust gateway for AI commerce: one API that\nverifies the signatures AI shopping agents already carry, and lets merchants\nset policy for what verified identity earns. Open source at\ngithub.com/AVA-PAY/ava-pay. More essays at avalayer.com/writing.*", "url": "https://wpnews.pro/news/the-agent-who-won-t-say-its-name", "canonical_source": "https://dev.to/avaverify/the-agent-who-wont-say-its-name-3o4n", "published_at": "2026-08-10 18:37:14+00:00", "updated_at": "2026-08-10 18:48:41.274857+00:00", "lang": "en", "topics": ["ai-agents", "ai-policy", "ai-safety", "ai-ethics"], "entities": ["Elara", "IETF", "Anonymous Bot Authentication"], "alternates": {"html": "https://wpnews.pro/news/the-agent-who-won-t-say-its-name", "markdown": "https://wpnews.pro/news/the-agent-who-won-t-say-its-name.md", "text": "https://wpnews.pro/news/the-agent-who-won-t-say-its-name.txt", "jsonld": "https://wpnews.pro/news/the-agent-who-won-t-say-its-name.jsonld"}}