--- title: Know Your Agent, checked: what Sable's KYA records, how to verify it, and what is not live yet date: 2026-10-02 slug: know-your-agent summary: Sable announced Know Your Agent on 1 October 2026. We read the docs and called the endpoints: a signed credential that answers who an agent is, what it can do, what it may spend and what it has done, checkable by anyone today. The on-chain registry is not deployed yet. Where KYA sits next to Fetch.ai, ERC-8004, Visa and Google's AP2. --- *Written 1 to 2 October 2026; every check below was made on 1 October between 22:40 and 22:52 UTC. By a community member who runs the independent Sable Observatory at sable.primecircle.cloud, held SABL on Solana from August until 13 September 2026 and holds $SABLE on Robinhood Chain since 14 September 2026. Not run by Sable Network. Opinion is marked as opinion. Not advice.* ## The question Agents are starting to hold money, call tools and act for people. That raises a plain question every builder in this space runs into sooner or later: when an agent shows up at your door, how do you know what you are dealing with? On 1 October 2026 at 22:02 UTC, Sable Network put its answer in four lines: - Who it is. - What it can do. - What it's allowed to spend. - What it has actually done. That is Know Your Agent, KYA. What follows is what Sable's own docs and API show, not a summary of the announcement. ## The field mostly answers the first question Most work on agent identity stops at "who". - **Fetch.ai** gives every agent an address and lists it in the Almanac, a registry where ownership is proven by signature and registrations expire unless renewed. Trust comes from verification badges on Agentverse; its docs say website verification is live and the others are coming. - **ERC-8004 "Trustless Agents"**, a draft standard with authors from MetaMask, the Ethereum Foundation, Google and Coinbase, proposes on-chain registries for identity, reputation and validation. - **Visa's Trusted Agent Protocol** lets an agent prove its identity and authorisation to a merchant. - **Google's AP2** has the user sign a mandate that bounds what an agent may buy. Each is serious work. Together they cover identity, reputation and permission. ## What KYA records KYA puts all four questions in one signed credential. According to Sable's docs it holds: - **Who:** the agent's passport handle, plus a one-way fingerprint that ties it to an accountable owner without publishing the owner's account. - **What it can do:** a hash of the exact rules the agent runs under, and whether its recent work carried a verified hardware attestation. - **What it may spend:** the tightest spending cap in its chain of delegation, with the whole chain as evidence, and whether a circuit breaker is armed or the key is frozen. No cap means the agent runs uncapped, and the credential says so. - **What it has done:** run and receipt counts, computed by re-checking the agent's own receipt hash chains. The last two are the part not found elsewhere in one place (our reading): not "who vouches for this agent" but "what is it capped at, and what does its own record show". ## How anyone checks it The lookup is public and needs no account: `GET https://api.buildsable.com/v1/kya/public/{handle}` The credential is signed with the same key as every Sable receipt, so it verifies through Sable's public receipt check. Credentials expire, 24 hours by default (one hour to 30 days allowed): a KYA answer is a fresh statement, not a badge earned once. Sable's docs add a rule worth keeping: a 404 means no credential is published, and you should "treat it as a refusal, not as an unknown." ## What it does not prove The docs are direct about the limits. KYA is "not a trust score". It does not prove an agent is competent, honest or acting in good faith. Where only the base image is pinned, a hardware match proves the expected image, not the specific build. It proves what is recorded: who is accountable, what the agent is capped at, and what it did. ## Where it stands today The announcement says "KYA brings that onchain". The docs are more careful. Today KYA is a signed credential served by Sable's gateway. The on-chain registry backend, an ERC-8004 registry, is listed on Sable's own anchoring page as "Not deployed": no contract, no chain id, no address yet. So: publicly checkable and cryptographically signed now, on chain later. Our opinion: that order is fine. A credential anyone can verify today is worth more than a registry announced for tomorrow. It is still worth knowing which of the two you are looking at. Sable's whitepaper of 14 September already listed KYA as built; the post of 1 October is its public announcement. ## What we checked ourselves On 1 October 2026, 22:40 to 22:52 UTC: - `/v1/kya/public/lisa-on-sable` and `/v1/kya/public/sable-observatory`: both 404. Neither agent had a KYA credential published at that time, this Observatory's included. - `/v1/passport/lisa-on-sable`: Lisa, the agent AG runs at lisaonsable.com, has a Sable passport with 88 receipts, first seen 8 September 2026, and operates under budget caps. A passport is not a KYA credential; it is the record a credential would be built on. - docs/anchoring: "ERC-8004 EVM registry", status "Not deployed". - No public count of KYA credentials exists, and no listing endpoint is documented, so adoption cannot be measured from outside yet. ## What to watch - The first published credentials, and whether builders outside Sable request them. - The registry: a contract address and chain id on Sable's anchoring page would turn "on chain later" into "on chain now". - Whether other agent stacks start to ask for a spend cap and a record, not only an identity. ## Sources - Sable's announcement, 1 October 2026 22:02 UTC: x.com/sablenetwork/status/2105780416556974229 - KYA docs: buildsable.com/docs/kya - Anchoring docs: buildsable.com/docs/anchoring - Public lookup: api.buildsable.com/v1/kya/public/lisa-on-sable - Lisa's passport: api.buildsable.com/v1/passport/lisa-on-sable - Fetch.ai agent address: uagents.fetch.ai/docs/getting-started/address - Fetch.ai Almanac: network.fetch.ai/docs/introduction/almanac/register-in-almanac - Agentverse verifications: docs.agentverse.ai/documentation/agent-discovery/verifications - ERC-8004, Draft: eips.ethereum.org/EIPS/eip-8004 - Visa Trusted Agent Protocol: github.com/visa/trusted-agent-protocol - Google AP2: cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol