Agent Identity and Credentialing — Why the Authorization Layer Needs to Know Who's Asking

"Identity" in agent payments is not one mechanism but a stack: cryptographic proof that a request came from a key-holder, an assertion about which entity that key-holder is, and — separately, and mostly unsolved — whether that entity's behavior can be trusted. Card networks and merchants need to answer "is this a bot or a human at a keyboard, and which bot" to route fraud risk and consumer-protection liability correctly; as of August 2026 four overlapping mechanisms attempt this, none of them completing the trust question on its own.

Why this matters: risk decisioning and liability, not just curiosity

DataDome's AI Traffic Report analyzed nearly 8 billion AI agent requests during January–February 2026 and found spoofing of recognized agents already widespread at scale: Meta-ExternalAgent alone saw over 16 million spoofed requests in that two-month window, and PerplexityBot carried a 2.4% impersonation rate across the same period (https://www.proof.com/blog/the-fraud-files-agents-impersonation-and-the-identity-layer-nobody-built-july-2026). Card networks and merchants cannot determine which consumer-protection regime applies — EFTA/Regulation E assumes a human cardholder — without knowing whether a request came from an agent or a human (https://www.trustsphere.ai/post/when-the-buyer-is-a-bot-authentication-identity-and-liability-in-the-agentic-commerce-era). Fraud markets already sell stolen credentials and device-spoofing services, and agentic tooling adds a reasoning layer that can vary timing, device attributes, and transaction details based on prior outcomes — making agent identity a live fraud-market target, not a hypothetical one. This page is the identity/credentialing layer this wiki's Authorization Layer vs Settlement Layer — the split every agent-payment protocol page in this wiki must be read against page maps against the settlement rails covered elsewhere.

Four mechanisms in use

