Agent identity: what "verified" should mean

“Verified” should always name the claim that was checked and the evidence behind it. For an AI agent there are four separate claims: the agent holds a particular key, a particular organization operates it, it acts for a particular person or company, and it has behaved acceptably so far. Each claim needs different evidence, and a valid proof of one says nothing about the others.

A2A covers parts of the first two. It requires TLS, lets a server declare how clients must authenticate, and lets providers sign their Agent Cards. It does not bind keys to legal entities, define how the represented person is identified, or track reputation. A useful verification result reports each layer separately, with the evidence and the time of the check.

Four claims, four kinds of evidence

Layer	Question	Typical evidence	Proves	Does not prove
Key possession	Did the holder of this key produce the card or request?	Signed Agent Card, HTTP Message Signature, mutual TLS, OAuth client credentials	The sender controlled a private key or secret	Who the sender is in the real world
Provider identity	Which organization runs this agent?	Domain that serves the card or keys, TLS certificate, a trust list that maps keys to organizations	Control of a domain, or a listing by someone you trust	That the organization is honest or competent
Principal	On whose behalf is it acting, and for what?	OAuth token naming a user, a token exchange act claim, a mandate or verifiable credential	That an issuer you trust recorded a delegation	That this action falls inside it, unless the credential says so
Behaviour	Is this agent acting normally?	Request history, rates, abuse reports, outcomes	A pattern over time	Anything certain about the next request

The layers depend on each other. Behaviour data needs a stable identifier to attach to. A delegation is worthless if you cannot tell which agent is presenting it. So verification usually runs bottom-up: authenticate the key, map it to a provider, check the delegation, then apply a policy informed by history.

Layer 1: key possession

Signed Agent Cards

Section 8.4 of the A2A specification lets a provider sign its Agent Card with a JSON Web Signature over an RFC 8785 canonical form of the card. A client that verifies the signature learns two things: the card has not changed since signing, and the signer held the private key. Clients SHOULD verify at least one signature before trusting a card, MAY keep a trusted key store for known providers, and MUST NOT use expired or revoked keys. Signing itself is optional. Signed Agent Cards walks through canonicalization and verification step by step.

A card signature covers the card. It does not authenticate the requests an agent sends afterwards.

Request authentication in A2A

Section 7 treats agents as ordinary web applications. Identity is established at the transport layer, and A2A messages carry no identity fields. The card’s securitySchemes lists what the server accepts: API key, HTTP authentication, OAuth 2.0, OpenID Connect or mutual TLS. The client obtains credentials out of band and sends them with every request, and the server MUST authenticate every request (sections 7.3 and 7.4).

These schemes prove possession of something the server already knows about. An API key shows the caller has the key, and nothing about whether someone copied it. Mutual TLS, and OAuth tokens bound to a client key, tie the credential to a private key that never leaves the client, which narrows that gap.

HTTP Message Signatures and Web Bot Auth

RFC 9421 (February 2024) defines HTTP Message Signatures. The sender signs selected components of an HTTP message, such as the method, authority and path, and sends the result in Signature and Signature-Input headers.

The IETF Web Bot Auth working group builds on RFC 9421 for automated clients that visit websites. Its working group draft, draft-ietf-webbotauth-httpsig-protocol-00, was published on 1 September 2026 and is still an Internet-Draft, with no RFC yet. It adds a Signature-Agent header that points to an HTTPS URL where the agent publishes its public keys as a JWK Set, by default at /.well-known/http-message-signatures-directory on the agent’s origin. Each signature must cover @authority or @target-uri, carry created and expires values, use a JWK thumbprint as keyid, and set tag to web-bot-auth.

Illustrative signed request (a trailing backslash marks a wrapped line):

GET /orders/1042 HTTP/1.1
Host: shop.example
Signature-Agent: sig1="https://agent.example"
Signature-Input: sig1=("@authority" "@path" "signature-agent";key="sig1");\
  created=1790000000;expires=1790000300;\
  keyid="NTbGu3Hb1dtNCfM3Yx0WqRz7s0bq8n2kQv5c9pF1a2E";tag="web-bot-auth"
Signature: sig1=:c2lnbmF0dXJlLWJ5dGVz:

The draft is explicit about what a valid signature shows. The verifier ends up with a pair: the URL it resolved and a key served there. That proves a holder of a published key signed the covered parts of the request. The request can be replayed until the signature expires, unless the signer covers more components or adds a nonce. The signature says nothing about who operates the agent, whether it is benign, or whether the request is authorized (section 4.1). The draft also states that it does not authenticate human users and does not define authorization or delegation (section 4.6).

The working group’s charter scopes the work to automated clients of sites built for people. It lists HTTP APIs and agent-to-agent interfaces as out of scope, along with end-user authentication and tracking bot reputation. Web Bot Auth identifies the crawler or agent visiting your website. It is not an A2A authentication scheme.

Layer 2: provider identity

An Agent Card’s provider object has two required fields, organization and url. Both are self-asserted. Anyone can publish a card that names any company.

