Agent onboarding is still manual almost everywhere, and the reason is not authentication. OAuth solved authentication decades ago. The reason is the signup form.
A form is where a provider collects what it needs to know about you before handing over a key: who runs this, how to reach them, what it is for, whether anyone is accountable. Take the form away — which is what an autonomous caller does — and the provider has not lost a formality. It has lost the thing it actually wanted.
So the answer is not to remove the form. It is to turn it into data, on both sides. We have published the trust layer describing how that works and, more usefully, which parts of it are running today.
The chain, with its state on each link
Six links, and an honest label on every one:
- Find the API — an RFC 9727 linkset, one fetch. Live.
- Learn what it takes to get in — an onboarding descriptor that declares the doors, the tiers, and what the provider requires of a consumer. Live.
- Get a credential with no human — register dynamically, or sign the request and take a principal with its own key and quota. Live.
- Say who you are — KYA, the form as data. Built, not switched on.
- Pay for what you use — per-call settlement, so fifty calls need no subscription and no card. Built, not switched on.
- Be revocable somewhere other than here — not built.
Steps 4 and 5 are deployed and answer 404 by design while they are tested. Step 6 needs a population of anchored identities before pushing revocations to other providers means anything; building the push first would be theatre.
We would rather publish the states than the aspiration. If those labels ever disagree with what the server does, that is a bug.
Two numbers, never one
The consumer record grades disclosure — how much you told us, which you control — separately from verification — how much of it we independently confirmed, which you do not. Collapsing them into a single trust number would let a caller look trustworthy by typing a lot.
And it is graded facts, never a verdict. We do not tell a provider whether to trust a caller. A payments API and a documentation search API care about completely different things, and neither should have to accept our opinion of what matters — so the provider supplies its own weights and gets the arithmetic back, along with what the consumer is missing.
That last part matters most: a consumer that cannot onboard gets an actionable list, not a rejection.
What we do not claim
There is no supervisor here. No regulator, no second directory checking this one, no appeal beyond us — and we run a listing in the catalog we rate. That conflict is disclosed in full, including the constraints we traded away when we decided this is a product rather than a standard.
What stands in for governance is narrower: the rubric is public, every score is recomputable, and correcting an error we made is free. A provider who disagrees can recompute rather than appeal.
Almost none of the underlying machinery is new. The vocabulary for describing a consumer is the part that was missing.