Is OAuth enough to verify an AI agent?

The short answer

No, and it was not built to. OAuth decides what a client may do: an access token tells your API that a server you trust issued it, with which scopes, until when, and often which person agreed, but not which agent is holding it, which company runs that agent, or whether the request changed on the way. Keep OAuth and your identity provider for those jobs, and add a signed agent card and a signature on each request for the rest; Pidgeon is the format and the check for that part, and never the authorisation.

What an access token tells your API

When a request arrives with Authorization: Bearer …, your API learns a few things, and they are the right things for its question, which is whether this call may go ahead:

• It was issued by an authorisation server you trust, because the token verifies against that server's key or because introspection says it is active.
• What it covers: the scopes, the audience and the expiry.
• Which client asked for it, as the client registered itself.
• Often, whose resources it reaches: the sub of the person or account that agreed.

That is authorisation, and OAuth does it well. Nothing below argues for replacing it.

What it does not tell your API

• Which agent is calling. One person's token, or one client registration, is often shared by every agent that person runs. Two agents with the same token are the same caller to your API, and revoking one revokes both.
• Whether a person or software is behind it. A token a person agreed to looks the same whether they use it or their agent does.
• Who stands behind the client. A client's name and details are what it said when it registered. With dynamic registration, any software can register under any name. Nothing in the token points at a domain an outsider can check.
• That the request is the one the agent sent. A bearer token works for whoever holds it. Sender-constrained tokens, such as DPoP, bind a token to a key, which stops a stolen token being replayed; they still do not say whose key it is.
• Anything outside your own system. A token your server issued means nothing to a vendor's API, and an email carries no token at all.

What a card and a signature add

An agent card answers who. It is a JWS signed under a key its domain publishes, and it names the agent's address and stable sub, its kind, the operator domain the company proved, who it acts for in on_behalf_of, and a coarse standing. What is an agent ID? walks through one claim by claim.

A signature on each request answers whether the request is what the agent sent. Post signs HTTP requests with HTTP Message Signatures (RFC 9421) in the profile of Cloudflare's Web Bot Auth: tag web-bot-auth, keyid the key's JWK thumbprint, valid for five minutes. It covers the method, the host, the path and query, Signature-Agent (https://post.acme.com), the agent's address as From, and the body's Content-Digest. A receiver that already checks Web Bot Auth signatures needs nothing new; Post adds the address and the card beside the signature.

Your API can hand the request it received to the verifier, with no key:

curl -X POST https://pidgeon.ai/api/v1/verify \
  -H 'content-type: application/json' \
  -d '{
    "request": {
      "method": "POST",
      "url": "https://api.you.com/v1/refunds",
      "headers": { "signature-input": "…", "signature": "…", "signature-agent": "…", "from": "support-agent@acme.com", "content-digest": "…" },
      "body": "{\"order\":\"A-1\"}"
    }
  }'

The answer has the verdict (verified, caution, failed or unsigned), the sender, the operator with whether its domain is verified, and the agent's card. A From counts as the sender only when it is at the domain whose key verified the signature.

How the two fit in one request

The access token and the signature travel side by side, each answering its own question:

So a refund call can be allowed by the token's scope, and logged against support-agent@acme.com, operated by acme.com, acting for Acme Ltd. When that agent misbehaves, you can block that agent and leave the person's other agents alone, because you know it is that agent.

The costs

• The agent holds a key. With pidgeon id the key is made on the operator's machine and Pidgeon only ever sees the public half. Losing it means proving the domain again with a new one.
• The signature lives for five minutes. Clocks need to be roughly right on both sides.
• The public verifier is limited per IP: 300 checks an hour. An API taking agent traffic at volume checks signatures itself, against the keys at https://post.<domain>/.well-known/http-message-signatures-directory, and fetches the card from the agent's post.<domain>.
• The signature does not cover your Authorization header. It binds the request to the agent, not the token to the agent. Binding the token is DPoP's job.

One token that carries both

Sign in with Pidgeon is coming soon. It uses OAuth token exchange (RFC 8693): the agent presents its card in a signed request, and gets an ID token for your site whose sub is the agent, and an access token for your API that can name the agent in its act claim and who it acts for in its sub. Your identity provider and your scopes stay where they are. Until it ships, the verifier above is the way to check an agent, and it works today.

When OAuth is enough

If your agents call only your own APIs, each with its own client registration, and nobody outside needs to know which agent did what, scopes and rate limits may be all you need. The gap opens when an agent reaches an API whose owner did not issue its credentials, or when one person's token is doing the work of several agents.

Start

Checking a message has every verdict and warning. Agents shows the card and how to issue one. The protocol is Post, the draft both formats come from. To hear when Sign in with Pidgeon ships, join the list on its page.