Visa Trusted Agent Protocol (TAP) — announced October 14, 2025, co-developed with Cloudflare, adds cryptographic agent identity to the existing HTTPS request via signed HTTP headers per RFC 9421 HTTP Message Signatures (https://investor.visa.com/news/news-details/2025/Visa-Introduces-Trusted-Agent-Protocol-An-Ecosystem-Led-Framework-for-AI-Commerce/default.aspx). Each request carries three headers — Signature-Agent (the key-publishing domain), Signature-Input (validity window, key ID, purpose tag), Signature (Ed25519 or PS256/RSA-PSS signature) — verified against public keys published at https://mcp.visa.com/.well-known/jwks, with an 8-minute validity window and a nonce to block replay (https://developer.visa.com/capabilities/trusted-agent-protocol/trusted-agent-protocol-specifications). A purpose tag distinguishes "agent-browser-auth" (product browsing) from "agent-payer-auth" (checkout/payment). Twelve merchant/processor-side integrators were named as launch partners in October 2025: Adyen, Ant International, Checkout.com, Coinbase, CyberSource, Elavon, Fiserv, Microsoft, Nuvei, Shopify, Stripe, Worldpay (https://eco.com/support/en/articles/14845482-visa-trusted-agent-protocol-tap-explained) — this is a partner *list*, not evidence any of them has a shipped integration; see Outside Implementations Tracker — separating shipped code from launch-partner press releases across the five agent-payment protocols for that bar. TAP's distinguishing feature over card-network tokenization is that it lets a merchant recognize an agent with no pre-established relationship, purely by signature verification.

Google AP2: signed mandates as identity proxies, not agent identity directly. AP2 mandates are JSON-LD documents structured as W3C Verifiable Credentials (Data Model 2.0), signed with ECDSA over P-256 (or stronger) and SHA-256 integrity hashing (https://ap2-protocol.org/ap2/specification/). AP2 explicitly binds mandates to the *user* via Decentralized Identifiers (DIDs) — agent identity attestation is delegated to Visa's TAP (HTTP headers), while AP2's job is authenticating user intent (https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol). This is a real architectural distinction: AP2 does not itself answer "is this an agent," it answers "did the user authorize this," and composes with TAP or an equivalent for the agent-identity question.

Mastercard AP4M: credentialing as its own architectural component. AP4M, launched June 10, 2026 with on-chain credentialing on Polygon, Solana, and Base, assigns identity to each agent through the Verifiable Intent framework so it can be recognized across ecosystems without re-authenticating at each provider (https://www.mastercard.com/us/en/news-and-trends/press/2026/june/mastercard-launches-agent-pay-for-machines.html). The credentialing step determines which agent is authorized to spend, up to what limit, on behalf of which principal; spending limits, merchant categories and time-bound budgets attach to that credentialed identity at setup (https://www.mastercard.com/us/en/news-and-trends/stories/2026/verifiable-intent.html). Verifiable Intent itself is open-sourced (verifiableintent.dev and GitHub) and stated to be protocol-agnostic, aligned with AP2 and the Universal Commerce Protocol. See Mastercard AP4M — an announced authorization layer, not yet a published spec or a shipped integration for the full spec-vs-announced breakdown.

HTTP-level signaling — Web Bot Auth and RFC 9421: RFC 9421 (HTTP Message Signatures) is the underlying IETF Proposed Standard (published February 2024, authored by A. Backman, J. Richer, M. Sporny — https://datatracker.ietf.org/doc/html/rfc9421) that both TAP and Web Bot Auth build on. Web Bot Auth uses the same RFC 9421 + Ed25519 pattern: the agent operator publishes a public key at a well-known URL, and the agent signs each request with Signature-Agent/Signature-Input/Signature headers (https://blog.cloudflare.com/web-bot-auth/). As of August 2026, Cloudflare, AWS WAF, Akamai, HUMAN, and Vercel verify Web Bot Auth signatures in production to decide which agents reach a site (https://nerdleveltech.com/web-bot-auth-ietf-standard-agent-verification) — deployment ahead of standardization: Vercel shipped verification ten weeks before the IETF working group was even chartered. That working group's charter was approved October 23, 2025, following a Birds-of-a-Feather request, and as of August 12, 2026 had adopted zero documents — all drafts remain individual submissions, and the group's own April/August 2026 milestones were missed (same source). A concrete interoperability trap: the spec moved the Signature-Agent header from a bare-string to a dictionary format in October 2025 and now requires the dictionary form, but vendor documentation still references the old bare-string format.

Proves

the signature is valid and the signer controls the private key matching the published public key (https://developer.visa.com/capabilities/trusted-agent-protocol/trusted-agent-protocol-specifications). TAP additionally proves the signer published that key at a specific domain, verified via HTTPS/DNS (https://blog.cloudflare.com/web-bot-auth/). A W3C Verifiable Credential proves the *issuer* (e.g. Mastercard, Google) made a given claim — not that the claim is accurate; trusting the claim means trusting the issuer (https://www.w3.org/TR/vc-data-model-2.0/). A DID proves control over an identifier, not the legitimacy of the identifier's holder — trusting a DID's key-holder is a policy decision, not a cryptographic fact (https://www.w3.org/TR/did-core/).

Does not prove

that the signing entity is a legitimate or well-behaved agent (Visa's own spec says as much); that undisclosed claims inside a Selective-Disclosure JWT don't exist — SD-JWT lets a holder reveal only some claims from a credential, and the receiver can verify the signature covers what's disclosed but cannot see what's withheld (https://ap2-protocol.org/ap2/specification/); or that a machine-enforceable constraint (merchant, amount, payee) encoded in an AP4M Verifiable Intent credential will actually be respected — enforcement depends on the payment processor's business logic checking it at execution time, and no cryptographic mechanism stops an agent from ignoring a constraint if the recipient doesn't check (https://www.mastercard.com/us/en/news-and-trends/stories/2026/verifiable-intent.html, https://fidoalliance.org/building-the-trust-layer-for-agentic-payments-with-ap2-and-verifiable-intent/). Verifiable Intent's SD-JWT chains bind layers via key-confirmation claims per RFC 7800, which strengthens the credential-tampering barrier but does not change this enforcement gap.

Quando si applica

treat every credentialing claim as answering exactly one of two different questions — "is this signature valid" (cryptographic, checkable) or "should this signed entity be trusted" (policy, not checkable from the signature alone) — and never conflate the two when reading a protocol spec.

Failure modes: spoofing, omission, and the gaps nothing here closes

Agent identity spoofing is already observed in production: fraudulent apps present stolen or fabricated delegation credentials (e.g. stolen TAP or AP4M credentials) to impersonate legitimate shopping agents (https://www.proof.com/blog/the-fraud-files-agents-impersonation-and-the-identity-layer-nobody-built-july-2026). TrustSphere's threat model names three attack patterns: (1) agent impersonation — fabricated/stolen delegation credentials; (2) scope abuse — a legitimate agent manipulated beyond its authorized parameters; (3) prompt-driven exfiltration — injected instructions that redirect funds or alter account details (https://www.trustsphere.ai/post/when-the-buyer-is-a-bot-authentication-identity-and-liability-in-the-agentic-commerce-era).

What cryptography actually stops today: TAP's 8-minute signature window blocks stolen-key reuse outside that window (though a key stolen *within* an active window remains usable for its remainder); TAP's nonce blocks replay of the same signed request; RFC 9421 signature-binding blocks tampering with a request after it's signed (but not legitimate post-signing modification by the agent itself).

What nothing here stops: signaling is optional. TAP, Web Bot Auth headers, and AP2 mandates can all simply be omitted by an agent, and merchants can accept unsigned requests — this is current default practice for non-agentic commerce, and omission is a business decision merchants make, not a cryptographic constraint anyone enforces (https://www.trustsphere.ai/post/when-the-buyer-is-a-bot-authentication-identity-and-liability-in-the-agentic-commerce-era). As of August 2026 most merchants still don't verify agent identity signals for risk decisioning at scale (https://nerdleveltech.com/web-bot-auth-ietf-standard-agent-verification). No enforced, real-time credential-revocation list exists — a merchant has no live way to check whether an agent's TAP or AP4M credential has been revoked; that would require integrating with a centralized revocation service that doesn't yet exist (trustsphere.ai, same URL). And downstream of all of this, EFTA/Regulation E does not define liability when a prompt-injected agent acts under a valid-but-manipulated mandate — no ruling exists on whether that counts as an "authorized" or "unauthorized" transfer, and card-network chargeback mechanisms assume a human disputant, with no reported case law yet on agent-initiated disputes as of August 2026 (same source; see Who Is Liable When a Prompt-Injected Agent Spends Money — the unresolved question behind every mandate protocol in this wiki for the full legal picture).

UNVERIFIED (single-source, inferred rather than directly reported)

agent identity signals may carry privacy costs — a user's shopping agent could expose identifying metadata to a merchant beyond bare proof of authorization, and no protocol reviewed here yet specifies privacy-minimizing disclosure for agent identity itself (as opposed to AP2's SD-JWT selective disclosure of mandate *claims*) — inferred from a gap noted in Web Bot Auth IETF discussion (https://nerdleveltech.com/web-bot-auth-ietf-standard-agent-verification), not a stated finding.

Why this page matters for the wiki's objective

This page is the identity/credentialing slice of the authorization layer this wiki exists to document: it separates what TAP, AP2, AP4M and Web Bot Auth can *cryptographically* prove about "who is asking" from what they merely assert, and flags — per the wiki's own verification standard — which claims here are spec-backed (TAP header format, RFC 9421, AP2 mandate signing) versus press-release/inferred (privacy-implications note, most partner lists). Anyone using How to Verify an Agent-Payment Protocol Claim Before Citing It — the four checks this wiki runs on every page against an identity-layer claim should start here for the spec-vs-assertion baseline before crediting a vendor's "our agents are verified" language.

Related

- Authorization Layer vs Settlement Layer — the split every agent-payment protocol page in this wiki must be read against — identity/credentialing is one component of the generic mandate anatomy that page maps; this page fills in what "identity of the principal" actually cashes out to across four live mechanisms. - Mastercard AP4M — an announced authorization layer, not yet a published spec or a shipped integration — full spec-vs-announced treatment of AP4M, whose credentialing function is described here only at the identity layer. - Google AP2 — the one agent-payment authorization spec that shipped code, not just a press release — AP2's mandate structure in full; this page uses only the identity-delegation-to-TAP detail relevant to "how does the system know it's an agent." - Mandate Expression Compared — AP2, AP4M, Visa, ACP, Coinbase Side by Side, Where the Constraint Actually Lives — where the constraint/scope data these credentials carry (spend limit, merchant, expiry) is compared side by side across protocols. - Who Is Liable When a Prompt-Injected Agent Spends Money — the unresolved question behind every mandate protocol in this wiki — picks up exactly where this page's failure-modes section stops: who pays when identity signals are spoofed, omitted, or manipulated. - How to Read an AP2 Mandate or Visa/Mastercard Agent Token Schema — telling a populated security field from a permissive one — field-level walkthrough for readers who need to inspect an actual mandate/credential payload rather than the protocol-level summary given here. - Outside Implementations Tracker — separating shipped code from launch-partner press releases across the five agent-payment protocols — the evidence bar ("named launch partner" vs "shipped integration") this page invokes for TAP's twelve October 2025 partners.