AP2
A design for an AP2 (Agent Payments Protocol) adapter, positioning PolicyVault as a mandate-verifying Credential Provider.
Status: DESIGNED. Nothing described on this page is implemented, unit-tested, VM-verified, testnet-verified, or production-hardened yet. No production file, covenant byte, or configuration is changed by this design.
What AP2 is
AP2 (Agent Payments Protocol) is a mandate-based agentic-commerce protocol: a user's authorization is captured in cryptographically signed, selectively-disclosable verifiable credentials ("mandates") that travel with a purchase as it moves between a shopping agent, a merchant, and payment infrastructure.
The role PolicyVault plays — and never plays
| AP2 role | PolicyVault |
|---|---|
| Credential Provider (CP) | In scope — the primary role. The CP is "the source of payment credentials" that "verifies agent authorization" — precisely PolicyVault's function: it holds the delegated-spending relationship (vault, agent registry, covenant policy) and deterministically decides whether an agent is authorized. |
| Trusted Surface (TS) | In scope, optional. PolicyVault already ships a wallet-authenticated UI with browser-local intent verification that independently detects server/frontend manipulation before signing — a stronger Trusted Surface than most AP2 deployments have by default. |
| Shopping Agent | Out of scope. PolicyVault never does product discovery or decides what to buy; the Shopping Agent is the customer's own AI agent, and PolicyVault is what bounds it. |
| Merchant / Merchant Payment Processor | Out of scope, permanently — free-forever product policy. |
| Network | Out of scope — Kaspa consensus is the network. |
How a mandate would be mapped onto the pipeline
AP2's Checkout Mandate and Payment Mandate would be normalized into a closed intent structure under the same trust-classification discipline as every other externally supplied instruction, then flow through the existing intent → build → sign → finalize → submit → reconcile pipeline — the same policy checks, mandatory dry-run simulation, and pre-sign verification as any other spend. Mandate constraints would feed the restrictive-only risk layer by construction: a mandate can only add restriction, never expand what the covenant would otherwise accept.
An honest, open gap
Like x402, AP2's reference flows assume settlement that can complete synchronously; PolicyVault's covenant-enforced model requires a real signed, submitted, and chain-confirmed transaction. This design documents that gap and a proposed Kaspa-specific payment-instrument extension point rather than inventing behavior AP2 does not specify. Ecosystem-acceptance questions (how a novel Kaspa payment instrument would be received by existing AP2 implementations) are open and stated as such.
Deployment boundary
As with x402, an AP2 adapter would run as its own module/process, separate from PolicyVault's core pipeline, so its absence or compromise degrades only AP2-specific functionality.
See also: x402, Machine identities and capabilities.