Know Your Agent (KYA)
Know your agent (KYA) is the set of checks that establishes, before an AI agent may buy or move money, which agent it is, who operates it, which person or business it acts for, and what that principal has authorised it to do. It applies know-your-customer logic to software acting on someone's behalf, using cryptographic credentials rather than documents.
- Also known as
- KYA, Know-your-agent checks, Agent identity verification, Agent authentication
- Used at
- merchant checkouts and bot management when an agent browses or buys; card networks and wallets registering agents and issuing them credentials; banks and payment firms receiving instructions from an agent rather than a person
- Binding
- no dedicated law; the obligations come from existing rules — KYC and AML on the human or business principal, strong customer authentication for card and account payments in the EU and UK, card-scheme rules and merchants' terms — and from the networks' own agent programmes
- Typical checks
- agent identity (a request signed with a key published in a registry); the operator behind the agent; the principal it acts for; the scope of its mandate — amounts, merchants, time limits; and a record tying each transaction to that mandate
- Standards in play
- Visa's Trusted Agent Protocol (October 2025, developed with Cloudflare) and Mastercard's Agent Pay, both built on Web Bot Auth, which signs an agent's HTTP requests using HTTP Message Signatures (RFC 9421); Google's Agent Payments Protocol, AP2 (September 2025), which records a user's instructions as signed "mandates"
- Parties
- the agent developer or platform, the user or business it acts for, the merchant, the network or bot-management layer that validates the agent, the card issuer and acquirer, and the compliance teams answerable for the outcome
How know your agent works in practice
A shopper tells an assistant to reorder printer ink under £40. The assistant's agent reaches the retailer's site, where older bot rules would treat it as a scraper and block it. Under a KYA scheme it signs each request with a key registered in a card network's directory and tags the request as browsing or paying; the retailer's bot-management layer fetches the public key, checks the signature, its timestamp and its one-time nonce, and lets it through. At checkout the agent passes payment details the network can link to the cardholder, together with a record of what the user asked for — in AP2's terms an intent mandate, then a cart mandate approving the exact items and price.
Each layer answers a separate question. The signature says which agent this is; the registration says who operates it; the card issuer's own KYC says who the principal is; the mandate says what was authorised. When a customer later disputes a purchase — "I never asked for that" — the signed request and the mandate are the evidence, and who bears the loss depends on who could have checked what.
For a buyer of a payments, fraud or identity business, KYA is where those products are heading: bot management, tokenisation and authentication rebuilt for customers who are software. The diligence questions are which network programmes the target supports, how it binds an agent to a verified principal, and whether its records would win a dispute.
Example
A European online retailer sees 2 million agent sessions a month. It used to block all automated traffic except known search crawlers, turning away an estimated 40,000 purchase attempts a month at an average basket of €55. It switches to verifying network-registered agents: 70% of agent sessions now present valid signatures and pass, while unsigned traffic is still challenged. Agent-initiated orders reach 25,000 a month, about €1.4m of sales. Disputes on those orders run at 0.3%, against 0.5% on its other card-not-present sales, and the retailer wins most of them in representment by submitting the signed instruction and the cart the user approved.
Common mistakes
- Treating a verified agent as a verified customer; the principal still needs KYC. - Admitting agent traffic on its user-agent string or IP address, both of which can be spoofed. - Accepting instructions with no stated limits, so the mandate cannot be tested in a dispute. - Blocking all automation and losing the sales that registered agents would have made. - Keeping no link between the signed request, the mandate and the order, then losing the chargeback.