DEV Community: Nick Mathews

The Agent Who Won't Say Its Name

Nick Mathews — Mon, 10 Aug 2026 18:37:14 +0000

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.

Identity Is the Easy Half

Nick Mathews — Mon, 03 Aug 2026 04:20:15 +0000

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

I was setting up a throwaway store to test something unrelated when I found it.
Shopify admin, Online Store, Preferences, near the bottom of a page most
merchants never scroll: Crawler access. Create a signature, hand it to a
tool you trust, and that tool can crawl your store.

I clicked it because the label mentioned Signature-Agent, and Signature-Agent
is not a phrase you encounter by accident. It comes from a set of IETF drafts
about proving which automated client is knocking. Shopify has quietly shipped
them.

What it actually is

The credential Shopify handed me is a genuine Web Bot Auth artifact, not
something merely inspired by one:

Signature-Input: sig1=("@authority" "signature-agent");
  keyid="SjjyXvQ2cGhsRXs9DXEaV6ClyCun0Pj5yxjV67dLGOk";
  nonce="e5hRNIchH...Rqw==";
  tag="web-bot-auth";
  created=1785536199; expires=1788128199
Signature-Agent: "https://shopify.com"

You can check the interesting part yourself in about ten lines. Shopify
publishes a key directory at
https://shopify.com/.well-known/http-message-signatures-directory (follow
the redirect to the www host), served with the right content type, containing
one Ed25519 key. Take that key, compute its RFC 7638 thumbprint, and compare
it to the keyid in the signature above. They match. We confirmed it with two
of our own toolchains, which is not the same as two organizations confirming
it, so do it yourself: canonical JSON of crv, kty, and x, SHA-256,
base64url, no padding.

That is a real deployment of a draft standard, in production, on a store I
made in four minutes on the cheapest plan. Whatever else is true, the
plumbing is here.

The part worth reading carefully

Look at what the signature covers: @authority and signature-agent. The
path is not covered. The method is not covered. The body is not covered. And
it is valid for thirty days.

So this is not the agent proving who it is on each request. It is Shopify
signing a statement that whoever holds these three headers may crawl this
store, and the merchant handing that statement to a tool. Possession is the
whole story. The crawler's own key appears nowhere.

That is a completely reasonable design for the problem it solves, which is
let this specific tool I already know about through my front door. It is a
capability token wearing a verification protocol's clothes. I want to be
precise about that rather than snide, because the distinction is the entire
subject of this essay.

What the merchants are actually doing

We run a scanner that probes sites the way an AI shopping agent would,
identifying honestly as ClaudeBot and GPTBot and recording what comes back.
Across the twenty-two sites scanned so far, small national retailers to
one-person service businesses:

Sixteen let every automated visitor in.
Five blocked them all, by hard 403 or a CAPTCHA gate.
One we could not determine, and we say so rather than guess.
Zero distinguished between agents.

Twenty-two is a small number and I am not going to dress it up as a survey.
But the shape is worth sitting with, because the two ends of it are the same
decision made in opposite directions. Blocking everything and trusting
everything are both what you do when you cannot tell who is knocking.

None of this is because the tools do not exist. robots.txt has expressed
per-agent rules for years, and user-agent allowlists are older than that.
Every site in that sample could have written a rule naming an agent. The
problem is that those mechanisms are advisory and unauthenticated: any client
can type any name into a user-agent header, and nothing stops it. Asking a
stranger who they are, and believing the answer, is not a security control.
It is a formality.

What is new is cryptographic proof of which agent is knocking. That is what
Shopify shipped, and it is genuinely useful.

And then the question nobody answered

Here is where it gets interesting, and where I think the industry is about to
spend a few confused years.

Suppose the proof works. Suppose the agent at your door is verifiably
ChatGPT, or verifiably a shopping assistant from a company you have heard of.
Now what?

