"KYC for AI agents" is a phrase that falls apart the moment you take it literally. There is no document to photograph, no face to match against it, no jurisdiction of residence. An agent is a process. It has no identity to know — it has a principal, and the principal is a person or a company. Everything useful in this area follows from getting that distinction right: you do not verify the agent, you verify the human it is acting for, and then you let the agent carry the evidence.
Which raises the question every vendor accepting agent traffic eventually has to answer: how much evidence? A verified email and a passport scan are not the same ask, and requiring the second one for a free read-only endpoint is a good way to have no users at all.
The ladder
Identity assurance is not a boolean. In Notlogin's model a human accumulates proofs over time, each answering a narrow question at a very different price in friction:
- Email — a reachable mailbox that someone controls. It proves almost nothing about who, and quite a lot about recourse: there is somewhere to send a notice, and a burner costs the attacker thirty seconds.
- Google — a federated account, which mostly means a mailbox with an established history and an account-takeover story somebody else is paid to worry about. Slightly harder to manufacture at scale than a fresh address.
- SMS — a phone number. The first rung with a real unit cost to the abuser: numbers are rate-limited by carriers, cost money in bulk, and burn when reported. This is the classic anti-Sybil rung, and it is the one most vendors should be asking for.
- Wallet — control of an on-chain address, demonstrated by signature. Not a human check at all; it is a solvency and continuity check. An address with history is expensive to fake and trivially checkable, which is why it pairs naturally with payments and budgets.
- KYC — a government ID plus liveness, run through a regulated verification provider, with AML screening attached. This is the only rung that yields a legally meaningful identity, and it is also the only one that costs real money per check and loses you a meaningful share of signups.
They are not strictly ordered — a wallet proof is not "stronger" than SMS, it is orthogonal — but they do form a rough cost curve, and the vendor's job is to sit at the cheapest point on that curve that still bounds the abuse they actually fear.
What the vendor learns, and what it does not
Here is the part that surprises people coming from conventional KYC. When an agent presents a credential, the signed payload carries the list of proof types the human passed — ["email", "sms", "kyc"] — alongside an opaque user id and a short pseudonymous handle. It does not carry a name. It does not carry a date of birth, a document number, an address or a selfie.
The vendor learns the assurance level. It does not learn the person. That is not a limitation that had to be worked around; it is the entire value proposition of putting a broker in the middle. A search API gating its write tier behind "this principal completed KYC" has every bit of signal it needs, and has taken on exactly none of the custody, retention and breach liability that comes with holding identity documents. The documents stay with the verification provider who is regulated to hold them.
One consequence worth internalising: the proof list is a snapshot taken at issuance time, signed into the payload alongside the scope and expiry. A human who completes KYC on Tuesday does not retroactively upgrade the credentials they issued on Monday — those are already signed and immutable. They re-issue. This is correct behaviour (a signature that could change meaning after the fact is not a signature), but it does mean an agent that suddenly starts getting refused may simply be holding a stale certificate, not a revoked one.
Declaring a requirement as a vendor
A registered vendor declares its requirement as a list — requiredProofs — and the SDK enforces it at the point of signup. An empty list accepts any valid credential. The default is ["email"]. A payments-adjacent vendor might publish ["email", "wallet", "kyc"].
The detail that makes this workable for agents is the shape of the refusal. A credential that falls short is not met with an opaque 403; the response names the missing proofs. An agent can read "you need sms", report that to its human, and retry after the human clears it — the same machine-readable loop that lets an agent sign up without a form in the first place. Compare to the human web, where the equivalent is a support ticket.
Choosing your rung
A decision rule that survives contact with reality: require the proof that raises the attacker's cost above the value of what they would steal, and nothing beyond it. Concretely —
- Free, read-only, rate-limited. Require nothing, or email. The abuse ceiling is your rate limiter, and a credential of any kind already tells you more than an anonymous API key does.
- Writes, or anything that emits. Sending mail, posting content, creating public records: require SMS. The failure mode here is Sybil spam, and a per-number cost is the cheapest thing that bites.
- Money moves, or an on-chain payout exists. Require wallet, and cap it with a budget rather than an identity check. Identity does not stop overspending; a ceiling does.
- You have a statutory obligation. Regulated financial services, age-gated goods, AML-covered activity, anything where a regulator will eventually ask who your customer was: require KYC, because nothing lower is an answer to that question. Do not require it anywhere else. Each rung is a tollgate on your own funnel.
The reason this is worth doing once, centrally
The compounding argument is on the human's side of the table. In the world where every vendor runs its own KYC, a person who wants their agent to use twelve services uploads a passport twelve times, waits twelve times, and creates twelve separate copies of their identity documents sitting in twelve breach surfaces of wildly varying quality. In the brokered world they verify once and the resulting proof rides in every credential they ever issue — which is the same argument as the broker argument generally, applied to the most expensive step in onboarding.
For the vendor, the arithmetic is nicer still: you get the assurance signal for the cost of reading a field, and you never pay a verification provider, never build a document pipeline, never write a retention policy.
What a proof does not buy you
KYC verifies a person. It does not verify that the person is watching. An agent operated by a fully verified human can still be steered by a prompt injection into doing something the human never intended, and a verified identity behind a hostile request does not make the request less hostile — it just makes it attributable afterwards.
Which is why assurance is one axis of three, and the weakest of them on its own. Scope decides what the agent may touch. Budget decides how much it can cost. Expiry and revocation decide how long a mistake lasts. Identity assurance only decides how much you trust the party standing behind all of that. A vendor requiring KYC but issuing unbounded, non-expiring access has verified precisely who will be filing the incident report.
If you operate agents, clear the proofs once and stop re-onboarding for every service — start here. If you run a service and want agent traffic you can actually reason about, register as a vendor, declare the rung you need, and let the SDK turn it into a one-line check. And if you are still weighing the format itself against API keys and OAuth, the comparison is here.