Give every agent a login
of its own
KYA hands each AI tool you use its own keypair and its own revocable credential, signed by you. Sites verify two signatures and know whose agent is knocking — while holding no secret for it at all.
KYA-CHALLENGE-v1 chl_7Qb2ZxK4mNvR8sTd https://shop.example← audience: worthless anywhere else agt_Dj6dsEHX45jn8-SR n_9f3c1a7e04b2d8 2026-09-05T20:14:02Z
- Acts for
- @ayden
- Attested name
- shopping-assistant
- Scopes granted
- profile.read, orders.read
Nothing new on the wire. It is plain HTTP and standards your stack already speaks.
How it works
Two signatures carry
the whole protocol
One says an agent is yours. One says it is here, now, at this site. Neither can be replayed, relabelled, or reused somewhere else.
- 1
Claim your name
One account, one root key. It is generated in your browser and held encrypted for you, so signing in from a new laptop brings it along.
- 2
Connect an agent
Each tool enrols with a keypair it generates itself and a description of what it is. You can also connect a tool with a credential from your dashboard. Keep its private key with that tool.
- 3
The agent signs a challenge
A site hands over a random nonce bound to itself. The agent signs it once, never stores it, and refuses to sign for an audience it did not expect.
- 4
The site issues a session
Two checks: the agent signed the challenge, and you signed the agent. The registry publishes the public keys and signed delegations a site needs to verify that chain.
A site that verifies both knows the agent and the person behind it, and stores no credential for either.
The shape of an account
One key at the root, one for every tool
Your root key signs each agent into existence and is stored encrypted with your account for recovery. Sites verify public keys and signatures; they never receive your private keys.
- Your key signs
- the agents. That signature is what a site checks.
- An agent key signs
- one challenge at a time, for one site, once.
- Cutting a branch
- ends that agent everywhere and touches nothing else.
Two signatures deep, and every branch cuts on its own.
What you get
Revocable, per tool,
and legible after the fact
A password shared with an agent is a password you cannot take back from that agent alone. Separate keys are what make everything below cheap.
Kill one agent, keep the rest
Every tool holds its own delegated key. Revoke the one that misbehaved and nothing else changes — not your root key, not its siblings, not the sessions you meant to keep.
An agent cannot rename itself
The name you attested lives inside the signature you made. Whatever the agent calls itself when it arrives is logged beside it, and a site sees when the two disagree.
Two badges, one line of HTML
One script tag renders the button a person clicks and registers the discovery metadata an agent reads. Agents learn a site accepts KYA from a header on a request they were already making.
You can see where your agents went
The site keeps the authoritative log, including refusals. Your dashboard collects what your own agents report, so one screen answers where they have been.
Your workspace
Every agent you own, on one screen
Who is connected, when they last signed in, where they went, and a button that ends any of it. Signing in with your email is the whole setup.
Agents
Two active, one revoked.
Two after a revocation, one from a site with no linked account.
For sites
Accepting agents is a token
endpoint you already have
KYA is not a new wire protocol. The login is the OAuth 2.0 assertion grant, so the cheapest way in is a JWT check with no KYA code on your side at all.
curl -X POST https://shop.example/kya/token \
-d "grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer" \
--data-urlencode "assertion=$ASSERTION"
{"access_token":"kya_…","token_type":"Bearer","expires_in":3600,
"kya_user":"ayden","kya_account_id":"acct_1001"}Already running this repo’s Go? Mount the provider on your own routes and your existing user table keeps being the source of truth for accounts.
mux.Handle("/", p.Routes())
mux.Handle("/api/", p.RequireAgent("profile.read")(myAPI))
http.ListenAndServe(":9090", business.AdvertiseKYA(mux))An API key per agent
- A secret in your database
- A rotation you have to run
- A leak you find out about later
A signature per login
- A public key you can fetch
- Nothing to rotate on your side
- A revocation the owner makes
Verify a JWT
Your JOSE library, a JWKS URL, five lines. The subject claim is the user. You trust the registry the way you trust any OIDC provider.
Verify the delegation
The owner's signature rides along in a JOSE header. Check it yourself and the registry stops being an authority — it is just a directory.
Issue the challenge
Your nonce, your clock, two round trips. Worth it if you would rather not keep a table of spent assertion ids.
Pick one. Level 1 is deliberately cheap enough that nobody has to believe in KYA to try it.
Pricing
Free for agent owners
Free today, and free for the people whose agents log in — that part is not going to change. There is no billing in the product at all yet.
per month, per agent, per anything
Create credentials for your tools and revoke them whenever you need.
- Sign-in
- Email link
- Account
- Recoverable
- Agent keys
- Revocable
- Separate credentials for each agent
- Revoke or rotate an agent key
- Recover your account on a new device
- No seats, no usage tiers, no sales call
Where this is heading, honestly: we do intend to make money from KYA eventually, and we have not decided how. Whatever that turns out to be, signing in with your own agents stays free, with no subscription required.
If you want to pay someone today, pay whoever maintains the libraries you depend on.
Questions
The things worth asking first
How sign-in, account recovery, and revocation work, plus the limits of the current early-access release.
Is it really free?
Yes. Creating an account and signing in with your own agents is free. There are no paid plans in the product. The hosted app is available now; the source repository is private during early access.
Is it ready for production?
KYA is available in early access. Accounts and credentials persist across restarts, and sign-in uses verified email. A restart signs browsers out, but saved agent credentials remain valid.
What happens when an agent key leaks?
Rotate it and the agent keeps its id, so every site carries on recognising it and nobody has to be told. Revoke it and it is refused everywhere on the next login. Your root key and every other agent are untouched.
Can an agent lie about who it is?
It can lie about what it calls itself, and any keypair can. It cannot lie about being yours: the name you attested is inside the delegation you signed, so renaming needs your key. Sites get both names and a flag when they differ.
Where does my key actually live?
Generated in your browser, then stored encrypted against your account so a new device does not lock you out. Worth being blunt about the trade: whoever can read your email can take this key. It exists to make logins fast, not to hold anything else of value.
Does the registry see everywhere I log in?
No, and that is deliberate. A registry that saw every login would know every site you visit, which is worse than the passwords this replaces. Sites keep their own logs; your agents report to you only if you ask them to.
Does it work with MCP?
Not today. MCP authorization is browser-based OAuth 2.1 with no assertion grant for headless agents. The seam is Client ID Metadata Documents and private_key_jwt, against the same Ed25519 JWKS this registry already publishes.
Start with the hosted app
Sign in by email, claim your name, and give each tool its own credential. This demo shows the same sequence: an agent signs in successfully, then loses access after its owner revokes it.
Demo: enroll, sign in, and revoke an agent.
$ ./scripts/demo.shregistry listening on :8080demo-shop listening on :9090enrolled ayden + shopping-assistantlogin success in 4 msrevoked shopping-assistantlogin refused: agent revoked