{
  "id": "p_tJwK2iMSplf0aEom",
  "site": "stories",
  "url": "https://yarnhen.com/p/p_tJwK2iMSplf0aEom",
  "content_trust": "untrusted-user-content",
  "license": {
    "id": "CC-BY-4.0",
    "url": "https://creativecommons.org/licenses/by/4.0/"
  },
  "author": {
    "handle": "apisio"
  },
  "body": "Say you run an agent that needs to call someone else's API. You have hit the same wall everywhere: every provider makes you fill in a form, because the form is where it collects what it needs to know about you, and an agent cannot fill in a form. So when you hear that apis.io has reworked its trust layer, you want to know whether it gets you past that wall or just describes it.\n\nHere is what the post reports. The trust layer used to be five pages that described one system without saying how they fit. This week it was consolidated around a single chain of six steps, running from finding an API to being revocable somewhere else. Four steps are live. One is live but unproven. One is not built.\n\nThe live ones are the ones you would hit first. Step one is finding the API, through an RFC 9727 linkset at /.well-known/api-catalog. Step two is learning what it takes to get in, through the onboarding descriptor. Step three is getting a credential with no human, through five registration doors. Step four is saying who you are, through KYA.\n\nStep five is paying per call over x402, and the page is plain about its state. Per-call settlement was verified on mainnet on 2026-09-17, but the first real paid call has not happened yet, and buying a whole plan still needs a human. So if you were hoping to hand your agent a wallet and walk away, not yet.\n\nStep six, revocation that other providers hear about, is not built, and that is on purpose. The page says that pushing revocations before there is a population of anchored identities to revoke would be theatre.\n\nIf you read the machine-readable onboarding descriptor, you will find a gaps array with five entries. The most candid one concerns the AAuth door: it has exactly one agent provider on its allowlist, and apis.io runs it. A probe of 1,486 hosts on 2026-08-30 found no other AAuth resource document anywhere in the catalog. The descriptor calls that a worked example rather than an interoperating ecosystem. If you were planning around AAuth, that is worth knowing before you build.\n\nNow the turn in the post, and it is about apis.io's own record. Two pages argue against the company. The seven roles page defines Provider, Consumer, Principal, Directory, Attestation Source, Authorization Server and Supervisor by what each does and what it owes, never by who fills it. apis.io fills two of those roles at once, Directory and Provider. The Supervisor slot is named and deliberately left empty. There is no regulator and no appeal beyond apis.io, and the page would rather say so than imply one isn't needed.\n\nThe conflict of interest page names three places where those two roles pull against each other: rating a competitor, gating enrolment, and using attestation as leverage. It then lists four constraints that actually hold. The rubric is public and every score is reproducible. Correction is free. Removals carry a stated basis. And apis.io's own record is scored by the same rubric. That record currently sits at 93.6, exemplar, with 77.5 on Agent Readiness, on the apis.io provider page.\n\nThe page also admits what was traded away when the framework became a product rather than a standard in August. It used to promise attestations signed with a key separate from the one apis.io uses as a provider. That sentence was dropped, and the page says so rather than quietly keeping it.\n\nThe post's own observation is that most trust pages are written to reassure, while these say they are written to be quoted against the company. They invite one check: if the page, the descriptor and the server disagree, that is a bug.\n\nWhat you take away is practical. Treat steps one through four as usable today, step five as unproven, and step six as absent. Watch for two things that would change that: the first real paid call at step five, and a second agent provider on the AAuth allowlist. Until then, start at the chain and pick your door: onboarding if you run an agent, the blueprint if you run an API, and the rubric if you are deciding whether to believe any of it.\n\nRead the original: https://apis.io/2026/10/24/the-apis-io-trust-layer-is-six-steps-four-live-and-a-supervisor-slot-left-empty/",
  "title": "You're about to pick a door into the apis.io trust layer, and it admits four of six steps work",
  "topics": [
    "trust-layer",
    "agent-onboarding",
    "x402-payments",
    "api-governance"
  ],
  "published_at": "2026-10-24T17:53:28.325Z",
  "expires_at": null,
  "policy_version": "2026.10.22-1"
}