AP2 Evidence

AP2 (Agent Payments Protocol, v0.2) is the Google/FIDO format for proving that an agent’s purchase was authorised: a Checkout Mandate bound to the merchant-signed checkout and a Payment Mandate bound to the same checkout, each an open mandate (constraints authorised on a trusted surface) plus a closed mandate the agent signs against it. Merchants and payment processors verify the chains and answer with signed receipts.

Regent does not change how it decides. When a caller brings a merchant Checkout JWT, the gate adds AP2 evidence to an allow.

Roles

AP2 role	Who	What it signs
Trusted Agent Provider / Trusted Surface	Regent — the owner authorised the agent on the console (KYC, mandate terms, policy); the gate checked this request	the open Checkout + Payment Mandates (ES256 provider key, in the control JWKS)
Shopping Agent	the agent, with a custodial key derived per agent and held by Regent	the closed mandates (key-binding hops)
Merchant	e.g. get4agent	the Checkout JWT and the Checkout Receipt
Merchant Payment Processor	e.g. get4agent’s prepaid ledger	the Payment Receipt

The open mandates attest exactly what the gate allowed — this checkout’s line items and merchant, this amount, this payee. The owner’s ceilings never appear in AP2 artifacts; they stay under commit-and-reveal in Regent’s own receipts.

Asking for evidence

Add ap2 to the decision context of a money action:

{
  "agent_id": "agent_…",
  "tool": "market",
  "action": "POST /call",
  "args": { "listing_id": "…" },
  "context": {
    "amount": 0.95, "currency": "USD", "mandate_id": "…",
    "ap2": {
      "checkout_jwt": "<merchant-signed Checkout JWT (ES256)>",
      "nonce": "<the verifier's nonce>",
      "aud": "get4agent",
      "instrument": { "id": "prepaid:agent_…", "type": "regent.prepaid_balance" }
    }
  }
}

An allow then carries ap2:

{
  "decision": "allow",
  "decision_id": "dec_…",
  "token": "…",
  "ap2": {
    "spec": "0.2",
    "checkout_mandate": "<open>~…~~<closed>~…",
    "payment_mandate": "<open>~…~~<closed>~…",
    "transaction_id": "<base64url sha256 of the Checkout JWT>",
    "checkout_reference": "<what the Checkout Receipt must reference>",
    "payment_reference": "<what the Payment Receipt must reference>",
    "nonce": "…", "aud": "get4agent",
    "provider_kid": "…", "agent_jwk": { "kty": "EC", "crv": "P-256", "…": "…" }
  }
}

The /complete receipt of the same decision carries ap2_transaction_id and ap2_payment_reference, so Regent’s own evidence and the AP2 set point at each other.

Verifying

Anyone holding the evidence can run the spec’s dispute rules in one call:

POST https://control-api.regentprotocol.org/v1/control/ap2/verify
{
  "checkout_mandate": "…", "payment_mandate": "…",
  "nonce": "…", "aud": "get4agent",
  "checkout_receipt": "…", "payment_receipt": "…",
  "receipt_keys": [ { "kty": "EC", "crv": "P-256", "kid": "…", "x": "…", "y": "…" } ]
}

The report lists every violation (chain signatures, constraint evaluation, checkout_hash versus transaction_id, receipt signatures and references) and is ok only when there are none. The chains also verify offline with Google’s reference SDK against two public keys: the provider key in https://control-api.regentprotocol.org/v1/control/.well-known/jwks.json and the merchant’s key (for get4agent: /v1/ap2/merchant.json).

On get4agent

Every governed prepaid call on get4agent.com produces the full set: the marketplace signs the checkout, the gate issues the chains, the marketplace verifies them before money moves and signs both receipts after the charge. The set is available at GET https://get4agent.com/v1/ap2/evidence/{decision_id} together with a ready-to-send verify body.

What AP2 does not replace

AP2 is the evidence format. Enforcement — the mandate check, policy, behavioural signals, the kill switch, the anchored audit trail — stays in the gate, before any money moves. See Concepts → Guardian and Receipts.

SDK & Integration Settlement Confirmation