You Don't Verify the Agent. You Verify the Human Once. That's bitid.
A couple of weeks ago I closed a three-part series on agentic identity with a promise I don't usually make in public: I told you I had been building the thing I was describing, not just sketching it, and that soon I would show you what it actually looked like.
This is that post. The thing has a name — bitid — and a public home at bitid.net.
I want to be as honest here as I was in the series, because the rhetoric in this corner of the industry runs hot and I would rather under-claim. Bitid is not a live network you can transact on today. What we have published is a frozen protocol specification and the foundation of the chain that runs it. The design is settled; the build is underway. That is exactly the stage I said it was at, and I am not going to dress it up as more.
But the design is the hard part, and the design is done. So let me show you what the sketch became.
The whole idea, in one sentence a non-engineer gets
Strip away the cryptography and bitid is one move: you prove a fact about yourself without handing over the document that fact lives in.
Today, proving one small thing — that you are over 18, that you hold a valid licence, that you are a real customer — means surrendering your whole passport to yet another website and hoping it does not leak. Every verification spawns a fresh copy of your identity sitting in someone else's database, waiting to be breached.
bitid inverts that. You verify yourself once, with a trusted issuer — the way a bank checks you today. From then on you hold a credential only you control, and when a site asks "are you over 18?", your credential answers yes — cryptographically, in seconds — without revealing your name, your birthday, or which document said so. The line we settled on says it in six words: verify once, prove anything, reveal nothing.
No personal data ever touches the chain. The ledger carries approved-issuer records, status commitments, staking and governance — never a database of people. That last part matters more than it sounds, and it is what lets the same design carry agents.
The same machinery, turned over, solves the agent problem
The knot I could not stop thinking about in the series was this: to make an AI agent accountable, everyone attaches a real identity to the agent — and the moment you do, you have built surveillance. Accountability or privacy, pick one.
The inversion I proposed in the third post was to stop attaching identity to the agent at all. Verify the human once, and let only the fact of that verification flow into every agent they deploy — never the identity behind it.
That is not a sketch anymore. In bitid, a person does KYC once, then mints as many agent credentials as they want, one per agent. Each agent can prove exactly one thing: "I am operated by a KYC-verified, liable human, at assurance grade ≥ G, acting within delegated scope S, and I am not revoked." Not which human. Just that there is one, that they are real and accountable, and that they stand behind this agent. The agent proves backing. It never proves identity, because it never holds it. Your agents inherit the trust you established once — and no two of them can be tied back together into a profile.
The three invariants became three mechanisms
In the series I named three properties I said I would never break for convenience. It is worth showing you that each one is now a concrete part of the protocol, not a value statement.
Backing is provable; identity is not. Assurance is graded A1–A4, and only a commitment is public. A verifier gets a threshold proof — "grade ≥ A3, yes" — without ever learning the exact grade, let alone the person. The presentation is a selective-disclosure zero-knowledge proof: it answers the predicate the counterparty actually needs and reveals nothing else.
An operator's agents are unlinkable. Nothing in a presentation ties two of your agents together. A counterparty cannot quietly correlate your fleet, because there is no shared handle to correlate on.
The one thread back to the person lives in escrow, openable only under due process.
Accountability has to be payable, not just provable
I learned this watching how disputes actually resolve: a wronged counterparty does not want a name months after a cross-border lawsuit. They want their money back, fast. Accountability that is provable but not payable does not unlock anything high-value.
So in bitid an agent can carry funded recourse — proof that a real, bounded amount of money stands behind it, provable as a band ("at least this much is recoverable") without exposing the exact figure or the account. That turns accountability into a ladder instead of a single cliff:
- Money settles it first. Most disputes are paid out of the posted recourse under a published process. The principal is debited, and no identity is revealed to anyone.
- Then, a minimal fraud signal. If an independent arbiter finds genuine fraud, a small machine-readable flag is shared — enough to act on, never a name or a document.
- Identity is the last resort. Only serious harm or lawful compulsion unmasks the human, decided by an arbiter under due process and released by the issuer. Never bought with a payment.
Funded accountability ends up more protective of the person, not less, because it resolves the ordinary cases with money instead of with a name.
No one owns the root — that was the non-negotiable
The easy money in this idea is a centralized agent-identity service you rent from one vendor. For an open, cross-organization agent economy that is a non-starter, and I said so plainly in the series. A counterparty on another company's stack has to verify a proof without phoning the issuer's private API and without trusting one corporation not to rent-extract, censor, or get breached.
So bitid is its own sovereign, permissionless proof-of-stake Layer-1 — its own token, validator set, consensus rules and governance from launch, built on Cosmos SDK and CometBFT rather than reinventing consensus. The neutral root buys the two things the OpenID Foundation's survey flagged as unsolved: fast global revocation — a signed status root republished every 30 seconds, with immediate emergency roots, so a killed credential stops verifying within seconds everywhere — and a per-agent kill-switch, so one compromised agent drops without taking down the principal or its siblings. A holder can even revoke their own credential without the issuer.
The property that makes it scale is almost boring, and it is the one that matters most: an agent is just another credential holder. There is no per-agent record in a central registry to enumerate, breach, or bloat. The chain holds a handful of issuer status roots; the agents live off to the side, proven against those roots, never enrolled in them. State grows with issuers and verifiers — never with the number of holders. That is what lets the design stretch to a population of agents larger than the human one, which is exactly the world the standards bodies are bracing for.
The language boundary is the security boundary
One decision I would want a fellow engineer to know about, because it is not in the marketing copy: in bitid, the language boundary is the security boundary. Consensus-visible logic is Go. The anonymous-credential and zero-knowledge proof core is Rust. Simulation and load-testing is Python — and Python never touches a consensus path or production crypto. No network, clock, randomness or FFI ever runs inside block execution. Determinism is not a hope you audit for later; it is enforced by where the code is allowed to live. That is the kind of decision you make after watching a nondeterministic dependency take a cluster down at three in the morning.
Where I am being careful
Let me flag the limits, the same way I did in the series. Custody of other people's money means a licensed, bonded custodian, segregated accounts, anti-money-laundering checks, and an honest treatment of reversibility — funds posted by an everyday payment instrument can be clawed back for months, so the recourse they back cannot be treated as final on day one. Any low-friction way to onboard a human fast is, by definition, low-assurance, and has to be graded as low-assurance, not dressed up as more. None of that is a reason it cannot be built. It is the reason it has to be built carefully, with the legal framework alongside the protocol and not trailing it. That is why the spec is frozen before the chain is finished, and not the other way round.
What I'd do this quarter if you're shipping agents
- Stop reusing the human's tokens. If your agent acts with your OAuth session, downstream services cannot tell you apart from it. Give each agent its own credential now, even a crude one.
- Separate "who is behind it" from "what it may do." Identity and scope are different questions; bind the scope into the credential so an agent cannot quietly grant itself more power. I wrote the companion piece on bounding what an agent is allowed to do.
- Design revocation before you need it. Assume one agent will be compromised. Can you kill it in seconds without taking down the rest? If not, that is the first thing to fix.
- Watch the standards, not the vendors. A2A, MCP, OpenID4VCI/VP, AP2 — the rails are being laid right now. bitid is built to ride them, not replace them, and you should hold anyone in this space to the same test.
The through-line
The whole thing reduces to one line I have been circling since the first post: the agent is autonomous, but the accountability cannot be. Behind every fleet there is a real, liable human — and the entire game is proving that fact to whoever needs it while exposing the person to no one. Verify the human once. Let the accountability travel into everything they deploy. Keep the one thread back to their identity locked behind due process, where a breach cannot reach it and a marketer cannot buy it.
I said I would show you what that looked like when it stopped being a sketch. It is called bitid, the spec is frozen, and it is at bitid.net. Go read it, tell me where I am wrong — and if you are wrestling with agent identity inside your own systems, come talk to a CTO who is building it.
