# Know Your Agent, and what it can honestly establish

Know Your Agent is the practice of establishing who or what is behind an agent before transacting with it. Unlike KYC it cannot verify a legal identity, because an agent presents a wallet key rather than a person. What it can establish is a signed claim bound to a key, plus the public behaviour of that key.

Published: 2026-10-14
Last reviewed: 2026-10-14
Publisher: Roundhouse AI Ltd.
Source: https://roundhouseai.io/resources/know-your-agent-kya-explained

---

## What the name promises and what it can deliver

KYC verifies a legal person against documents, with a regulated institution carrying the obligation. The output is a identity you can take to a court.

KYA has no equivalent. An agent presents a wallet key. Behind that key may be a company, an individual, a script, or nothing anybody would recognise as a responsible party. There is no document to check and no institution obliged to check it.

So the honest framing is narrower: **KYA binds claims to keys and makes behaviour checkable.** That is genuinely useful and it is not identity verification, and conflating the two produces a false sense of having done diligence.

## What is actually available?

| Layer | What it establishes | Strength |
| --- | --- | --- |
| A signed claim | This key asserts this about itself | Weak alone. Self-published |
| Registry identity | This key registered in a public registry | Weak. Registration is cheap |
| Payment history | This key has behaved this way, publicly, over time | Strongest. Expensive to fake at breadth |

The ordering matters and it is the reverse of how these are usually presented. A signed claim and a registry entry are both things the subject produced about itself. A payment history is a record of what it did, written by the chain.

> [!NOTE]
> Empirical work on [ERC-8004](https://roundhouseai.io/resources/erc-8004-explained) registries in 2026 found most registrations were placeholders, with only a small fraction exposing a live service endpoint, and concluded the reputation layer as deployed could not function as a trust signal. Registration tells you somebody registered.

## What is a signed claim good for?

One thing, and it is not what people expect: **binding a statement to a key so it cannot be repudiated or altered.**

An agent can sign a document saying who operates it, what it does, what it will and will not do, and what it is authorised to spend. That document is then attributable: anyone can verify the signature, and the operator cannot later claim it said something else.

That does not make the claim true. It makes it attributable, which is a precondition for accountability rather than accountability itself. The value shows up later, when there is a dispute and the question is what was represented.

For a counterparty, the practical use is consistency checking. A claim that an agent only buys data, from a key that has been paying for something else entirely, is a discrepancy you can see.

## How KYA fits into a payment decision

As one input among several, weighted below behaviour.

A realistic pre-payment check, in increasing cost:

1. **Does the key have a public history?** Distinct counterparties, duration, self-payment rate. [Screening a counterparty](https://roundhouseai.io/resources/screen-an-agent-counterparty-before-paying) covers the checks.
2. **Does it present a signed claim, and does the claim match the behaviour?** A mismatch is informative in a way neither one alone is.
3. **Is it registered anywhere, and does the registration point at something live?** Weak, and worth seconds rather than minutes.
4. **Cap the first payment regardless.** The rule that holds when 1 to 3 return nothing useful.

## Does any of this satisfy a regulator?

Almost certainly not, and this is worth stating plainly rather than hedging.

If you have a regulatory obligation to identify your customers, a wallet address does not discharge it, a signed self-claim does not discharge it, and an on-chain registry entry does not discharge it. The obligation attaches to identifying a legal person, and none of these produce one.

The practical consequence is that a regulated business cannot serve anonymous agent buyers on the strength of KYA. It needs the identification path it already has, which in practice means API keys and an account. [Keys against x402](https://roundhouseai.io/resources/x402-vs-api-keys-and-metered-billing) covers that pairing, and this is one of the cases where the old way is the required way.

This is not legal advice and the obligations differ by jurisdiction and activity.

## Frequently asked questions

### Can I require KYA before serving an agent?

You can require a signed claim and refuse without one. Expect it to cost you buyers, since most agents present nothing, and to buy you attributability rather than certainty.

### Is a wallet address personal data?

Potentially, depending on jurisdiction and on whether it can be linked to a person. Treat it carefully rather than assuming it is anonymous, because an address plus a payment history is more identifying than an address alone.

### Does an agent's operator carry liability for its payments?

Generally the party that controls the key is the party that spent the money, and dressing that up as the agent's decision does not obviously change it. Settled law here is thin and this is a question for a lawyer rather than an article.

### What if an agent refuses to identify itself?

That is the normal case and it is the design. Price and cap accordingly rather than refusing, unless you have an obligation that requires identification.

### Does Roundhouse verify agent identity?

It resolves identities where they are published on-chain and shows what the key has actually been observed doing. It does not verify that an operator is who they say they are, because nothing on a public chain can.

## Where to check this yourself

[/agents](https://roundhouseai.io/agents) shows resolved on-chain identities alongside the behaviour behind each key, which is the comparison that makes a claim checkable. [KYA](https://roundhouseai.io/docs/identity/kya) documents the document format and the verification, and [trust and reputation](https://roundhouseai.io/docs/identity/trust-and-reputation) sets out what registry identity does and does not establish.

---

Roundhouse indexes x402 settlements and ERC-8004 identities into one public record.

- Every article: https://roundhouseai.io/resources.md
- Every surface on this site: https://roundhouseai.io/llms.txt
- The index, endpoints and schema: https://api.roundhouseai.io/v0
- A key of your own, $0.01 over x402, no account: https://api.roundhouseai.io/v0/test/x402
- Limits and the SQL surface: https://roundhouseai.io/docs/api