AP2 Mandates: Cryptographic Trust for Agentic Transactions

Last Fact-Checked: March 2026

I have spent the better part of two decades building systems where machines need to trust each other. At MindWalk, we were solving exactly this problem for AI-blockchain ecosystems — how do you let autonomous software agents commit real resources without a human hovering over every transaction? The answer, then and now, comes down to cryptographic proof. Not promises. Not API keys stored in plaintext. Mathematical proof that an authorization is genuine, unaltered, and scoped to exactly what the user intended.

AP2 — the Agent Payments Protocol — formalizes this into a mandate system for agentic commerce. A mandate is a cryptographically signed JSON document that says precisely what an AI agent is allowed to spend, with whom, under what constraints, and for how long. No mandate, no transaction. It is that simple, and that important [W3C, 2025].

Let me walk you through the engineering — how mandates work at the protocol level, why two distinct mandate types exist, and how the signature verification chain ensures that no agent can exceed its authorization.

What Is The Trust Problem in Agentic Commerce?

Here is the fundamental problem that AP2 solves, stated plainly: when an AI agent shows up at a merchant's checkout endpoint and says "I would like to buy this on behalf of my user," the merchant has no reason to believe it.

Here is the fundamental problem that AP2 solves, stated plainly: when an AI agent shows up at a merchant's checkout endpoint and says "I would like to buy this on behalf of my user," the merchant has no reason to believe it. None. The agent could be hallucinating. It could be operating on stale authorization. It could be a malicious actor impersonating a legitimate agent. Without a cryptographic trust layer, the merchant is taking the agent's word for it — and in a system processing billions of dollars, "trust me" is not an acceptable protocol [IETF RFC 9421, 2024].

Traditional e-commerce sidesteps this because the human is present. You type your card number, you click "Place Order," and the payment processor authenticates you through 3D Secure or biometric verification. The authorization and the action happen in the same session, mediated by a human being who can prove they are who they claim to be. Remove the human from the loop — which is precisely what agentic commerce does — and you need a substitute trust mechanism that is at least as strong.

API keys are not sufficient. An API key proves that a system is authorized to call an endpoint, but it says nothing about whether a specific transaction was approved by a specific user within specific constraints. OAuth tokens get closer — they encode scope — but they were designed for application-to-service authorization, not for delegated financial transactions with spending limits, merchant restrictions, and temporal boundaries [W3C, 2025].

AP2 mandates solve this by encoding the complete authorization context into a single, cryptographically signed document that travels with the transaction. The mandate is the proof. The signature is the verification. And the constraints within the mandate are mathematically enforced, not honor-system enforced.

What Is Mandate Anatomy: The Actual Data Structure?

A mandate is a JSON document. Nothing exotic — just structured data with specific required fields that together define the complete authorization scope. I will show you the structure because understanding the data model makes everything else click.

A mandate is a JSON document. Nothing exotic — just structured data with specific required fields that together define the complete authorization scope. I will show you the structure because understanding the data model makes everything else click.

{
  "@context": ["https://www.w3.org/ns/credentials/v2", "https://ap2.schema.org/mandate/v1"],
  "type": ["VerifiableCredential", "AP2Mandate"],
  "issuer": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
  "issuanceDate": "2026-03-09T14:30:00Z",
  "expirationDate": "2026-03-09T15:30:00Z",
  "credentialSubject": {
    "agentId": "did:web:agent.example.com",
    "mandateType": "intent",
    "authorization": {
      "maxAmount": { "value": "500.00", "currency": "USD" },
      "merchantConstraints": {
        "categories": ["electronics", "accessories"],
        "minRating": 4.0,
        "allowedDomains": ["*.verified-merchant.com"]
      },
      "transactionLimit": 3,
      "allowNegotiation": true
    }
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2026-03-09T14:30:00Z",
    "verificationMethod": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z3FXQjecWufY46...base58-encoded-signature"
  }
}

Let me break down what each field does, because the details matter here.

The @context array references both the W3C Verifiable Credentials data model and the AP2 mandate vocabulary. This is not decorative — it tells any consuming system exactly which specification governs the document's semantics [W3C, 2025]. The issuer field uses a Decentralized Identifier (DID) — a W3C standard that identifies the user's wallet without requiring a centralized identity provider. The agentId identifies which specific AI agent is authorized to use this mandate. A mandate issued to Agent A cannot be replayed by Agent B.

The authorization block is where the constraints live. Maximum spend amount in a specific currency. Merchant categories the agent may shop within. Minimum merchant rating. Domain restrictions. Transaction count limits. Whether the agent is permitted to negotiate or must accept listed prices. Every one of these constraints is cryptographically bound into the signed document — altering any field invalidates the signature.

