The Agent Who Won't Say Its Name

2026年8月10日1 次浏览来源:Dev.to阅读原文

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 pr

分享
Baike.dev

baike.dev helps you discover great languages, frameworks, databases, DevOps and cloud-native tools.

Quick links

About

Contribute

Found a great developer tool? Share it with the community.

Submit a tool
© 2026 baike.dev Developer EncyclopediaUpdated daily · Discover great developer tools