Can an AI agent consent or act on your customer's behalf? The AP2 mandate model, explained
Landscape as of September 2026. AP2 was donated to the FIDO Alliance on 28 April 2026; the Agentic Authentication and Payments working groups it created are still active as of this writing, and the interoperable standard they eventually produce may differ from AP2's original specification. OpenAI and Stripe's ACP took a different path - its Instant Checkout feature shipped, then was rolled back in March 2026 - so cite ACP's current shape carefully, not its 2025 launch framing.
What it is
AP2 (the Agent Payments Protocol) does not make an AI agent capable of giving consent the way a person does. Instead, it defines three signed Verifiable Credentials - the Intent Mandate, Cart Mandate, and Payment Mandate - that let an agent prove a specific human authorized a specific action, at a specific scope, before the agent acts on it. Google announced AP2 in September 2025 with more than 60 partners and donated it to the FIDO Alliance on 28 April 2026 for platform-neutral governance; two new FIDO working groups, Agentic Authentication and Payments, are now developing interoperable standards from it. The framing worth holding onto: AP2 answers "did a human actually authorize this," which is adjacent to, but not the same question as, "does this data collection or processing have valid consent under a privacy regulation" - the second question is still yours to answer, typically with the same consent-management architecture you already run.
When you need it
Your product lets a customer connect or authorize an AI agent - a shopping assistant, a booking agent - to act on their account, and legal or privacy has asked what actually proves that authorization if it's ever challenged.
You're evaluating whether to support AP2-style Mandates on the merchant side (accepting an agent-presented Intent or Cart Mandate at checkout) and need to know what the credential does and doesn't establish before committing engineering time.
A customer, auditor, or regulator has asked what stops an agent from consenting to something on a customer's behalf that they didn't actually agree to, and you need a precise answer rather than a general statement about AI safety.
How to implement it
- 1
Separate the two questions before designing anything
Question one: did the customer actually authorize this agent to act at all, and within what scope? That's what AP2's Mandates are built to prove. Question two: is the underlying data collection or processing lawful under your applicable privacy regulation? That's still your existing consent-management program's job. AP2 does not replace or satisfy the second question - conflating the two is the most common design mistake here.
- 2
Map what each Mandate actually attests
The Intent Mandate is the customer's signed statement of what they authorized the agent to do (a category of purchase, a spending ceiling, a time window). The Cart Mandate attests the agent presented a specific set of items or terms consistent with that intent. The Payment Mandate authorizes the actual transaction. None of the three is a consent record for data processing - they're an authorization chain for the action itself.
- 3
Decide where a Mandate needs to reach your consent architecture, not replace it
If accepting an AP2-style Mandate at checkout also triggers data collection - an account creation, a marketing opt-in bundled into the flow - that collection still needs its own valid basis under your privacy program. Route that decision through the same review that governs any other checkout-flow consent question, rather than assuming a valid Payment Mandate covers it.
- 4
Log the Mandate chain itself, not just its outcome
If you're a merchant accepting agent-driven transactions, retain the signed Mandate objects, or a verifiable reference to them, the same way you'd retain any other proof of authorization. This is the artifact that answers a later dispute ("the agent claims I authorized this, prove it") - a Mandate you didn't retain is not meaningfully different from one that never existed.
- 5
Route the actual liability and dispute-resolution question to your own review
What happens when a Mandate chain is technically valid but the customer disputes the outcome anyway is a business and compliance decision, reviewed alongside legal and privacy, not something the protocol itself resolves - AP2 proves authorization occurred, it doesn't adjudicate disputes about it.
How to verify it worked
Pick one Mandate type your integration actually issues or accepts and confirm, in a test transaction, that the signed credential is generated with the fields you expect (scope, ceiling, expiry) rather than a stub that always returns the same values.
Confirm a test flow that bundles a data-collection moment (account creation, opt-in) inside an agent-authorized checkout still triggers your existing consent-management prompt or record separately from the Mandate itself - a passing result shows two distinct artifacts, not one standing in for the other.
Retrieve a retained Mandate for a completed test transaction days later and confirm it's still readable and verifiable, not just logged as a pass/fail flag with the underlying signed object discarded.
Related
Elsewhere in the agentic-traffic cluster
Want this scoped against your specific OneTrust tenant?
We scope every engagement in discovery, before implementation - no assumptions about your stack.