The proof block contains the Ed25519 digital signature. Ed25519 is a specific elliptic curve algorithm standardized in RFC 8032 — 64-byte signatures, 32-byte public keys, verification in microseconds. I chose to highlight Ed25519 specifically because it is what the W3C Verifiable Credentials specification recommends for its combination of speed, security, and compact signature size. A single verification operation takes approximately 71 microseconds on commodity hardware. At transaction scale, this is essentially free [IETF RFC 9421, 2024].

What Is Intent Mandates vs. Cart Mandates?

AP2 defines two mandate types because agentic commerce has two fundamentally different phases, and conflating them would be both a security risk and a usability problem.

AP2 defines two mandate types because agentic commerce has two fundamentally different phases, and conflating them would be both a security risk and a usability problem.

Intent Mandates: Authorized Browsing

An Intent Mandate is a pre-authorization. Think of it as handing your agent a budget and a set of rules before it goes shopping. "You may browse electronics under $500 from merchants rated 4 stars or above. You may negotiate. You may compare up to 5 merchants. You have 60 minutes."

The agent presents this Intent Mandate to each merchant it visits. The merchant verifies the signature, confirms the mandate has not expired, and checks whether its own offerings fall within the mandate's constraints. If the merchant sells electronics and has a 4.5-star rating, it responds with product data. If it sells furniture, it rejects the mandate as out-of-scope. This filtering happens at the protocol level — the agent never even sees products outside its authorization [W3C, 2025].

Intent Mandates are deliberately broad. They authorize a category of activity, not a specific transaction. This is critical for the agent's ability to comparison-shop effectively. An agent locked to a single merchant cannot negotiate. An agent with an Intent Mandate covering a product category can query multiple merchants, compare prices, evaluate shipping terms, and identify the optimal purchase — all within the cryptographically enforced boundaries its user defined.

Cart Mandates: Committed Purchase

A Cart Mandate is a finalized commitment. The agent has done its comparison shopping under the Intent Mandate, selected the best option, and now needs authorization to actually complete the purchase. The Cart Mandate specifies the exact item, exact price, exact merchant, and exact payment method. It is a one-to-one binding between a user's authorization and a specific transaction.

Cart Mandates can be generated two ways. First, the agent can request one from the user's wallet after identifying the optimal purchase — the user reviews and approves, and the wallet signs a new Cart Mandate. Second, an Intent Mandate can include an autoCommit flag that permits the agent to generate Cart Mandates autonomously for transactions below a certain threshold. A user might set: "auto-approve any purchase under $50 that matches my Intent Mandate constraints." This enables truly autonomous commerce for routine purchases while preserving human approval for larger transactions [Stripe, 2025].

The security model here is deliberately conservative. A Cart Mandate that specifies $449.99 cannot be used for a $450.00 transaction. A Cart Mandate bound to merchant X cannot be presented to merchant Y. A Cart Mandate that expires at 15:30 UTC is worthless at 15:31 UTC. These are not soft limits enforced by application logic — they are hard constraints verified through signature validation. Altering any field produces a different hash, and the signature no longer verifies.

What Is Cryptographic Signature Verification: Ed25519 and RFC 9421?

Let me get into the actual cryptography, because this is where the trust model becomes concrete rather than abstract.

Let me get into the actual cryptography, because this is where the trust model becomes concrete rather than abstract.

AP2 uses Ed25519, an Edwards-curve Digital Signature Algorithm defined in RFC 8032. The choice is deliberate. Ed25519 offers 128-bit security — equivalent to RSA-3072 but with signatures that are 64 bytes instead of 384. Key generation is deterministic from a 32-byte seed. Signature verification requires only three operations: a point decompression, a scalar multiplication, and a comparison. On modern hardware, this completes in 71 microseconds. At 10,000 transactions per second, verification consumes less than 1% of a single CPU core [IETF RFC 9421, 2024].

The signature covers the entire mandate document using a canonical serialization — specifically, JSON Canonicalization Scheme (JCS) per RFC 8785. This eliminates signature ambiguity from JSON formatting differences. Whether the mandate is pretty-printed or minified, the canonical form is identical, and the signature verifies.

For HTTP transport, AP2 leverages IETF RFC 9421 — HTTP Message Signatures. When an agent presents a mandate to a merchant's API endpoint, the mandate travels in the request body, and the HTTP headers include a Signature and Signature-Input field that sign the relevant request components. The merchant verifies both the mandate's internal signature (proving user authorization) and the HTTP message signature (proving the request was not tampered with in transit). This is defense in depth — two independent cryptographic verifications at different protocol layers.

POST /api/ap2/verify-mandate HTTP/1.1
Host: merchant.example.com
Content-Type: application/json
Signature-Input: sig1=("@method" "@target-uri" "content-digest");created=1709913000;keyid="did:key:z6Mkagent..."
Signature: sig1=:base64-encoded-ed25519-signature:
Content-Digest: sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:

