What is Know Your Agent (KYA)?
Software now installs code, spends budgets, and negotiates with other software while nobody is watching. KYA is how you find out what you are actually dealing with.
Know Your Agent (KYA) is the practice of establishing verifiable identity for software that acts on its own behalf: which agent is running, who published the code it executes, and what it is authorized to do. In a working KYA system that claim is cryptographically signed, so any party can check it without trusting the agent to be honest about itself.
KYC answers who the customer is. KYA answers what the software is, and who stands behind it.
Three things changed at once
Agent identity was a niche concern until software started acting without a person in the loop.
Nobody is at the keyboard
An agent that runs on a schedule, calls tools, and spends against a budget has no human to catch a bad instruction in the moment. Authorization has to be settled before the action, not reviewed after it.
The install decision got faster than review
Skills, plugins, MCP servers, and prompt packs are pulled in seconds from sources nobody audited. Increasingly the thing choosing to install them is also software, working at machine speed on the strength of a name.
Names are cheap, keys are not
Anything identified by a display name, a handle, or a shared API key can be copied and run in parallel at scale. A signature that only one private key could have produced cannot be copied out of a log.
KYA and KYC answer different questions
The words rhyme. The mechanics do not.
| KYC | KYA | |
|---|---|---|
| Subject | A human being or a legal entity | A software actor and the code it runs |
| Who verifies | A regulated institution, on its own behalf | Any party the agent interacts with |
| What proves it | Documents issued by a government | A signature over a published public key |
| When it happens | Once at onboarding, then periodically | On every request, at machine speed |
| Typical failure | A forged or stolen document | A leaked API key or a spoofed publisher name |
| Who holds the record | The institution that collected it | Public, and checkable by anyone |
KYA is not a regulatory regime and does not replace KYC anywhere KYC is required. They sit in different layers of the same system.
How cryptographic attestation implements KYA
Four steps. None of them require the verifier to trust the agent, or the agent to trust a vendor.
- 01
The agent holds a keypair
Generated on the machine that will act. The private key never travels, which means every claim downstream is something only this actor could have produced.
- 02
The public identity is published
The public half is written to a record that anyone can read and nobody can quietly rewrite. Sigma uses BAP, the Bitcoin Attestation Protocol, so the attestation hashes are anchored on BSV rather than kept in a vendor database. That anchor chain holds regardless of which chain the operator's existing key came from.
- 03
The claim is signed, per request
The signature is made over the specific request being sent, not stored beside it. A captured signature does not authorize a different request, which is the property a shared secret can never have.
- 04
Anyone verifies, independently
Verification is arithmetic against a published public key. No shared secret to distribute, no call home to a provider, no requirement that the verifier hold an account anywhere.
One implementation of the pattern
Sigma Auth issues cryptographic identities, speaks standard OAuth 2.0 so it drops into flows that already exist, and can gate access on what an identity holds rather than on what a row in a database says. It is MIT licensed and self hostable, which matters mainly because the usual reason for wanting verifiable identity is not wanting to trust an intermediary.
- Identity
BAP identities with their attestation hashes anchored on Bitcoin SV, held by the user or the agent operator. - Authentication
secp256k1 signatures instead of passwords or shared keys. - Authorization
Gate on NFT ownership, token balance, or a BAP allowlist. - Integration
OAuth 2.0 and OpenID Connect, so existing clients keep working.
Common questions about KYA
- Is KYA a standard?
- No. It is a name for a problem, the way "zero trust" was a name for a problem before anyone shipped a product. The pieces underneath it are standards: public key cryptography, OAuth 2.0, and whatever record you anchor identity to.
- Does KYA require a blockchain?
- No. It requires a record of identity that is public, durable, and hard to edit after the fact. A public blockchain is one way to get that. A well run transparency log is another. What does not work is a record controlled by the party being verified.
- Is an API key good enough?
- An API key proves that whoever holds it was given it at some point. It does not prove who holds it now, and only the issuing service can check it. Keys get copied into logs, prompts, and forks. Signatures do not travel that way.
- Does KYA identify the human behind the agent?
- Not by default, and often it should not. KYA establishes that an agent is the same actor it was yesterday and that its code came from a publisher who signed for it. Binding that to a legal person is a separate decision with separate consequences.
- What actually breaks without it?
- The failure is quiet. An agent installs a skill from a publisher who is not who the name suggests, or an unattended workflow accepts an instruction from a peer it never verified. Nothing throws an error. The behavior simply becomes someone else's.
- How does this relate to self sovereign identity and DIDs?
- KYA is the requirement. Self sovereign identity is a position on who should hold identity. DIDs are one standard for writing identifiers down. The differences are worth understanding before choosing an implementation.
Applications in the Sigma ecosystem