AP2 mandate checks in KYA

The Agentic Payment Protocol (AP2) started as a Google-led effort to give autonomous AI agents a standard way to carry user-authorised purchase intent into a checkout. Earlier this year, Google donated AP2 to the FIDO Alliance. AP2 v0.2 supports a “Human-Not-Present” mode for the case where an agent transacts on a principal’s behalf without an active human session.

A KYA trace JSON Web Token (JWT) binds a principal hash, an operator, an action scope, an amount limit, an audience, and a validity window. The operator supplies this context. The trace signature does not independently verify the principal’s consent. The AP2 beta projects selected trace fields into AP2 mandate bodies for consumers that implement a KYA-specific integration.

The KYA trace JWT remains the signed source. The beta returns separate JSON bodies with AP2 fields. AP2 specifies Selective Disclosure JWT (SD-JWT) credentials for its normative transport. KYA does not implement that transport or the complete signed mandate chain.

Clients that used the embedded ap2 field must migrate to the mandate endpoint. Register an agent proof key before requesting mandate bodies. If the agent has several active keys, select one with agent_key_id. Do not pass these JSON bodies to an AP2 verifier that expects signed SD-JWT credentials.

For an eligible purchase trace, the mandate endpoint returns two JSON bodies: an Open Checkout Mandate and an Open Payment Mandate. The projection maps the merchant, amount limit, and time window. It checks purchase scope before translation. It does not translate every trace field or prove user consent.

A KYA-specific consumer can evaluate the projected constraints and retain the source trace. A complete AP2 verifier also checks signed credentials and their bindings. The beta constraint result does not replace those checks.

Authorising an intent is one half of the loop; checking that the actual payment matches that intent is the other. POST /v1/ap2/verify takes a trace, by trace_id or trace_jwt, and a closed (concrete) payment. It rebuilds the Open Payment Mandate from the trace instead of trusting one the caller sends, and returns a list of constraint violations—empty when the payment is within the mandate. If the caller does send a mandate and its constraints differ from the trace’s, that is reported as a violation. Revoked traces, and traces already used by another party, are rejected. Expired traces and traces without purchase scope are also rejected. A caller-supplied payment date cannot restore an expired trace. The endpoint does not verify an agent-signed closed mandate or track repeat checks of the same payment.

The verifier covers the constraints the translation emits: allowed_payees,amount_range (currency match, max, optional min), and execution_date (within the not-before/not-after window; a payment without a date is checked at the time of the request). AP2 says unknown constraints must count as failing, so any other constraint, such as recurrence history or payment-instrument lists, is reported as not evaluated rather than passed.

KYA’s pre-dispute side-channel exists to flag bad agent behaviour before it becomes a chargeback. Each alert carries a reason code (AMOUNT_EXCEEDED,UNAUTHORIZED_ACCESS, SCOPE_EXCEEDED, etc.). For AP2-aware merchants and processors, those codes were until now opaque KYA-specific strings.

We added a deliberate, conservative mapping from each KYA reason code to the AP2 constraint it logically violates. Every alert now includes an ap2_constraint_violatedclaim alongside the original reason code:

The codes that have no clean AP2 analogue stay null rather than being forced into the wrong bucket. Operational signals (the agent looped on itself, an operator triggered the alert manually, our system detected anomalous behaviour) aren’t mandate violations and should not be reported as such.

The beta gives KYA-specific consumers a typed view of selected trace constraints. Consumers must retain the source trace and its limitations. AP2 transport compatibility requires additional signed credential and mandate-chain work.

Merchant and payment-provider integrations can request the mandate bodies and compare a candidate payment against the supported constraints. Agent builders must register a proof key. Clients that read embedded mandates must migrate to the separate endpoint. Existing AP2 consumers need a KYA-specific adapter.