An AI agent spent the money and nobody can say who allowed it. Know Your Agent is how you answer.

Picture a pattern, not a named case. A customer you verified last year connects an AI assistant to their account. Three weeks later the assistant buys something expensive, or opens a second account, or pays a new recipient. Every control passes: the login, the token and the card were all valid.

Then the customer says: I never asked for that.

You go to the logs to find out who authorised it, and the logs say the customer did. The agent was acting as them. There is no record of what the customer told it, what limit they set, or which piece of software actually pressed the button. Nothing failed, and you still cannot answer.

That gap has a name now. People call it Know Your Agent, or KYA.

Why KYC and KYB do not answer it

KYC answers one question: is this person who they say they are? KYB answers the same question about a company. Both assume the party you verified is the party who acts.

An agent breaks that assumption. It leaves four questions open.

1. Which agent is acting? Not which customer. Which piece of software, run by which company, on which platform.

2. Whose agent is it? Which verified person or business stands behind it.

3. With what permission? What it was told it may do: how much, with whom, until when.

4. Who answers for it? When the purchase is wrong, who carries the loss, and what evidence settles the argument.

We did not coin the term. Trulioo and PayOS described a Know Your Agent framework with Worldpay in August 2025 (opens in a new tab). The OpenID Foundation's paper on agent identity describes the KYAPay protocol as extending KYC and KYB verification "to the agent itself" (opens in a new tab). Experian published its own definition (opens in a new tab) in June 2026. As of October 2026 there is no single agreed standard behind the phrase. It is a direction, not a specification.

What the industry has actually built

A great deal has shipped since early 2025. Each piece proves something real and leaves something open.

• Mastercard Agent Pay (29 April 2025). Introduces Agentic Tokens and says the programme will require trusted AI agents to be registered and verified (opens in a new tab) before they pay for their users. It proves the agent is known to the network, and it promises consumers control over what the agent may buy. The announcement does not describe the form that permission takes, or who can inspect it later.

• Cloudflare signed agents and Web Bot Auth (28 August 2025). An agent platform signs its HTTP requests (opens in a new tab) so a website can verify which agent is calling. The IETF working group now standardising this is explicit about its edge: "authentication of the end user is out-of-scope" (opens in a new tab). It answers question one and deliberately stops there.

• Google's Agent Payments Protocol, AP2 (16 September 2025). The most direct attempt at questions three and four. A user signs a Mandate, which Google describes as "verifiable proof of a user's instructions" (opens in a new tab): an Intent Mandate with limits for delegated tasks, and a Cart Mandate for the exact items and price. It is evidence of permission. The announcement does not say who verifies the identity of the user who signs.

• OpenAI and Stripe's Agentic Commerce Protocol (29 September 2025). Stripe issues a Shared Payment Token that is "scoped to a specific merchant and cart total" (opens in a new tab). The permission is narrow and hard to misuse. It covers one purchase the buyer just confirmed, not a standing delegation.

• Visa Trusted Agent Protocol (14 October 2025). Built with Cloudflare, it lets approved agents pass agent intent, consumer recognition and payment information (opens in a new tab) to a merchant. That helps a merchant tell a real shopping agent from a bot, and see whether the shopper is already known. What the shopper told the agent is not one of the three items.

• x402. A payment standard for HTTP whose own site promises "No accounts or personal information needed" (opens in a new tab). That is the opposite design choice: payment with no identity at all. Hard to reconcile with any duty to know your customer.

Underneath, the identity community is doing slower work.

• The OpenID Foundation's whitepaper (opens in a new tab) (7 October 2025) says today's standards already secure many agent uses, then lists what they do not. Its sharpest line: "User impersonation by agents should be replaced by delegated authority." (opens in a new tab) It also warns that users will face thousands of approval requests and start approving by reflex, that agents which hand work to other agents create chains nobody scoped, and that agents driving a browser bypass API controls entirely.

• An individual IETF draft (opens in a new tab) proposed OAuth parameters that name the agent in the consent request and in the token. It has expired: an idea on record, not a standard.

• The Model Context Protocol authorisation specification (opens in a new tab) (the June 2025 revision we read) builds on OAuth 2.1 and makes tokens valid for one server only. It also says authorisation is optional for implementations.

Put together: the industry can increasingly prove which agent is calling, and is starting to prove what a user approved. Nobody has yet joined those to a verified principal and an agreed answer on accountability.

What regulators have said: not much yet

We looked for rules and found mostly intent.

• The UK's FCA said in its Payments Regulatory Priorities (opens in a new tab) of March 2026 that its work with the Treasury "will include considering whether change or development of regulation is needed to support agentic AI payments". Considering, not deciding.

• In Singapore, an industry group working under an MAS initiative published Safeguards for Agentic Finance at Runtime (opens in a new tab) on 3 July 2026. It proposes checking every agent action before it executes, starting with an Agent Identity step and ending with an append-only audit log. The paper itself says (opens in a new tab) it "does not constitute regulatory guidance or supervisory expectations".