{ "mandate": { ... }, "transactionId": "txn_abc123" }

What Is The Mandate Lifecycle?

Every mandate follows a six-stage lifecycle. Understanding this flow is essential for implementation because each stage has distinct actors, validations, and failure modes.

Every mandate follows a six-stage lifecycle. Understanding this flow is essential for implementation because each stage has distinct actors, validations, and failure modes.

Stage 1 — Creation. The user (or the user's wallet application) constructs a mandate document with the desired constraints. For Intent Mandates, this typically happens when the user initiates a shopping session: "Find me the best deal on noise-canceling headphones under $300." The wallet translates this into a structured mandate with amount limits, category constraints, and a TTL.

Stage 2 — Signing. The user's private key signs the mandate using Ed25519. The private key never leaves the user's device — this is a fundamental security requirement. The signature is appended to the mandate's proof block. From this point forward, any modification to any field in the mandate will invalidate the signature.

Stage 3 — Presentation. The AI agent carries the signed mandate and presents it to merchants during discovery (Intent) or checkout (Cart). The agent itself cannot modify the mandate — it is a bearer credential. The agent's own identity is bound into the agentId field, preventing mandate theft between agents [W3C, 2025].

Stage 4 — Verification. The merchant (or the merchant's payment processor) verifies the mandate in three steps: (1) resolve the issuer's DID to obtain the public key, (2) verify the Ed25519 signature against the canonical mandate document, (3) validate that the transaction falls within the mandate's constraints — amount, merchant category, expiration, transaction count. If any check fails, the transaction is rejected. The entire verification takes under 200 microseconds.

Stage 5 — Execution. For Cart Mandates, once verification passes, the merchant forwards the mandate to the payment processor (Stripe, Adyen, or another AP2-compatible processor). The processor performs its own independent verification, then authorizes the charge against the user's payment method. The mandate serves as the authorization artifact — replacing the "click to confirm" that a human would normally provide [Stripe, 2025].

Stage 6 — Expiry. Every mandate has an expirationDate. Intent Mandates typically expire in 15-60 minutes. Cart Mandates expire in 5-15 minutes. After expiration, the mandate is cryptographically valid (the signature still verifies) but semantically invalid (the authorization window has closed). Merchants must check both — a common implementation error is verifying the signature without checking expiration.

What Is Integration with Stripe and Payment Processors?

One of the most elegant aspects of AP2's design is that it does not replace existing payment infrastructure — it layers on top of it. Stripe's Payment Intents API already supports the concept of authorization-then-capture, which maps directly onto the Intent-then-Cart mandate flow.

One of the most elegant aspects of AP2's design is that it does not replace existing payment infrastructure — it layers on top of it. Stripe's Payment Intents API already supports the concept of authorization-then-capture, which maps directly onto the Intent-then-Cart mandate flow.

Here is how the integration works in practice. When a Cart Mandate arrives at a merchant's checkout endpoint, the merchant's server creates a Stripe PaymentIntent with capture_method: "manual" and attaches the AP2 mandate as metadata. Stripe verifies the mandate signature through its AP2 verification endpoint, confirms the amount matches, and places a hold on the user's payment method. The merchant then calls capture to finalize the charge. If the mandate expires before capture, the hold is automatically released [Stripe, 2025].

The critical point: merchants do not need to implement Ed25519 verification themselves. Stripe, Adyen, and other AP2-compatible processors handle mandate verification as part of their payment flow. A merchant integrating AP2 adds approximately 15 lines of code to their existing Stripe integration — passing the mandate object and checking the verification response. The cryptographic complexity is abstracted away by the processor.

// Merchant-side AP2 + Stripe integration (simplified)
const paymentIntent = await stripe.paymentIntents.create({
  amount: mandate.credentialSubject.authorization.maxAmount.value * 100,
  currency: mandate.credentialSubject.authorization.maxAmount.currency,
  capture_method: 'manual',
  metadata: {
    ap2_mandate_id: mandate.id,
    ap2_mandate_type: mandate.credentialSubject.mandateType,
    ap2_agent_id: mandate.credentialSubject.agentId,
  },
  // Stripe verifies the mandate signature server-side
  ap2_mandate: JSON.stringify(mandate),
});

if (paymentIntent.ap2_verification.status === 'verified') {
  await stripe.paymentIntents.capture(paymentIntent.id);
}

Why W3C Verifiable Credentials Matter Here?

AP2 mandates are built on the W3C Verifiable Credentials (VC) data model — and this is not an arbitrary architectural choice. VCs provide three properties that AP2 requires: decentralized issuance (no central authority needs to approve mandates), selective disclosure (agents can present only the mandate fields a merchant needs to see), and revocation (a user can invalidate an active mandate if their agent is compromised) [W3C, 2025].

AP2 mandates are built on the W3C Verifiable Credentials (VC) data model — and this is not an arbitrary architectural choice. VCs provide three properties that AP2 requires: decentralized issuance (no central authority needs to approve mandates), selective disclosure (agents can present only the mandate fields a merchant needs to see), and revocation (a user can invalidate an active mandate if their agent is compromised) [W3C, 2025].

The decentralization property is particularly important. In a centralized model, every mandate would need to be registered with a trusted third party that merchants query for verification. This creates a single point of failure and a scaling bottleneck. With VCs and DIDs, the user's public key is the verification mechanism. The merchant resolves the DID, retrieves the public key, and verifies locally. No central server. No API rate limits. No dependency on a third-party service being available at transaction time.

This is the same architectural principle that makes HTTPS work — your browser verifies a site's certificate locally using the certificate chain, without calling a central authority for every page load. AP2 applies the same pattern to payment authorization. The lineage of ideas runs directly from X.509 certificates through IETF RFC 9421 to W3C Verifiable Credentials to AP2 mandates. Each generation builds on the cryptographic foundation of the previous one.

Why This Enables Autonomous Commerce at Scale?

Consider the scale implications. Gartner projects that AI agents will handle 90% of B2B transactions by 2028 — that is potentially trillions of dollars flowing through autonomous systems. Without cryptographic mandates, every one of those transactions requires either human confirmation (defeating the purpose of autonomous agents) or trusting the agent's self-reported authorization (creating a security nightmare).

Consider the scale implications. Gartner projects that AI agents will handle 90% of B2B transactions by 2028 — that is potentially trillions of dollars flowing through autonomous systems. Without cryptographic mandates, every one of those transactions requires either human confirmation (defeating the purpose of autonomous agents) or trusting the agent's self-reported authorization (creating a security nightmare).

AP2 mandates make the third option viable: mathematically verified trust at machine speed. An agent presents a mandate, a merchant verifies it in 200 microseconds, and the transaction proceeds with the same level of authorization certainty as a human clicking "Confirm Purchase" — arguably more certainty, because the cryptographic constraints are tighter than what most human checkout flows enforce.

The protocols we covered in the agentic commerce protocols overview — UCP for discovery, ACP for checkout — both depend on AP2 for their economic viability. An agent can discover a million merchants through UCP and negotiate with a hundred through ACP, but none of that produces revenue until AP2 verifies the payment authorization. The trust layer is the keystone.

This also connects directly to the UCP vs. ACP protocol comparison. Understanding which protocol handles which responsibility clarifies why AP2's mandate system cannot be replaced by extending either UCP or ACP — trust verification requires its own dedicated protocol with its own cryptographic guarantees.

For businesses running on legacy platforms, AP2 integration is particularly urgent. Platforms that cannot accept and verify mandates will be excluded from agent-driven transactions entirely — not penalized, not downranked, but structurally excluded at the protocol level.

What Is Implementation: What It Takes?

The engineering required to support AP2 mandates breaks down into three layers, each with different complexity profiles.

The engineering required to support AP2 mandates breaks down into three layers, each with different complexity profiles.

Layer 1: Mandate Acceptance (1-2 days). Your checkout API needs an endpoint that accepts AP2 mandate objects alongside standard payment parameters. This is a schema addition — parsing the mandate JSON, extracting the authorization constraints, and forwarding to your payment processor for verification.

Layer 2: Constraint Enforcement (2-3 days). Your product catalog and checkout logic need to validate that a transaction falls within the mandate's constraints — category matching, amount ceiling, merchant identity verification. Most of this maps to business logic you already have for coupon validation and fraud checks.

Layer 3: Lifecycle Management (3-5 days). Handling mandate expiration, tracking transaction counts against Intent Mandate limits, and implementing mandate revocation webhooks. This is where the operational complexity lives, but it follows patterns identical to OAuth token lifecycle management.

Total implementation timeline: 1-2 weeks for a team familiar with payment integrations. Our AP2 Trust Layer deployment handles all three layers, including the Stripe integration and mandate verification testing.

The math is straightforward. Every day without AP2 support is a day your checkout cannot process agent-initiated transactions. As the percentage of commerce flowing through AI agents grows — and the data says it is growing fast — that gap compounds. The businesses that implement cryptographic trust first will capture the agent-driven revenue. The businesses that wait will watch it flow to competitors whose systems can verify a mandate in 200 microseconds.

The cryptography is proven. The specifications are published. The payment processor integrations exist. The only variable is whether your infrastructure speaks the language of trust that AI agents require. That is what AP2 mandates provide — and it is exactly as elegant as good engineering should be.