How operator KYC works for AI agents (and why it isn't KYC-as-a-service)

Solidus Agents does not perform KYC. It links to a KYC credential issued somewhere else, by verify.solidus.network, and that link, not a KYC check of its own, is what this page explains.

Who the "operator" is

An agent isn't a legal person. Something registers it, holds the keys behind it, and answers for what it does, a company, a developer, a platform. Solidus Agents calls that party the operator, and it's a KYC'd entity, not a wallet. Don't read "operator" as wallet-UX language: it has nothing to do with custody or transaction signing (that's wallet.solidus.network's territory). It's an accountability concept: the answer to "who's behind this agent, and can that answer be checked."

The actual mechanism

An operator proves who they are once, to verify.solidus.network, the KYC check itself, including the document capture and liveness work, happens entirely there. What comes back is a verifiable credential attesting that this operator passed KYC. That credential is what crosses into Solidus Agents.

The API call is deliberately narrow: issueCredential() POSTs to /v1/agents/:id/credentials, attaching the operator's existing KYC credential to one agent record. Register a second agent under the same operator, and the same credential attaches again, unchanged, not re-verified, not re-issued. One KYC check, N agent registrations. This is descriptive of the shipped architecture, not a public demo a stranger can run without an operator account; the closest thing to a runnable, public proof on this product is the passport lookup covered on the verify-the-agent-passport page.

Worth restating plainly, because it's the one place this page could slip: Solidus Agents ingests that credential. It stores the link, it does not run the underlying identity verification, and it never issues a KYC credential of its own. The check, the document handling, the liveness work, all of it stays at verify.solidus.network. If you want to see how that side actually works, that's verify's flow to describe, not this page's.

What a relying party actually gets

The value of the link shows up on the other side. A relying party, a marketplace deciding whether to let an agent transact, a platform deciding whether to trust an agent's actions, can check "is there an accountable, KYC'd operator behind this agent" by resolving the credential attached to the agent's record, instead of re-running an identity check on every single agent that same operator spins up. That's the whole mechanism: a per-agent lookup against a per-operator verification, so the cost of accountability doesn't scale with how many agents one operator registers.

This is the same shape as Credential Portability, verify once, reuse the result everywhere a relying party would otherwise ask again, just applied at agent-registration scale rather than across independent human-facing services. It's a genuine, small instance of that idea, not a rebranding of it.

Whether a relying party should actually trust the issuer behind that credential, whether verify.solidus.network itself is on a list of issuers this particular relying party accepts, is a separate question, one that a Trust Registry answers. Solidus Agents doesn't decide that either; it's out of scope here, same as the KYC check itself.

What this isn't

None of this makes Solidus Agents a KYC vendor. There's no KYC-as-a-service product here, no identity-verification pricing, nothing to compare against an IDV vendor's feature list: that comparison belongs to verify.solidus.network, which actually performs the checks referenced in KYC and IDV. This page only describes the linkage step: how one already-issued credential attaches to many agent registrations, and how a relying party reads that link back out.

The honest baseline