How Agent Onboarding Works, and Why It Is Not Know Your Agent Yet

The flow, as it actually runs

An operator record is created, and it gets its own tenant.

A verification credential reference is attached to it, together with an assurance level. The reference points at something verify.solidus.network issued. This surface ingests that reference and never runs an identity check itself.

An agent is created, either with a key we generate or with one you already hold, and an identifier is written to our chain.

A passport is minted by our relayer in the public registry, and transferred to the operator's recorded address when there is one.

An owner-binding credential is issued, and the public card at the passport's URI lists it.

That is the whole flow, and it works. What follows is what it does and does not establish.

One: the gate checks that a reference exists

Creating an agent requires the operator to have a reference attached. With no reference, the request is refused and the error tells you where to get one.

Whether verify actually confirmed that reference is, by default, recorded rather than required. The service can run in three postures: not checking, checking and recording the answer, or checking and refusing. The default is the middle one.

So an operator whose reference was never confirmed can still register an agent today. That is a deliberate, documented choice with a stated reason, and it is still the first reason this is not knowing your agent.

Two: the assurance level is supplied by the party it describes

The owner-binding credential we sign carries three claims: the agent's identifier, the operator's identifier, and an operator assurance level.

That level is a free-text string, between one and sixty-four characters, taken from the request body. It is never read from verify's answer.

When none is supplied, the credential says unknown. That default is honest and worth saying so, because the tempting default was a flattering one.

But a supplied string is signed as given. A credential asserting an assurance level chosen by its own subject is a record of what somebody typed, authenticated by us.

Three: the credential carries no field for the verdict

The database has a column for verify's answer, with three states: confirmed, rejected, or never checked.

None of the three reaches the credential. The claim schema has no field for it.

CONTROL that makes this a decision rather than an oversight of inputs: the value exists and is stored, so a field carrying it would have had somewhere to come from.

Consequence for a relying party: the artefact tells you an operator attached a reference and named a level. It does not tell you whether the issuer of that reference stands behind it.

And one shipped screen says more than the credential does

At the point of issuance, the interface says the credential proves the operator behind the agent is verified.

Both strings shipped. The second is accurate. The first is on the screen where somebody decides to issue, which is the worse place for the stronger claim, and it has been filed rather than written around here.

What this flow gets right, at the same volume

Two different failures get two different messages. No reference at all and a reference verify did not confirm are separate errors with separate fixes, which is a deliberate distinction most systems collapse.

Reference validation exists at all, added in July 2026. Before that, any string passed.

The honest default and the honest terms page, as above.

And the separation of duties is real. Identity checking happens on another surface, this one ingests the result, and nothing here re-runs or re-decides an identity check. That boundary is the part of "know your agent" we do hold.

What would actually make it know your agent

1. The refusing posture switched on, which needs a network that does not reset nightly.
2. The verdict carried inside the credential rather than beside it.
3. The assurance level sourced from the issuer instead of the subject.
4. A relying party that checks. Zero unaffiliated relying parties have accepted a credential we issued, so today the chain of custody is a chain nobody has pulled on.