• The FSB consulted in June 2026 on sound practices for responsible AI adoption, and says they are "not intended to establish an international standard" (opens in a new tab).

We have cited the UK, Singapore and one global body. We have not cited your regulator, and we could not open the FATF's paper on AI, so we will not characterise it. In the documents we read, as of October 2026, no rule tells you how to verify an agent. The existing duties to know your customer and to evidence consent have not gone away while that is worked out.

What stays the same

Strip away the protocols and one fact holds. An agent has no money, no legal standing and nothing to lose. Every agent acts for a person or a business, and that principal is who you onboard, who you screen, and who you go back to when something is wrong.

So the foundation of KYA is ordinary KYC and KYB. What is new sits on top:

• Binding. A durable, checkable link between this agent and that verified principal.

• Scope. A record of what the principal allowed, precise enough to compare with what the agent did.

• Presence. A way to bring the human back when the stakes rise, because a standing permission should not cover everything.

• Record. Evidence of who or what decided, kept at the time, that still reads clearly a year later.

What to do now

If you buy or own risk. Decide these before your customers decide them for you.

• Will you allow agents to act on customer accounts at all, and for which actions?

• Can you tell an agent session from a human one today? If not, that is the first gap.

• What is the amount or action above which a human must confirm in person?

• When a customer disputes an agent's action, what evidence will you hold, and who bears the loss under your terms?

• Ask every provider what their agent protocol proves, and what it leaves to you.

If you build. Nothing here needs a new standard to exist.

1. Verify the principal first. No agent access for an unverified customer or business.

2. Give the agent its own credential. Never the customer's password or session. Issue a separate, revocable token so its actions are distinguishable in your own logs.

3. Carry your customer reference on every action. Each payment, login or change the agent makes should name the customer it acts for and that it came from an agent.

4. Score every action, not just the session. An agent with a valid token can still do something the customer would never do.

5. Require a human step-up above a threshold. A new recipient, a large amount, a change of contact details: ask the person, not the agent.

6. Log the decision when it is made. What was asked, what was allowed, who or what decided.

What to watch. Whether AP2 mandates and the card networks' agent tokens converge, the IETF Web Bot Auth documents, the UK Treasury's work on payment rules, and the final versions of the MAS and FSB papers.

What exists today at Toden

To be plain: Toden does not have an agent-verification or KYA product today. We do not verify agents, issue agent credentials or validate mandates. What we do today covers the principal and the action.

• Verify the principal. Identity verification for people and business verification for companies, each stored against your own externalUserId, so the customer you verified is the same record you screen and monitor.

• Re-confirm the person is present. A face re-authentication workflow matches a live selfie against the face that customer enrolled. A step-up sends a hosted challenge and you continue only when it passed. We covered that in account takeover and step-up.

• Decide on each action. Send a transaction or an activity such as a login, a new beneficiary or a payout, and get allow, review or block back on the request. See sending events for real-time scoring.

• Keep the record of who decided. Every status change on a verification is kept with its source: a reviewer, your backend's API key or a workflow. Earlier decisions stay on record. Decision graphs explained shows how the rules are recorded.

• Docs built for coding agents. Every page as Markdown, an llms.txt index, OpenAPI contracts, an integration prompt and a documentation MCP server (opens in a new tab). That server searches the docs and runs no API calls. One that works with your account is planned and not available yet.

The limits matter. Toden cannot tell you an action came from an agent unless you send that fact. Device Intelligence reports emulators, failed app integrity and hosting networks, which can hint at automation, but none of that identifies an agent. A passed step-up confirms who is there, not what they understood.

What we think has to be built

This section is our view. It is not a product announcement, a roadmap or a commitment.

We think trust infrastructure needs a fourth pillar beside KYC, KYB and risk decisions.

• The principal is always verified, and the link is checkable. An agent credential that cannot be traced to a verified person or business should be worth very little.

• Permission is data, not a checkbox. A signed scope with an amount, a counterparty and an expiry, which the party receiving the request can read and compare with the action.

• Presence scales with the stakes. Routine actions run on the standing permission. Unusual ones bring the human back, with a real check that it is them.

• The record is written before the action, not rebuilt after. Which agent, for whom, under which permission, decided by what.

• Agent identity and customer identity meet. Today the agent protocols and the KYC record live in different systems. The party that already holds the verified customer is the natural place to join them.

None of that makes a wrong purchase impossible. It makes the question at the top of this article answerable.

This is not legal advice. The area is moving quickly, the regulatory papers cited here are consultations or proposals, and details may have changed since October 2026.

Want to start with the part that exists? Open a Toden workspace (opens in a new tab) or point your coding agent at the docs (opens in a new tab).