Know Your Agent checklist for merchants: before an AI agent buys

Before accepting an AI agent purchase, a merchant should be able to identify the requester, establish customer authority, evaluate eligibility and enforce the transaction’s limits. It also needs a defined response to expired permissions, duplicate requests, payment failure and customer withdrawal.

This checklist is our proposed starting point for product, engineering, risk and support teams. It is not a certification scheme. Apply it to one clearly defined purchase flow, then expand the scope after its success and failure paths are understood.

1. Define exactly what the agent may do

List the actions in scope: browse, obtain a quote, reserve stock, place an order, redeem points or request a refund. Identify which are read-only, reversible or financially consequential. Assign an owner to the policy for each action.

Acceptance test: an agent permitted to request a price cannot complete a purchase using that permission. The denied request produces an understandable reason.

2. Identify both the agent and the represented customer

Document how the merchant authenticates the agent and how the request relates to the customer’s approval. Keep those decisions distinct. A known software provider should not receive authority over every customer account simply because its identity is recognised.

Acceptance test: a request from a known agent fails when the required customer connection or authority is missing. For background, see agent identity and authorisation.

3. Make purchase limits enforceable

Specify the merchant, goods or substitutions, total amount, currency, usage count and expiry. Assign responsibility for enforcing each field at the point where the order or payment becomes committed.

Acceptance test: a basket that exceeds the cap after delivery charges is rejected. A changed merchant, expired approval or disallowed substitution also fails. Use our permissions guide to build additional cases.

4. Separate eligibility from permission

Write down which evidence qualifies a customer for a membership price or other benefit. Define accepted issuers or account records, offer exclusions and how recent the evidence must be. Give the customer a clear outcome if a benefit cannot be applied.

Acceptance test: an authorised agent cannot obtain a member discount with expired eligibility evidence. A valid membership alone cannot authorise a purchase. Our loyalty checkout example shows how the two decisions interact.

5. Bind the approval to the transaction

Ensure the approved price, basket and payment request remain consistent. Decide which changes require fresh customer approval. For integrations using payment mandates, map the evidence to the precise protocol version and the parties’ responsibilities.

The AP2 v0.2 specification distinguishes checkout and payment evidence. We recommend testing the connection between them rather than treating a valid signature as approval for any later basket.

Acceptance test: replacing the approved basket with a different one cannot reuse the original authority without a permitted change process.

6. Test revocation and requests already in progress

Set a measurable target for how quickly withdrawal takes effect across participating services. Define behaviour when status cannot be checked. Clarify when a request is too far advanced to stop and which cancellation or refund process then applies.

Acceptance test: revoke permission while a purchase is in progress and record the result at each decision point. Separately test a request sent after withdrawal has taken effect. Report the actual behaviour, including any delay.

7. Handle retries, parallel orders and payment failure

A slow response can cause an agent to retry. A distributed shopping flow may also submit simultaneous requests. Define a stable order reference or idempotency mechanism and coordinate shared spending limits and one-use benefits.

Acceptance test: submitting the same request twice creates at most one intended purchase. Two concurrent requests cannot overspend a shared cap. A declined payment does not leave the order marked paid, and any stock or benefit reservations follow the agreed release policy.

8. Keep useful evidence and a customer recovery path

Record enough to explain the decision: policy version, approval reference, relevant check outcomes, final basket, timestamps and payment result. Assign access and retention rules. Collecting entire identity documents or raw credentials by default can add exposure without helping resolve the transaction.

Acceptance test: support can explain why an order or benefit was accepted or rejected, identify the responsible parties and offer the appropriate recovery route. The customer can find active permissions and distinguish withdrawal from a refund request.

Define a small first release

Choose one merchant, one clearly specified purchase type and a limited set of benefit rules. Write down success measures before launch, such as completion rate, incorrect benefit decisions, duplicate-order incidents and observed revocation delay. These are proposed measures, not AIR benchmarks.

For an AIR Agent discussion, bring this checklist and the evidence available in your existing systems. Agree supported capabilities and ownership of each control before committing to a rollout. The broader KYA guide explains how these decisions fit together.

Frequently asked questions

What should be in a merchant KYA checklist?

Include agent authentication, customer authority, purchase limits, benefit eligibility, transaction evidence, revocation, duplicate handling and customer recovery.

Who should own the checklist?

Assign a business owner for each decision and a technical owner for its enforcement. Product, engineering, risk and support should agree the expected outcomes together.

What is a useful first pilot scope?

One merchant and one well-defined purchase flow are a practical starting point. Limit benefit rules and permitted actions so success and failure can be evaluated clearly.

Which failure cases matter most?

Test expired or revoked authority, changed baskets, excessive totals, stale eligibility evidence, repeated requests, concurrent spending and declined payments.

Does passing this checklist certify compliance?

No. It is an implementation aid. Applicable legal, payment, security and programme requirements need their own assessment for the business and integration concerned.

About AIR

We build identity, money and loyalty infrastructure for businesses. Explore AIR Agent or discuss your commerce flow with AIR.

Moca Network, the identity network of Animoca Brands.