What is agent identity in agentic commerce?

It is which agent is at the checkout, which company runs it and who it is buying for. Whether the payment may go through is a separate question for the card network, the issuer and the merchant.

How does Pidgeon relate to Visa Trusted Agent Protocol and Mastercard Agent Pay?

Both build on Web Bot Auth, according to Cloudflare's post Securing agentic commerce, read 4 November 2026. Pidgeon agents sign their requests in the same profile and add a card saying who runs the agent and who it acts for.

Does Pidgeon approve agent payments?

No. Pidgeon is the format and the check for identity. It holds no payment credentials and never decides whether a payment goes through.

What happens when an agent's identity is revoked?

Its card answers 404 from then on and the address is never issued again. A copy somebody fetched earlier lapses within a day.

Agent identity for agentic commerce

The short answer

Agentic commerce needs two answers kept apart: identity, meaning which agent is at the checkout, which company runs it and who it is buying for, and spending authority, meaning whether this payment may go through, which stays with the card network, the issuer and the merchant. Pidgeon answers the first and only the first: every agent gets a signed card anyone can check, and its requests are signed in Web Bot Auth's profile, which Visa's Trusted Agent Protocol and Mastercard Agent Pay build on. Whether the agent may pay is never Pidgeon's call.

Two questions at the checkout

When a person buys something, the merchant asks two things, usually without noticing it is two. Is this the person they claim to be? And will this card pay? The first is the account and its sign-in. The second is the card network and the bank behind the card.

An agent splits those further. The merchant now wants to know:

Which agent is this? Not "a bot", but a particular agent that can be told apart from every other one.
Who stands behind it? The company that runs it and answers for what it does.
Who is it buying for? The person or company whose money it is.
May this payment go through? The limit, the card, the fraud check, the merchant's own rules.

The first three are identity. They are true of the agent whatever it is buying, and they should be the same answer at every shop. The fourth is authority, and it belongs to whoever carries the risk of the payment. Mixing them is how you end up with an identity system that tries to approve payments, or a payment system that has to guess who the agent is.

What the payment protocols already do

Cloudflare's post "Securing agentic commerce" (read 4 November 2026) describes Web Bot Auth as the base layer: an agent signs its HTTP requests with HTTP Message Signatures (RFC 9421) and a public key, and both Visa's Trusted Agent Protocol and Mastercard Agent Pay are built on it.

A signature like that proves which key signed the request, and that nothing it covers changed on the way. That is the first question. It does not by itself say which company stands behind the agent or who it acts for. That is the gap an agent ID fills, and it is why Pidgeon signs in the same profile rather than a new one.

What the identity layer adds

A Pidgeon agent has a card: a compact JWS, signed by its issuer, that anyone can fetch with no key. It says:

address: the agent, buyer@acme.com. One domain can run many agents, and each has its own card.
kind: agent, or service for software with no agent behind it.
on_behalf_of: who it acts for, as the company set it.
operator: the domain that runs it, and verified: true only when its owner proved the domain.
reputation.standing: new for its first 30 days, restricted while it is suspended, else established.

The agent signs its requests with the key the card names. The merchant checks the request with any Web Bot Auth verifier, or sends it to Pidgeon's verifier and gets the card back with the verdict:

curl -X POST https://pidgeon.ai/api/v1/verify \
  -H 'content-type: application/json' \
  -d '{"request": {"method": "POST", "url": "https://shop.example/checkout", "headers": {"…": "…"}, "body": "…"}}'

The answer's verdict says whether the signature held, sender.address names the agent when the signed From is at the signing domain, and operator and card say who runs it. Nothing sent is stored.

Two more properties matter at a checkout:

Revocation is immediate. A revoked card answers 404 from then on, and the address is never issued to anybody else, so a new agent cannot inherit an old one's history. A copy fetched earlier lapses within a day.
Every card is public. Each card issued, changed or revoked is an entry in an append-only log (GET /v1/log/head), the way Certificate Transparency logs certificates. A company can watch it for cards that claim its name.

Where Pidgeon stops

Pidgeon is the format and the check. It is not the identity provider and not the authorisation:

It does not decide whether the agent may pay. That is the network, the issuer and the merchant, through whatever their payment protocol says. A verified request from an established agent is still a request the merchant may refuse.
It does not replace the company's identity provider. The company decides which agents exist and what they may do; Pidgeon defines what the ID says and lets anyone check it.
It does not hold card numbers or tokens. Nothing in a card is a payment credential.

Post's draft also defines a grant: a signed statement from the person or company an agent acts for, naming what it may do, for whom and until when. A recipient checks a grant beside the verdict and the grant never changes the verdict. It is the grantor's word, not a payment authorisation. Grants a person gives, and the page where they see and revoke them, are being built. Letting an agent with no account sign up or sign in at a shop, Sign in with Pidgeon, is coming soon.

A merchant's check, in order

Is the request signed, and unchanged? A Web Bot Auth verifier answers this, Pidgeon's or another.
Which agent, run by whom, for whom? Read the card: address, operator.verified, on_behalf_of, standing.
May it pay? Hand over to the payment protocol and your own rules, with the agent's identity as one input among the rest.

Step 2 is the one that should not depend on which payment protocol the agent happens to use. The same card answers it at a checkout, in an email to your support desk, and in a call to your API.

When you would not need this

The agent uses the person's own browser session. Then the merchant sees the person, as it always has. Nothing says an agent was involved, which is the problem this layer exists for, but it is not one an ID can solve from the merchant's side alone.
One known partner. If a single integration calls your API with a key you issued, that key already says who it is.
The payment protocol already names what you need. If a network's agent programme gives you everything your risk team asks for, an extra card adds a second answer to a settled question.

Start

Agents shows what a card says and where anyone fetches it. Checking a message has the verdicts, which are the same for a signed request. To give your own agents cards, start with the quickstart; the open protocol underneath is on the protocol page.