Three kinds of evidence narrow this down:

• The domain that serves the card. A2A clients SHOULD validate the server’s TLS certificate against trusted certificate authorities (section 7.2). That shows the card came from the named host. Certificate issuance relies on challenges such as those in ACME (RFC 8555, section 8), which show that the applicant controls the domain name. They do not say which legal entity that is.
• Where the signing key lives. If the card’s jku or a Web Bot Auth key directory sits on the provider’s domain, the key is tied to whoever runs that domain. The Web Bot Auth draft notes that serving keys at a reserved well-known path means the domain operator stands behind them (section 4.5).
• A trust list you choose. A trusted key store, a registry or a contract maps keys and domains to organizations. A2A allows a trusted key store for card verification but defines no registry API, vetting process or accreditation.

The remaining gap is the step from “controls example-freight.com” to “is the Example Freight company in our vendor records”. Lookalike and newly registered domains pass every cryptographic check. Closing that gap takes business evidence: a contract, an onboarding record, or a registry that did the vetting and says so.

Layer 3: the principal

The principal is the person or organization the agent represents. When an agent asks for a refund, a cancellation or a quote on an account, this is the question a business cares about most.

A2A’s enterprise guidance says the authenticated identity may represent an end user, a client application, or both. When a task needs more authority partway through, the agent moves it to TASK_STATE_AUTH_REQUIRED. Section 7.6.4 then leaves the scope, representation, validity and revocation of the resulting credential to implementations and extensions, and says the state change by itself authorizes nothing.

Existing standards fill parts of this layer:

• OAuth access tokens identify a subject and a client, and carry scopes.
• OAuth 2.0 Token Exchange (RFC 8693) defines an act claim that names the party acting for the subject. Nested act claims record a chain of actors.
• AP2 payment mandates carry signed evidence of what a user approved for a purchase.

Web Bot Auth explicitly leaves end-user authentication out. Delegated authority covers these mechanisms in depth.

Layer 4: behaviour and reputation

No key, certificate or token says the agent will behave. The A2A specification tells servers to log authentication failures and suspicious requests, watch for unusual patterns such as rapid task creation, and rate-limit every operation (section 13.4). The Web Bot Auth draft expects websites to log, rate-limit, allowlist or block a resolved Signature-Agent URL the way they treat IP addresses today.

Reputation is only as strong as the identifier underneath it. The same draft points out that an agent can abandon a URL and stand up a new one, and the protocol does not try to prevent this. Behaviour data therefore counts in proportion to how costly the identifier is to replace. A key that a registry vetted is expensive to throw away. A freshly generated key costs nothing.

What A2A defines and what it leaves open

Topic	Defined by A2A	Left to you, an extension or another standard
Transport	HTTPS or TLS required in production; clients SHOULD validate the server certificate	Certificate pinning, client certificate issuance
Request authentication	Schemes declared in securitySchemes; the server MUST authenticate every request	Credential issuance, lifetime, binding to a key
Card integrity	Optional JWS signatures over a canonical card; clients SHOULD verify one	Which keys and key locations you accept
Provider identity	Self-asserted provider field	Binding a key or domain to a legal entity
Principal	TASK_STATE_AUTH_REQUIRED signals the need	Credential format, scope, validity, revocation
Behaviour	Servers SHOULD log, monitor and rate-limit	Reputation data, sharing, scoring

Worked example: a refund request

Illustrative. A retailer’s service agent receives a SendMessage request to refund order 1042. The caller’s Agent Card names “Example Assistant” as its provider.

Check	Result	What the retailer now knows
TLS and OAuth client credentials	Valid token for client ex-assistant	The caller holds credentials the retailer issued to that client
Card signature	Valid, key served from the assistant’s domain	The card is intact and signed by a key that domain publishes
Provider mapping	Domain matches the vendor record from onboarding	The retailer has a contract with this operator
Principal	Token from the retailer’s own authorization server with sub set to customer 88121 and scope refund:order	The customer approved refunds on their orders for this client
Behaviour	Refund volume for this client is within its usual range	No sign of abuse so far

Each row is a separate fact with its own evidence. If the principal check fails, the first three rows still hold, and the right response is to ask for authorization, which is what TASK_STATE_AUTH_REQUIRED is for.

Using the word “verified” honestly

• Name the layer. “Card signature verified” and “provider verified” are different claims. Avoid a single badge that merges them.
• Name the evidence and the time. Record which key, domain and token you checked, and when. Keys rotate and credentials expire.
• Fail closed on unknowns. An unknown key location, an unexpected algorithm, or a delegation that does not cover the action should stop the request or trigger a request for more proof. None of them should pass by default.
• Keep the record. A2A section 13.4 asks for audit trails of sensitive operations. The verification result belongs in that trail.

Emissar’s Verify module is aimed at the provider-identity and behaviour layers: it validates card signatures and signing keys, matches keys to provider records, and assesses requests before returning allow, ask for more proof, or refuse. Its status is In development.