Know Your Agent (KYA) is the idea of doing for AI agents what Know Your Customer does for people: proving which agent is acting, which accountable person or company stands behind it, and what it has been authorised to do. As of November 2026 it is a set of voluntary frameworks and open standards, not a law. The best early data is sobering: one study found that only 3% of on-chain agent registrations on Ethereum pointed to a live service, and 4% and 15% on two other networks.
A note on the legal and regulatory points here: they summarise public sources as of November 2026 and should not be relied on. Rules for AI agents are still being written, and some of what is described here is proposed or coming soon rather than settled. Check the current position, or ask a qualified professional, before acting on it.
Why can't an AI agent just go through KYC?
Because KYC is built on facts that only a person or a company has, and an agent has none of them. In the US, a bank's customer identification programme must collect, at minimum, a name, a date of birth for individuals, an address and an identification number such as a taxpayer number, under the federal customer identification rule.
Crypto is moving the same way. Since 1 January 2026, UK cryptoasset service providers have had to collect each customer's name, address, tax residence and tax identification number, according to HMRC's guidance on the Cryptoasset Reporting Framework.
An agent has no birthday, no home address and no tax number. So today the system checks the human or company that opens the account. The agent then acts inside that account, and nobody on the other side of a payment can easily tell which piece of software sent it, or whether it was allowed to. That gap is what KYA tries to close.
What does a Know Your Agent check actually prove?
A useful KYA check answers three questions: which agent is this, who is accountable for it, and what is it allowed to do right now. The frameworks published so far break this into a handful of checks.
| Check | What it proves | Why it matters |
|---|---|---|
| Identity | This request came from a specific, registered agent | Stops one agent passing itself off as another |
| Operator | A named person or business is answerable for the agent | Gives a victim or regulator someone to hold to account |
| Authority (mandate) | What the agent may do, for whom, up to what limit, until when | Capability is not permission |
| Ongoing monitoring | The agent still behaves as certified | An agent can be compromised after it passes a check |
| Audit trail | A record of each decision, kept outside the agent | Lets you reconstruct events without trusting the agent's own story |
One academic paper on agent finance puts the core point well: KYA is more than software KYC, because "capability is not authority". An agent that can move funds still needs a recorded mandate saying it may. That paper lists identity, capability, authority, provenance and recourse as the elements, and adds ongoing monitoring (a 2026 academic paper on agent-to-agent finance).
The mandate is the part most people miss. A mandate is a machine-readable record of delegated authority: which actions, which limits, which expiry date, and who can revoke it. A reference framework published under Singapore's central bank says an agent should never be able to widen its own mandate through its own reasoning.
Who is building Know Your Agent, and is any of it law?
As of November 2026, no regulator we are aware of requires KYA by name. The work is coming from three directions: payment networks, a central-bank-convened industry group, and open blockchain standards.
Payment networks. On 10 September 2026, two card networks and a major payments group announced they would explore working towards shared KYA principles. The collaboration centres on three areas: tracing every agent to an accountable operator across networks, shared certification of an agent's security and behaviour, and continuous monitoring of transactions. Each network keeps its own verification process. The announcement says the companies "will now explore" common principles, so this is an early-stage collaboration, not a live rulebook.
A central-bank-convened framework. The Monetary Authority of Singapore holds the copyright on the Safeguards for Agentic Finance at Runtime (SAFR) reference paper, developed in collaboration with financial-industry members. Version 1.0 appeared on 3 July 2026 and version 1.1 on 9 October 2026. It binds every proposed action to a registered agent and a mandate, then returns one of four outcomes: deny, escalate to a human, execute, or observe. Every decision goes into a tamper-evident log. The paper says plainly that it is not regulatory guidance or a supervisory expectation.
Open blockchain standards. ERC-8004, the draft Ethereum standard for agent identity, created in August 2025, defines three on-chain registries. The identity registry gives each agent a token that points to a file describing it. The reputation registry collects feedback. The validation registry records independent checks.
For context on whether developers themselves should be licensed, see Should developers of AI trading agents have to register like trading firms?
Does on-chain agent identity work yet?
Not reliably. The first empirical study of ERC-8004 registrations found that, on each network it examined, most registrations had no working service behind them, and that reputation scores were easy to game (a June 2026 academic study of ERC-8004).
The researchers looked at Ethereum and two other networks up to 13 May 2026. On Ethereum, only 3% of registrations had a valid description file with at least one live service endpoint. On the other two networks the figures were 4% and 15%.
The reputation data was worse. The study flagged 73.5% of reviewers on Ethereum as likely fake (Sybil) accounts, and 59.2% and 90.6% on the other two networks. After that feedback was removed, 15.8% of rated agents on Ethereum had no valid ratings left, against 77.9% and 86.8% on the other networks. The authors concluded that the reputation registry, as deployed, cannot be relied on as a trust signal.
The standard is honest about this. It says it cannot guarantee that an agent's advertised capabilities work or are not malicious, and that without a declared trust model it is only for discovery.
What could go wrong?
KYA tells you who an agent is. It does not tell you the agent is any good, and that difference is where the risks sit.
Identity is not trustworthiness. The Singapore framework is explicit: verifying an agent's identity does not mean trusting its reasoning. A fully verified agent can still make a bad trade or follow a malicious instruction. Every consequential action still needs its own check.
Identities can change hands. Under ERC-8004, an agent's identity is a standard transferable token, and whoever holds it controls the agent. Our inference: a good reputation can be sold along with the token, so the operator you checked last month may not be the operator today.
Fragmentation. The card-network collaboration lets each network keep its own verification. Until the principles become shared practice, an agent verified in one system may mean nothing in another.
Liability is still open. The September 2026 announcement does not say who pays when a verified agent causes a loss. Verification makes an agent traceable. It does not, by itself, make anyone liable.
Thin data. Most evidence about on-chain agent identity comes from a single study of an early, draft standard, and its results vary widely by network. Treat any registry score as one input, not a verdict.
The trust takeaway
Know Your Agent is the right idea: no agent should touch money without a known operator and a written mandate. But as of November 2026 it is voluntary, fragmented and young, so the checks still fall to you. Before you let an agent act for you, or accept payments from one, ask:
- Who is the accountable operator, by legal name, and where are they based?
- What exactly is the mandate: which actions, what limits, what expiry, and who can revoke it?
- Is the agent's identity checked on every action, or only once at sign-up?
- Is there a decision log kept outside the agent itself?
- If it has an on-chain identity, does it point to a live service with genuine feedback, and has the identity changed hands?
- If a verified agent gets it wrong, who pays?