KYA Now Speaks AP2

The Agent Payments 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, and AP2 v0.2 introduced a “Human-Not-Present” mode designed specifically for the case where an agent transacts on a principal's behalf without an active human session.

That mode is exactly the world KYA already operates in. Our trace JWT is the canonical authorisation envelope: it binds a principal, an operator, an action scope, an amount limit, an audience, and a validity window into a single Ed25519-signed token that merchants verify at checkout. The data shape is the same data shape AP2 cares about. What was missing was a way for AP2-native consumers—merchants, credential providers, payment processors—to read it without writing a KYA-specific integration.

The design constraint we held to is important: the KYA trace JWT remains the canonical authorisation envelope. We are not re-signing trace data into AP2's normative SD-JWT transport. We are not asking existing clients to migrate. AP2 is emitted as an additional, standards-shaped view of authorisation that the trace already encodes.

That choice keeps KYA cryptography, key management, and revocation paths exactly where they were. AP2-aware verifiers get the schema they expect; KYA-native verifiers see no change. No client breaks; no envelope is re-implemented.

For each trace, we emit two AP2 v0.2 documents in Human-Not-Present mode: an Open Checkout Mandate (where the agent is allowed to transact) and an Open Payment Mandate (how much, against whom, and within what window). The mapping is deterministic and lossless for the constraint subset AP2 understands.

An AP2-aware verifier receiving the Open Payment Mandate sees a typed array of constraints it already knows how to evaluate. A KYA-aware verifier still gets the trace JWT and the full kya claim. Both reach the same answer about the same authorisation.

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 an Open Payment Mandate and a closed (concrete) payment, and returns a list of constraint violations—empty when the payment is within the mandate.

The verifier covers the constraints the translation emits today: allowed_payees,amount_range (currency match, max, optional min), andexecution_date (within the not-before/not-after window). Other AP2 constraints such as recurrence history or specific payment-instrument lists need state the caller already holds, so they are intentionally out of scope for this endpoint and remain the verifier's responsibility.

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) are not mandate violations and should not be reported as such.

The point of speaking AP2 isn't that AP2 is conceptually richer than what KYA already encodes—it isn't. The point is that AP2 is what merchants, credential providers, and payment processors are reading when they integrate with anyone else in this space. Speaking the same vocabulary means a KYA-issued authorisation can flow through their existing rails without a per-vendor adapter.

For merchants, that means the trace token a verified agent presents at checkout produces a mandate that drops straight into an AP2-aware risk engine. For PSPs, pre-dispute alerts now arrive shaped like the constraint-violation events the rest of the AP2 ecosystem emits. For agent builders, nothing changes—the same trace they already mint is now automatically AP2-readable on the receiving side.