Skip to content
↑↓ to move · Enter to openEsc to close
Glossary · Policy and regulation

Know Your Agent (KYA): vetting AI agents before they act

Updated

As agents start to book, buy and negotiate, businesses face the question banks faced with customers: who am I dealing with? Several vendors now use the term Know Your Agent for products and programs that answer it, and their definitions vary. What they share is a need for an identity signal that holds up under scrutiny.

AgenID is not a KYA program. It is an open identity layer a KYA program can build on: a permanent identifier, an operator-signed manifest, and records any party can re-verify without trusting the registry that served them.

Definition

Know Your Agent (KYA) is an emerging industry term for the checks a business runs before letting an AI agent act on its systems: which agent it is, who operates it and what it may do. It borrows its shape from Know Your Customer programs in finance.

Also known as: KYA

Where AgenID fits in a KYA program

A KYA check typically needs three inputs. First, a stable identifier to attach decisions to, which AgenID provides as agenid:<ULID>. Second, an accountable party, which the agent manifest names along with an operator domain and contact. Third, evidence about that party, which AgenID models as a verification assertion scoped to one claim. A program resolves the agent at /verify, re-checks the signature and applies its own policy.

What exists today

Registration, resolution, the Verification Card and badges are live at agenid.com. The reference registry issues nothing above L1_REGISTERED, a registered self-declaration. L2 domain verification and higher require a VerificationAssertion signed by a root authority key, and that key has not been created yet. Operators can already record domain-control evidence at /verify/domain; that evidence raises nothing above L1.

What a KYA program still decides

Identity is one input. Which agent is acting is a different question from what it is allowed to do, and v1.1.1 defines no signed permission object; a v1.2 authorization layer is a draft in development. Risk scoring, limits and policy stay with the business running the program. The KYA guide shows how the pieces fit.

Frequently asked questions

Is KYA a standard?

Not today. It is an industry term used in different ways by different vendors. AgenID is an open protocol with a public specification that a KYA program can adopt as its identity layer.

Does an AgenID identity pass a KYA check on its own?

No. It gives the check something reliable to inspect. Whether that is enough is the relying business's policy decision.

Does KYA with AgenID require sharing private keys?

No. Operator keys are generated in the browser or with the CLI and are never sent to the registry.

What agenid.com issues today

The reference deployment at agenid.com issues DECLARED and L1_REGISTERED only. L2_DOMAIN_VERIFIED and higher require a VerificationAssertion signed by a root authority key, and that key has not been created yet. L5 is reserved by the specification and is not issuable at all.

Identity is not permission

Which agent is acting and who declared it is one question. What that agent is allowed to do is another, and it stays with the party on the other side and with the operator. Protocol v1.1.1 defines no signed authorization object.

Sources

  1. AgenID protocol specification (public repository)

Give your agent an identity

Register an agent in the browser — the signing key is generated on your device and never sent to AgenID — or resolve an existing AgenID and re-check its signature yourself.