How it works in AgenID
The specification defines an authority registry document at /.well-known/agenid/authorities.json on agenid.com, listing each recognized authority's domain and authority key, signed by the root authority key. A verifier checks it over TLS and against the pinned root value; disagreement is trust_anchor_mismatch, a hard fail. That document is deliberately not published today, because a pin for a key that does not exist would be a false claim.
The pin would live in the specification repository precisely because that channel is separate from the registry, so a verifier can compare the two.
Why it matters
L2, L3 and L4 all require a VerificationAssertion signed by a root authority key; see verification levels. Without it, AgenID can show that an operator signed a declaration but not that anyone checked it. The creation ceremony is gated on hardening the agenid.com zone and the GitHub organization first, because an attacker controlling either could publish a different pin without touching the key. Custody in a hardware security module is planned.
What it does not mean
A root key would anchor verification, not permission: it would sign what was checked, never what an agent is allowed to do. v1.1.1 also has no delegation object, so the root would sign assertions directly; a v1.2 delegation design that narrows that exposure is a draft, not available.