Trust tiers, signing, and why your verified badge matters
How the three tiers work, what verification requires, and why agents downstream can refuse to run unsigned content.
The three tiers
Every entity in the Amitte registry carries one of three trust tiers:
- Unverified — the publisher hasn't proven domain ownership. Any GitHub-authenticated user can publish to this tier.
- Verified — the publisher has signed a claim with a key tied to a domain they control (DNS TXT record). The badge is a green check.
- Official — manually granted. The badge is gold. Reserved for the Amitte org and its partners.
The tier is a property of the publisher, not the entity — every entity from a verified publisher inherits the verified badge.
Why publishers care
Consumers' agents can refuse to run unsigned or unverified content. If you're shipping an agent that reads from the registry, your config might look like:
# .agentrc.yaml
trust_floor: verified
That single line means your agent will skip every unverified skill on the registry. The verified badge is what gets you past that filter.
What signing actually proves
Each verified version is signed via Sigstore keyless flow. The signature is bound to:
- The publisher's GitHub identity at the time of publish.
- The artifact contents (manifest + body).
- A transparency log entry in Rekor.
Anyone can verify the signature post-hoc with the amitte verify
CLI command. If you're consuming a verified skill, run
amitte verify <publisher>/<skill>@<version> before trusting it.
Getting verified
Verification takes about ten minutes and one DNS record. The flow
lives at /publish/verify-domain — paste your domain, the registry
gives you a TXT record to add, you wait for propagation, you click
verify. Done.
If you're publishing on behalf of an org you don't control the DNS
for, file a request at /admin/contact instead — we'll work out
attestation manually.
Why this matters more over time
Today most agents run with no trust posture; they'll happily execute anything. Once they start running actions on behalf of users with real consequences (deploys, payments, sending email), the trust tier becomes load-bearing. Worth setting up before you need it.