How it works in AgenID
Each key has its own identifier, agenid:key:<ULID>. Its key document lists key_type, the base64url public key, role, controller, created_at, a status, and optional retired_at and revoked_at. In v1.1.1 the controller is the agent's identifier. Verifiers fetch it from the registry at https://www.agenid.com/v1/keys/<key-ulid> and, where the operator publishes one, from https://<operator_domain>/.well-known/agenid/keys.json.
Why it matters
Role is enforced at verification time, not just documented. A ManifestProof signed with an authority-role key is rejected even if the Ed25519 math validates, so an operator key can only produce DECLARED statements. That is the line between what an operator says and what an authority has checked; see declared, verified and authorized.
Keeping the private key off the registry also limits what a registry breach could do. Someone who took over AgenID's database would hold public keys and signed records, none of which lets them sign a new manifest for your agent.
What it does not mean
Holding the key proves control of the key, not honesty. No revocation flow is deployed today: the status values exist in the schema, and retired or revoked keys would stay resolvable so old signatures remain checkable, but nothing currently writes them. The key also signs identity claims only; it is not a credential for what the agent is allowed to do.