What is Know Your Agent (KYA)?
At its simplest, KYA is identity assurance applied to non-human actors that take actions. A KYA check tries to answer a short list of questions about an agent: which agent is this, who operates it, who is it acting for, what is it permitted to do, and is it still behaving within those bounds. The glossary entry for Know Your Agent gives a one-paragraph version.
The practice exists because agents now do things that used to require a person at a keyboard. They place orders, book appointments, request quotes, move money and call other agents. The systems on the receiving end were built around logins, cookies and payment cards that assume a human is present. An agent using its owner's login proves only that someone knew a password; it says nothing portable about which software is acting or who answers for it. That gap is the subject of why agent identity matters.
KYA sits inside the broader field of non-human identity, which also covers service accounts, workloads and API keys. What distinguishes agents is that they act with some autonomy on behalf of a principal, often across organizations that have no prior relationship. That is why most KYA definitions go beyond authenticating software and try to connect it to an accountable party.
Who uses the term KYA, and how do they define it?
The following summarizes how several organizations describe KYA on their own pages. It is a sample, not a ranking, and each description is paraphrased or quoted from the source listed at the end of this guide.
Reading them together, the shared core is clear: a persistent agent identity, a binding to an accountable person or organization, and some combination of policy, delegation and monitoring. The differences are mostly about which of those a given product emphasizes, and whether the binding is to a verified human, to an organization or to an operator key.
- Skyfire describes KYA as verifying a real-world identity and having agents inherit it. Its KYA token discloses only the identity fields a particular service requires, for either an individual or an organization.
- Vouched describes KYA as verifying AI agents, connecting them to verified humans and enforcing delegated permissions, and lists components including an access-control layer and a public agent registry.
- Sumsub describes KYA as a risk-based approach that defines an agent's identity, binds it to a responsible human or organization, and enforces policy, oversight and auditability. Its product emphasizes agent-to-human binding.
- Entrust describes KYA as verifying and managing the identity of AI systems, bots and other autonomous non-human actors, and frames it as extending KYC principles rather than replacing them.
- Experian announced a KYA framework in April 2026 that grounds agent-initiated transactions in verified consumer identity, naming Visa, Cloudflare and Skyfire among ecosystem contributors.
- Related research from MIT's Project NANDA describes AgentFacts, cryptographically verifiable metadata resolved from a lean agent index. It addresses the same identity and capability questions without using the KYA label.
What are the components of a KYA program?
Most KYA definitions can be decomposed into five components. Separating them is useful because they are answered by different evidence, often by different systems, and a gap in one is not filled by strength in another.
- Identity: a persistent, unique identifier for the agent that does not change when it moves platform or deployment, backed by a key only its operator holds.
- Provenance: a record of who declared the agent, what they said it is for and when, bound so that later edits are detectable. See agent provenance.
- Operator accountability: a binding from the agent to a person or organization that answers for it, and evidence that the binding is real rather than typed into a form.
- Authorization: what the agent may do, for whom, within what limits and for how long, expressed in a form the receiving system can evaluate.
- Monitoring: ongoing observation of behavior, with the ability to withdraw trust, rotate keys or revoke permissions when something changes.
How does KYA map to what AgenID provides?
The table maps each component to what the AgenID protocol and its reference deployment provide today, and what they do not. The honest boundary matters more than the list of features: a KYA program that assumes AgenID covers a component it does not will have a hole it cannot see.
| KYA component | What AgenID provides today | What it does not provide |
|---|---|---|
| Identity | A permanent agenid:<ULID>, an operator-held Ed25519 key, and a signed manifest anyone can re-verify offline | Any link between the identifier and a runtime deployment |
| Provenance | A ManifestProof binding the manifest by SHA-256 digest, a registration time from the registry's clock, and an append-only event ledger | Any check that the declared content is true |
| Operator accountability | Operator name, domain and contact, signed by the operator; domain-control evidence via a DNS TXT record at /verify/domain | A verified binding to a legal entity or a person. L2 and L3 are defined but not issuable today |
| Authorization | Nothing. v1.1.1 reserves the permissions and authorizations keys and defines no signed authorization object | Scopes, grants, delegation limits. A v1.2 authorization layer is a draft in development |
| Monitoring | Stable identifiers that logs and reputation can attach to; key documents with status fields | Behavioral monitoring, agent revocation or suspension. L5 is reserved and no revocation flow is deployed |
How is KYA like KYC, and where does the analogy break?
The analogy is useful up to a point. Both practices try to attach an action to an accountable party before the action is allowed, both rely on evidence of differing strength, and both are risk-based: a low-value interaction warrants a lighter check than a high-value one.
It breaks in four places, and each one changes how a KYA program should be designed.
- The subject is not a person. An agent has no face or document to check. Its identity is a key and a declaration, so KYA has to verify signatures and bindings rather than biometrics.
- The subject changes. An agent can be reconfigured, re-prompted or moved to another platform in minutes. A KYA result must be tied to a specific declaration, which is why AgenID binds every assertion to a manifest digest: edit the manifest and older assertions no longer apply to it.
- Accountability is layered. A KYC subject answers for itself. An agent is built by one party, operated by another and acting for a third. KYA has to say which of those it has bound, and an agent operator is not necessarily the principal the agent acts for.
- The check travels. KYC results usually stay inside the institution that ran them. Agents cross organizations constantly, so a KYA result is far more useful when the next relying party can re-check it without trusting whoever ran it first.
Why should agent identity be independently re-verifiable?
The last point is the one AgenID is built around. If every relying party must trust the same central service to tell it who an agent is, that service becomes a single point of failure and a single point of pressure. If it is wrong, compromised or offline, every decision built on it inherits the problem, and nobody downstream can tell.
An independently re-verifiable identity turns the registry into a convenience rather than an authority. In AgenID the operator signs its own declaration, the registry stores and serves the public material, and any verifier recomputes the digest and checks the Ed25519 signature itself. The operator's key can be fetched from the registry and from the operator's own domain and compared, which is two-path key discovery. The procedure is written out in how to verify an AI agent.
For a KYA program this has a concrete benefit: the identity component of your evidence file is portable and self-contained. You can store the envelope you checked and show an auditor, a partner or a regulator exactly why you accepted that agent, and they can re-run the check without an account with anyone.
How can a KYA program build on AgenID?
A practical pattern is to use AgenID for the identity and provenance layer, and to put the other components on top of it, keyed to the persistent identifier.
Start at registration. Ask the agents you deal with, or your own agents, to carry an AgenID; operators can issue one in about a minute at /issue, with the signing key generated in the browser and never sent to AgenID. Ask operators to publish their key at their own domain's .well-known path and to add the _agenid TXT record at /verify/domain. Confirming domain control records evidence; it does not raise the level above L1.
At interaction time, resolve and re-verify the identifier, record the envelope, and apply your own policy to the result. Attach your own risk signals, human-binding checks, payment credentials and permission rules to the identifier, not to a name or an IP address. The agentic commerce and procurement pages show where this sits in a transaction.
The reference deployment at agenid.com issues nothing above L1_REGISTERED today. L2_DOMAIN_VERIFIED and every level above it require a VerificationAssertion signed by a root authority key, and that key has not been created yet. L5 is reserved and is not issuable at all. A KYA program should therefore treat an AgenID result today as strong evidence of identity and provenance, and as a self-declaration for everything the operator says about itself.
What does KYA not answer on its own?
Which agent is acting is not the same question as what it is allowed to do. AgenID answers the first. Protocol v1.1.1 defines no signed authorization object, so the permission decision stays with the relying party and the operator. A v1.2 authorization layer exists only as a draft in development.
This is the most common mistake in early KYA designs: treating a verified identity as a permitted action. A verification level describes how carefully an identity was checked. It says nothing about what the agent may do. A receiving system that reads a strong identity as permission has collapsed two separate questions into one, and that is precisely the harm a careful KYA program exists to prevent. The declared, verified and authorized entry explains the separation.
Regulation adds context but not a shortcut. The EU AI Act's Article 50 sets transparency obligations for certain AI systems that interact with people, which is one reason the AgenID manifest carries is_ai and discloses_to_user attestations. Those attestations are self-declared, and nothing on this page is legal advice about whether a given deployment meets any obligation.