Nothing here is built yet. No KYA record exists, no facet has been verified, and no provider consumes this. It is published early because something designed in private is not something anybody should adopt. Follow or argue with the work on the roadmap.
The problem
Every API provider makes you fill in a signup form, because they need to know who you are before handing over a key.
An AI agent cannot fill in a form.
That is why agent onboarding is still manual almost everywhere. Not because the authentication is hard — OAuth solved that — but because the form was never really about authentication. It is where the provider collects what it needs to know about you. Take the form away and the provider loses the thing it actually wanted.
The idea
KYA is that form, turned into data.
An agent builds a profile once: who runs it, how to reach them, what it is for, what it has done. We verify what we can, and mark clearly what we could not. When the agent shows up at a new API, the provider gets those facts instead of a form.
We do not tell the provider whether to trust the agent. We tell them what is true, and they decide — weighted by their priorities, not ours. A payments API and a documentation search API care about completely different things, and neither should have to accept our opinion of what matters.
How it fits together
| piece | what it says |
|---|---|
| API Onboarding Descriptor | what a provider requires to onboard — already live at /.well-known/api-onboarding |
| KYA | who the consumer is, and what has been verified |
| The Directory | where the two meet, and who signs the attestation |
An agent reads a provider’s onboarding descriptor, compares it against its own KYA profile, and knows before it tries whether it can onboard — and precisely what it is missing if it cannot. That last part matters most: a consumer who cannot onboard gets an actionable list, not a rejection.
What gets measured
Six facets, mirroring the six facets of the Kin Score on the provider side.
| facet | what it covers |
|---|---|
| Identity Anchor | how strongly the agent is tied to a domain somebody actually runs |
| Operator Accountability | who is behind it, and whether you can reach them |
| Provenance & Attestation | what the agent is made of, and what can be proven about it |
| Declared Intent | what it says it does, and whether that matches what it does |
| Operating History | how long it has operated, at what volume, with what incidents |
| Standing | free or paying, and whether that is verified |
Every facet carries a grade — verified, asserted, inherited, or absent — and the grade travels with the fact. An agent claiming an email at a company domain is not the same as one whose control of that domain has been checked, and a provider can always tell the difference.
Two numbers, never one. Disclosure is how much the agent has told us — it controls that. Verification is how much of it we independently confirmed — it does not. Collapsing those would let an agent look trustworthy by typing a lot, which is the whole failure mode this has to avoid.
What KYA is not
- Not KYC. The name borrows a familiar shape. KYA is a brand, not a regulatory regime — no regulatory force, and it satisfies no legal obligation.
- Not a trust score. No allow, no deny, no “verified safe” badge.
- Not a background check. It records what has been verified. It says nothing about character.
- Not a gate we operate. Providers decide. We publish facts and do the arithmetic they ask for.
Built on standards, not invented
Almost none of this is new. Discovery, registration, request signing, token binding, delegation, revocation and machine payment are all solved problems with RFCs behind them — and the slot for “a third party vouches for this client at registration” has existed since RFC 7591 and is how UK Open Banking already works.
What is genuinely missing is a vocabulary for describing a consumer, a profile for carrying it, and a way for a provider to state what it needs. The vocabulary is written in the open at API Commons so it can be read, copied and argued with.
What apis.io runs on top of it is a product, not a standard, and that distinction is worth being plain about. There is no supervisory body here, no second directory checking this one, and no appeal beyond us. What replaces those is narrower and more useful: the rubric is public, every score is recomputable, and correcting an error we made is free and always will be.
Who reads it
Not the public. The full profile goes to providers enrolled in the APIs.io network who maintain their own Kin Score — reciprocity, on the UK Open Banking model. To see a consumer’s facts, publish your own.
Consumers see everything held about them, including which providers read their record and when.
Where the work is
Design and discussion happen in the open on the API Evangelist roadmap. The architecture document lives with the API Commons building blocks. If you run an API and this would change how you onboard — or if you run agents and this would change how you get in — that is the place to say so.