# Google’s AP2 put signed purchase authority beside an agent’s request Google announced Agent Payments Protocol on September 16, 2025, proposing signed mandates as evidence for agent-led payment authority. Canonical: https://rangoon.ai/insights/archive-google-ap2-september-2025/ Author: Rangoon Editorial (https://rangoon.ai/insights/editorial/) Published: 2026-10-23 Updated: 2026-10-23 Event date: 2025-09-16 Tags: [Google Cloud](https://rangoon.ai/insights/tags/google-cloud/), [AP2](https://rangoon.ai/insights/tags/ap2/), [agent payments](https://rangoon.ai/insights/tags/agent-payments/), [verifiable credentials](https://rangoon.ai/insights/tags/verifiable-credentials/) Source note: Historical reporting: Google Cloud announced AP2 on September 16, 2025 as an open, payment-agnostic protocol for agent-led payments. The current public repository supplies implementation context only; this article does not claim AP2 use, conformance, security sufficiency, or availability by any merchant, payment provider, agent, or product. Image: Signed authority path for an agent-led purchase. Original Rangoon explanatory diagram: Source boundary: dated primary release reporting; original editorial analysis. Not measured results, official guidance, vendor interface, or event photograph. ## Key takeaways - AP2 framed a payment request as a chain of signed authority evidence, rather than a model output alone. - Intent and cart mandates separate a user’s instruction from the final item-and-price commitment. - Cryptographic evidence can bind declared transaction data, but cannot prove that an agent’s earlier recommendation was wise or complete. ## The September event defined a payment-oriented protocol layer [source 1](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol) Google Cloud announced the Agent Payments Protocol, or AP2, on September 16, 2025. Its announcement described an open, payment-agnostic protocol for agent-led payments and said it could extend Agent2Agent and Model Context Protocol deployments. The stated problem was not merely moving a payment message between services: an autonomous agent changes the usual assumption that a person clicked buy on a trusted surface. Google therefore named authorization, authenticity, and accountability as separate questions for a transaction record. A protocol consumer can then examine a declared authority chain without treating a chat transcript, a tool call, and a settled payment as interchangeable artifacts. ## Mandates turn purchase instructions into inspectable transaction inputs [source 1](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol) [source 2](https://github.com/google-agentic-commerce/AP2) The announcement described mandates as cryptographically signed digital contracts backed by verifiable credentials. In a human-present flow, an Intent Mandate can preserve the request context and a later Cart Mandate can record the approved items and price. In a delegated flow, the advance instruction can state limits such as timing or price, then permit an agent to form a cart mandate only when those stated conditions are met. That division is technically useful because a service can test the signed data it received instead of reconstructing permission from a natural-language conversation. It also gives an investigation a specific question: whether the accepted cart was within the authority that was actually expressed and verified. ## A reliable implementation needs a narrow state boundary [source 1](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol) [source 2](https://github.com/google-agentic-commerce/AP2) A payment workflow needs identifiers for the user instruction, offer or cart revision, merchant, currency, amount, expiry, and signature verification result. A cart change after approval should create a new approval boundary; silently carrying a signature to new line items defeats the reason for preserving exact contents. Systems also need replay handling, key rotation rules, clock-skew policy, and an audit record that distinguishes an invalid signature from a rejected business request. Those mechanics are design concerns inferred from the protocol’s evidence model, not proof that a particular AP2 implementation handles them correctly. Storing the verification inputs, rather than only a pass-or-fail label, lets a later reviewer reproduce what credential and cart version the verifier saw. ## Signed authority does not settle every trust question [source 1](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol) [source 2](https://github.com/google-agentic-commerce/AP2) A valid signature can show that particular declared data was authorized under a verification policy; it does not establish product quality, delivery, a fair recommendation, or absence of fraud outside the declared fields. The issuer, verifier, merchant, payment provider, and agent still need compatible identity, credential, revocation, and incident procedures. AP2 also does not make an agent’s interpretation of a broad request automatically faithful to the user’s unstated preferences. The September announcement establishes a proposed common evidence layer, while adoption, legal treatment, and operational outcomes require separate evidence. Interoperability therefore depends on agreed data semantics and failure behavior as much as on a common signature format. A verifier also needs explicit outcomes for expired authority, partial availability, and disputed merchant data. ## Sources 1. [Google Cloud Blog: Powering AI commerce with the new Agent Payments Protocol (AP2)](https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol) 2. [Google Agentic Commerce: Agent Payments Protocol repository](https://github.com/google-agentic-commerce/AP2) ## Related reading - [Google Cloud detailed Customer Engagement Suite agent building, multimodal inputs and API tools](https://rangoon.ai/insights/archive-google-cloud-customer-engagement-suite-april-2025/) - [Google introduced Agentspace in early access for enterprise search, reasoning and custom agents](https://rangoon.ai/insights/archive-google-agentspace-december-2024/) - [Trillium general availability made a TPU generation a cloud configuration question](https://rangoon.ai/insights/archive-google-trillium-tpu-general-availability-2024/) ## More information - [Documentation index](https://rangoon.ai/llms.txt) - [AI access and policies](https://rangoon.ai/ai/) - [Source repository](https://github.com/hypler-dev/rangoon)