Agent Payments Protocol (AP2)
Agent Payments Protocol (AP2) explained
The central question is what was actually authorised. A checkout mandate and payment mandate connect authority to the specific transaction. That differs from a loose chat request to get something suitable. An implementation should make permitted products, spending limits and validity understandable and technically enforceable.
AP2 distinguishes direct confirmation from action within previously approved constraints. The relevant roles must verify mandates; a model response does not perform that verification. A pilot needs participating systems that support the same protocol version and intended flow. Mentioning AP2 in a product description is insufficient.
Signatures make certain data changes detectable. They do not prove that a product recommendation is suitable or a payment economically sensible. Repeats, expired authority, changed prices and conflicting responses also need clear handling. Contractual, privacy and payment requirements require separate assessment.
Creative Engineering designs understandable delegation with effective limits. We take responsibility for the concept and quality. Start with a narrow test case and explicitly test rejection of prohibited actions. Then evaluate correctly completed tasks and total review and operating effort rather than treating autonomous transactions as success in themselves.
Examples
Hypothetical application
A test system orders office supplies within an approved scope. If quantity or total price moves outside that scope, the process stops. The team also checks that repeating a request does not produce a second order.
Key Points
- Bind purchase and payment authority to the actual transaction.
- Have the responsible systems verify mandates.
- Separate technical evidence from a sound decision and legal assessment.
Practical application
Clarify the delegation case, participating systems and authority. In a limited environment, test successful transactions as well as limit breaches, repeats and uncertain responses.
Useful measures
Correctly bounded actions
Check that allowed actions succeed and disallowed ones are actually rejected.
Unambiguous completion
Reconcile orders, payment status and errors traceably.
Total effort
Assess integration, ongoing verification, exceptions and payment fees together.
Common mistakes
- Treating a signature as evidence of a good purchase decision.
- Describing authority only in a prompt without effective enforcement.
- Inferring security or savings from the protocol name.
Sources and context
- AP2: Specification v0.2
Protocol background on linked checkout and payment mandates and roles, not a universal security or legal guarantee.
- OWASP: LLM01 Prompt Injection
Risks from external instructions, access restrictions and layered mitigations.
Frequently Asked Questions about Agent Payments Protocol (AP2)
No. It describes a protocol component. Processing and other services come from participating systems and payment providers.
No. Autonomy must remain within actually granted and verified authority. An unclear preference is not an unlimited payment instruction.
No. Correct integration, effective checks and error handling remain essential. Even a validly signed transaction can be substantively unwanted.
Related links
Loading related terms…
All TermsArticles about Agent Payments Protocol (AP2)
Cybersecurity in marketing: When an attack stops demand
An attack does not only affect IT. It can interrupt demand, sales and trust. Plan protection and recovery around your marketing processes.
Marketing as an Operating Discipline: Why Almost Every CMO Talks About AI and Few Have Built It
The gap between intent and execution is not a technology problem, it is an operating model problem. How to move marketing from a project organisation to an operating discipline with systems, roles and cadence.
GEO in practice: Customer questions and evidence
A practical GEO review: choose customer questions, check content gaps and technology, add evidence and assess suitable enquiries.