Architecture
Discovery service
Discovery is a separate service. When an agent runs that nobody registered, its observed identity has to go somewhere a human can review it. The last place you want an unapproved agent’s prompt is inside the component that holds your keys. Discovery is that somewhere: a staging channel that keeps content out of the trust root.
What it stores, and what it doesn’t
When the client runtime detects an agent whose checksum matches nothing registered, it pushes the content it observed (the system prompt, the tools, and the computed checksum) to discovery. That is all discovery holds: proposed identities awaiting review, keyed by checksum. It mints nothing, holds no keys, and makes no authorization decisions.
How the two halves rejoin
Meanwhile the same agent’s attempted mint reaches the Authority carrying only a reference: its id and checksum. The Authority denies it (fail-closed) and records a reference-only trigger. The console then joins the two: it reads the Authority’s triggers and fetches the matching content from discovery by checksum, renders a review card, and on Approve fires the real registration into the Authority. This is the one sanctioned path for content to cross into the trust root.
Note
▶Why a whole service for this
It would be simpler to just let the Authority record the prompt of any agent it sees. That simplicity is the property you don’t want: an agent’s system prompt is often its most sensitive asset, and the trust root should hold as little as it can. Splitting content (discovery) from references (Authority) means an unapproved agent can be made visible for review without being made present in the component that matters most.
Discovery is where visibility-without-trust lives. Approval, a human action, is the only thing that moves an identity from staging into the registered set. See Discovery & the trust boundary for the concept, and the Authority for what registration writes.