Know Your Agent (KYA): a practical guide to AI agent trust

Updated 26 October 2026.

Know Your Agent (KYA) is the set of checks a business uses to understand an AI agent, who it represents and whether a requested action is allowed. In commerce, useful checks also cover the customer’s eligibility for a price or benefit. A recognisable agent can still request an unauthorised purchase, and an authorised buyer may still be ineligible for a member offer.

KYA is an evolving industry term. We use it here as a practical trust framework for merchants, rather than the name of one mandatory certification or a guarantee against fraud.

What does Know Your Agent need to establish?

Start with the decision the merchant has to make: may this agent complete this transaction for this customer, on these terms, now? Break that decision into evidence that can be checked separately.

1. Agent identity: which software agent or service is making the request, and how is it authenticated?
2. Representation: which person or organisation is the agent acting for, and what evidence connects them?
3. Authority: what actions, merchants, amounts and time window did that person approve? Our guide to AI agent permissions, spending limits and revocation explains how to make these boundaries enforceable.
4. Eligibility: does the customer qualify for the requested membership benefit or offer?
5. Current validity: have permissions or credentials expired, changed or been revoked?
6. Accountability: can the parties reconstruct the decision without retaining unnecessary personal information?

This is our proposed evaluation framework. Different services will need different evidence. Public catalogue browsing may need fewer checks than spending a customer’s money or redeeming their points.

How is KYA different from KYC?

KYC, or Know Your Customer, concerns the customer relationship and the checks applicable to it. KYA addresses the additional agent acting within that relationship. A customer identity check does not, by itself, establish permission for an agent to buy something. Recognising an agent does not establish the identity of its customer either.

For a merchant, the practical approach is to keep customer, agent and transaction decisions connected but distinguishable. Existing customer checks can inform the decision; an agent request still needs its own authority and scope. This guide is an implementation framework, not a substitute for the requirements that apply to a particular business.

A worked example: an agent buys a member-priced item

Consider an illustrative purchase. A customer asks an agent to buy one replacement travel adapter from Merchant A, spending at most HK$500 including delivery, before 6pm. The customer has a membership that may qualify for a discount.

The merchant first authenticates the requesting agent. It then checks the link to the customer’s approval and confirms that the basket fits the merchant, amount, quantity and time limits. Separately, it checks the membership evidence against its own offer rules. Only then should it calculate the eligible price and submit the payment request.

If delivery raises the total to HK$520, the agent needs a new approval. If membership has expired, the merchant can decline the discount; it must not silently buy at a higher price if the customer only approved the member-priced option. A payment decline remains a separate outcome even when the other checks pass.

Our guide to AI agents and loyalty at checkout works through the membership evidence, offer rules and final-price checks behind this kind of purchase.

Which standards can support KYA?

No single mechanism answers every question. W3C Verifiable Credentials Data Model 2.0 describes how issuer claims can be represented and checked. A merchant still decides which issuers and claims it accepts. A credential is not automatically a purchase permission.

For a merchant choosing how to access customer evidence, our comparison of account linking and verifiable credentials explains where each approach fits and how they can work together.

OAuth token exchange, RFC 8693, provides a way to express delegation and actor information in token flows. Business limits still need to be enforced by the receiving service. The Decentralized Identity Foundation’s KYA-OS work is another open effort addressing agent identity and delegation. Its existence does not establish universal adoption or regulatory approval.

Where AIR fits in Know Your Agent

AIR Agent is AIR’s product for connecting the customer behind an AI agent with relevant credentials and permissions. It builds on AIR Identity, the reusable credential infrastructure built by Moca Network. For merchants, the use case includes assessing customer eligibility before applying a membership benefit.

Use the AIR credential architecture to assess issuance, consent and verification, and the agent permissions guide to define the action limits your commerce flow must enforce. A customer credential can support the eligibility decision; authority to place an order needs its own evidence and enforcement. Sources reviewed 26 October 2026.

The AIR, Minds, Reap and Pivota announcement describes a planned commerce flow, not published pilot results. Agent capability availability should be confirmed for a proposed integration. The Moca Chain mainnet announcement separately places AI agent identity on the roadmap.

Where should a merchant start?

Choose one purchase flow and write down the evidence needed for each decision. Then test a successful purchase, an expired permission, an ineligible discount and a repeated request. A useful first milestone is a purchase whose approval, benefit calculation and payment outcome can each be explained.

Continue with our guide to identity and authorisation, or use the KYA checklist for merchants to define acceptance tests.

Frequently asked questions

What does KYA stand for?

KYA stands for Know Your Agent. In this guide it means checking an agent’s identity, representation, authority and the conditions for the action it requests.

Does KYA replace customer identity checks?

No. Customer checks and agent checks answer different questions. A business still needs to establish any customer relationship and requirements relevant to its service.

Does an authenticated agent have permission to buy?

Not automatically. Authentication establishes who is making the request. Purchase permission must cover the customer, action, merchant, amount and relevant time window.

Is KYA a single mandatory standard?

This guide uses KYA as an evolving industry term. Teams should identify the specific protocols, trust rules and business requirements their integration implements.

Where does AIR fit in a merchant’s KYA checks?

AIR Agent is designed to connect the customer behind an agent with relevant credentials and permissions, building on AIR Identity. A merchant can assess the customer-credential architecture alongside its agent authentication, action authorisation and payment controls. Confirm the supported interfaces and availability for the proposed deployment.

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.