Nothing in that admin screen tells you. Nothing in the drafts tells you
either, and that is correct, because it is not their job. Identity is a
protocol question and it has protocol answers. What a verified visitor should
earn is a business question, and it has only business answers.

Should a verified agent see your prices? Get your discount? Be allowed to
complete a purchase, or only to fill a cart a human confirms? Does an agent
that proves its operator, but carries no evidence that a customer authorized
this specific purchase, get the same treatment as one that does? Those are
five different policies and a store could reasonably choose any of them.

Most stores have chosen none, because most stores have not been asked. They
were handed a lock and no instructions about what it should keep out.

The half that is easy, and the half that is not

There is a temptation, once identity is solved, to treat the rest as a
detail. It is the opposite. Identity has a right answer that mathematics can
check. Policy has only tradeoffs: revenue against risk, convenience against
control, openness against abuse, each weighted differently by every merchant
who ever priced a product.

We build the second half. That is not a coincidence in this essay, and I
would rather say so plainly than pretend I stumbled into the observation
neutrally. Our whole product is the sentence a verified identity is not
spending authority until something proves a buyer authorized it, and we hold
that line even when it costs a conversion, because a trust layer that rounds
up is not a trust layer.

But the point survives without us. A merchant who never installs anything we
make still has to answer the question, and the answer is still theirs. The
worst outcome is not choosing wrong. It is having the choice made
accidentally by whichever default happens to be shipping that quarter.

Shopify gave every merchant a key. What it unlocks is still up to them, and
almost none of them know they are holding it.

– N.M.

Method note: probes identify honestly as ClaudeBot and GPTBot and record
robots.txt directives alongside live response codes. Verdicts use the last
clean observation per domain; rate-limited and unreachable probes are
excluded rather than counted as blocks, since an inability to observe is not
an observation. Our own repeat scanning of one domain triggered its rate
limiter, which is how we found that distinction mattered.

These findings were reported to the IETF web-bot-auth working group on
August 1, 2026, before publication.

The Signature Base Visa Didn't Specify

Nick Mathews — Mon, 20 Jul 2026 04:30:37 +0000

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

Verification is a strange business. What you're selling, when you get down to it, is certainty about other people's promises. So when we built a merchant-side verification layer for AI shopping agents, we made ourselves a rule: implement every protocol to its public-spec depth, validate against live production key material, and wherever we couldn't be certain, say so out loud. This essay is about the one place that rule got interesting.

Some background. Our API accepts a signed request from any AI agent and returns a verdict: trusted or not, with a typed reason. To say that honestly we implemented four protocols, including Visa's Trusted Agent Protocol. Most of that work went the way implementation work should go. The spec says a thing, you build the thing, the tests pass, and cryptography does what cryptography does. Cryptography is the reliable half of this industry. The unreliable half is agreement. A specification is an agreement about reality between people who have never met, and like most such agreements, it holds right up until someone reads it carefully.

Three layers, two of them clean

Visa TAP is a three-layer protocol. The outer layer is an RFC 9421 HTTP message signature binding the agent's identity and intent to a specific merchant and path. The middle layer is a Consumer Recognition Object carried in the body, including a Visa-signed identity token you can verify against Visa's published JWKS at mcp.visa.com. The inner layer is an Agentic Payment Container, also signed.

Layers one and two were a pleasure. RFC 9421 is a mature spec with a defined signature base, worked examples, and years of implementation scar tissue behind it. The identity token verifies against a live public key set; we pulled Visa's production JWKS, resolved their real RSA key, and verified real signatures. When a spec gives you that much to push against, independent validation is possible, and independent validation is the whole game.

Layer three is where we met the sentence.

One sentence, four questions

The signed body objects need a signature base: the exact byte string that gets signed and verified. The public spec describes it in a single sentence, saying the base is "a canonical representation of all fields in the object in the order received," excluding the signature field itself.

That sentence is doing the work of a chapter, and it answers none of the questions an implementer actually has:

Rendering. Is each field raw JSON? A name and value pair? Are strings quoted or bare?
Nested values. Compact or pretty printed? Keys reordered or preserved?
Joining. Newlines between fields? A trailing one or not?
Ordering. "Order received" presumably means insertion order, but not every language keeps its promises about that.

Here is the trap. The sentence isn't wrong. That's the problem. Wrong would be visible. Any reasonable answer to those four questions produces a working implementation. Sign with your answer, verify with your answer, and every test passes. Your implementation is correct. So is everyone else's. Everyone is correct alone, the way two people can both be on time for a meeting scheduled in different time zones.

The signature base never travels on the wire. It exists briefly in the signer's memory and the verifier's memory, and if those two constructions differ, no error message will ever say so. What you get instead is cryptography's entire emotional range: invalid signature. When the mismatch finally surfaces, months from now, between two teams who each shipped a perfectly self-consistent product, it will look like a bug. It won't be a bug. It will be a disagreement that nobody knew they were having.

We looked for the artifact that would settle it. The developer documentation has no worked example. The sample repository shows signed objects but never the bytes that were signed. No test vector exists. As far as we can tell, there is no public object in the world against which two independent TAP implementations can prove they agree.

What we did about it

Three things, in increasing order of usefulness to everyone else.

First, we picked an interpretation and labeled it as one. Our reading mirrors the RFC 9421 base style: one name and value line per field in insertion order, strings bare, everything else compact JSON, newline joined. It lives in a single function shared by our signer and our verifier, so our round-trip is exact, and if Visa ever publishes a normative answer that differs, the fix is one function. Quarantine your guesses. Give each one an address.

Second, we wrote the uncertainty into our public docs instead of around it. Our README says the construct is under-specified and points at the function holding our interpretation. The alternative, quietly guessing while selling certainty, is the kind of contradiction customers eventually find.

Third, we filed a public issue on Visa's repository asking for the one artifact that resolves all four questions at once: a sample object, its exact signature base string, and a valid signature under a published test key. We offered to contribute test vectors ourselves if our interpretation matches their intent. That issue lives at github.com/visa/trusted-agent-protocol/issues/23, and if you're implementing TAP, you're welcome in it.

The general lesson

Test vectors are as normative as prose. More, honestly, because prose can be ambiguous in ways nobody notices until it's expensive, and a byte string cannot. Prose is where a spec makes its promises. Test vectors are where it keeps them.

Ambiguity in a spec is a loan, and the interest is paid by whoever implements second. Right now the agentic commerce space is taking out a lot of these loans: Visa's TAP, Google's AP2, the IETF's Web Bot Auth drafts, EMVCo's credential schemas, all being written in public, at speed, mostly before any two independent implementations have met. That meeting is where specs are actually tested, and almost none of them have happened yet. When we submitted comments on EMVCo's draft schema framework this month, our first request was the same one we made to Visa: ship the worked example with version one, not after the divergence.

If you're writing a spec in this space: publish one complete sample, the exact bytes that get signed, and a signature under a test key. It's an afternoon of work that forecloses years of silent incompatibility. If you're implementing one: when you find a sentence doing the work of a chapter, don't just pick an answer. Isolate the guess, name it a guess, and say so where the next implementer will trip over it. Being loud about ambiguity is cheap exactly once, at the beginning. We're at the beginning.

That's the discipline we're trying to hold ourselves to, anyway. Verification is a trust business, and a trust business that rounds up isn't one. Where the spec is precise, we're precise. Where it isn't, we say so, in public, and we ask.

Trust is not built where everyone agrees. It's built where someone admits they aren't sure, and shows their work.

– N.M.

AVA Pay™ is a merchant-side trust gateway for AI commerce: one API that verifies the signatures AI shopping agents already carry (IETF Web Bot Auth, Visa TAP, Google AP2) and lets merchants set policy for what verified identity earns. The verifier, SDK, and all 240 real-cryptography tests are open source at github.com/AVA-PAY/ava-pay. More essays at avalayer.com/writing.