AP2 Verifiable Mandates Explained: The Cryptographic Backbone of Trustworthy Agent Payments

_Last updated: 2026-06-10_

AP2 verifiable mandates are structured digital credentials, built on the W3C Verifiable Credentials standard, that cryptographically prove an AI agent is authorized to make a specific purchase. Each mandate is signed by the authorizing party, travels with the transaction, and can be verified independently without calling back to a central authority. They're the mechanism that turns "the agent says it's authorized" into "anyone can prove it is."

Key takeaways

• AP2 mandates use W3C Verifiable Credentials (the same open standard used in digital identity), so any party that understands the format can verify them.
• Every mandate has four components: issuer, subject, payload, and cryptographic signature.
• AP2 defines three mandate types in sequence: Intent (what the agent wants to do), Cart (what it wants to buy), and Payment (authorization to charge).
• Mandates prove authorization happened; a real-time policy layer like Shatale's determines whether authorization should apply right now, against current budget and rules.
• Together, mandates and authorization-time policy close the two gaps that create agent payment liability: "was this agent ever allowed?" and "was it allowed at this specific moment?"

What is a W3C Verifiable Credential, and why does AP2 use it?

A W3C Verifiable Credential (VC) is an open, cryptographically signed data format designed to let one party prove a claim to another without either party needing to trust a shared central database. The data model is a formal W3C Recommendation (v1.0 in 2019, v2.0 in May 2025) and is widely deployed in digital identity systems.

AP2 adopts VCs because agent payments have the same verification problem as identity: a merchant or payment processor receiving an agent's purchase request needs to know the agent is actually authorized, without having to call back to the operator or the user in real time to confirm. A signed mandate resolves that. It's self-contained proof.

The format is not proprietary. Any system that understands the W3C VC standard can parse and verify an AP2 mandate. That's the point: it creates interoperability at the authorization layer rather than locking verification into a Google-controlled API.

What are the four components of every AP2 mandate?

Every AP2 mandate has the same structural skeleton:

Issuer. The entity that created and signed the mandate. Typically the user or, in enterprise deployments, the organization's authorization system acting on the user's behalf. The issuer's cryptographic key signs the credential. Anyone who trusts that key can verify the mandate's authenticity.

Subject. The agent receiving the authorization. In AP2, the subject is identified by the agent's credential or identity, not by a human-readable name alone. This is what binds the mandate to a specific agent rather than to "whoever presents this document."

Payload. What the agent is authorized to do. This includes the scope of the authorization: merchant categories, spend limits, time windows, and any specific constraints the issuer chose to set. The payload is specific enough to serve as a policy document. "Authorized to spend up to $500 on SaaS tools before June 30, 2026" is a valid payload.

Cryptographic signature. The issuer's digital signature over the credential. If the mandate is modified after signing, even a single character change to the spend limit, signature verification fails. That's what makes mandates tamper-evident.

This four-part structure is identical across all three mandate types. What varies is the payload content.

What are Intent, Cart, and Payment mandates?

AP2 defines three mandate types for the natural stages of a purchase:

Intent mandate. Issued at the start of a workflow. It establishes general authorization for the agent to explore purchases in a category (browse, compare, negotiate) without those actions being unauthorized. The payload specifies the category, issuer, subject, and validity window.

Cart mandate. Issued when the agent has identified a specific purchase. The payload becomes concrete: specific merchant, item, amount. This is the bridge between general intent and a payment request. It's also where a control layer can intercept if the cart exceeds the Intent mandate's scope.

Payment mandate. The final credential authorizing an actual charge. It references the Cart mandate, specifies the exact amount, and is what a payment processor or card network checks at the authorization moment.

The three-mandate chain produces an auditable trail of the decision process, not just the payment outcome. An auditor can reconstruct how an agent moved from "general authorization to buy cloud services" to "payment of $2,340 to Vendor X on date Y" step by step.

How do mandates and authorization-time policy work together?

Mandates answer the question: "Was this agent ever allowed to do this?" Authorization-time policy answers a different question: "Should this agent be allowed to do this right now, given the current state?"

Both questions need answers before a charge should go through.

A mandate proves that a human issued authorization at a point in time. But circumstances change. The budget envelope may have been depleted by earlier transactions. The merchant may have been added to an exclusion list after the mandate was issued. The delegation may have been revoked at the platform level. The mandate, being a signed credential with a fixed payload, can't capture any of that.

That's what authorization-time policy enforces. When a Payment mandate arrives at the authorization moment, a policy layer checks current conditions: Is the budget still available? Does the merchant still pass the policy filter? Is the agent's delegation still active? Has the per-transaction limit been hit?

The mandate proves "allowed in principle." The policy decides "allowed right now."

Used together, mandates and real-time policy are complementary controls. Mandates without policy enforcement leave gaps for changed conditions. Policy enforcement without mandates leaves the authorization chain undocumented and unverifiable. Neither alone is enough.

Why does cryptographic proof matter more than API-based verification?

The alternative to a self-contained signed mandate is calling an authorization API at transaction time. That works until the API is down or slow, and card networks authorize in well under a second. An external round-trip is a fragility point.

A signed mandate is offline-verifiable. The merchant or processor checks the signature against the issuer's public key. No round-trip, no live service dependency. Verification logic is standardized under the W3C VC spec. No proprietary SDK, no Google partnership, just the open standard.

Frequently asked questions

What is an AP2 verifiable mandate?

An AP2 verifiable mandate is a W3C Verifiable Credential that cryptographically proves an AI agent's authorization to take a payment action. It is signed by the issuing party, self-contained, and independently verifiable without a callback to a central authority. AP2 defines three mandate types: Intent, Cart, and Payment.

How are AP2 mandates different from an OAuth token?

OAuth tokens grant ongoing access to a resource; they're typically opaque and verified by calling the authorization server. AP2 mandates are structured, readable, self-contained credentials with a defined payload describing exactly what is authorized. Mandates are also domain-specific to commerce: they carry payment-relevant fields like spend limits and merchant categories that a general OAuth token doesn't model.

Can a merchant verify an AP2 mandate without calling Google?

Yes. Because mandates are signed using standard cryptography and the W3C VC format, any party with the issuer's public key can verify the signature locally. This offline verifiability is a core design requirement: it prevents a dependency on Google's infrastructure in the payment authorization path.

What happens if an agent presents a mandate that's been modified?

The cryptographic signature fails verification. A valid signature covers the entire credential payload; any modification, even a single digit change to a spend limit, invalidates it. The presenting agent receives a verification failure, and the transaction is declined.

Do I need AP2 mandates if I already have Shatale's delegation tokens?

They serve complementary roles. AP2 mandates prove authorization to external parties (merchants, processors, card networks) who don't have visibility into your internal delegation system. Shatale's authorization-time policy enforces current conditions against internal budget and rules. In a complete stack, mandates handle external proof; the control plane handles real-time enforcement. You want both.

---

To see how AP2 sits alongside ACP and Visa TAP in the full protocol picture, read [AP2 vs ACP vs Visa TAP](/blog/ap2-vs-acp-vs-visa-tap).