Keys
Master vs. app tiers, the apps scope subset, and why a key can't revoke itself.
Keys
Every shb_… key has a tier: master or app.
Master keys
Full authority over the account — every service, every project a grant
or the master itself can reach, plus minting and revoking other keys.
login's device flow and the dashboard's account-page "Create key"
button both mint master keys; there's no other way to get one, and a
master can never mint another master — the escalation ceiling is
enforced server-side, not just by convention.
App keys
Scoped to a non-empty subset of four apps values — page (sherpage),
serve (sherserve), link (sherlink), base (sherbase). Mint one with
key_create_app({ name, apps, project }); the plaintext is returned
exactly once, in that response.
Calling a tool outside an app key's apps list fails
403 insufficient_scope — never 401, which stays reserved for a
missing or revoked key entirely. An app key also can't call
key-management or OAuth-client tools (key_list, key_create_app,
key_revoke, oauth_*) regardless of its apps — those are
master-only by tier, not by scope.
A key can't revoke itself
If a key is the one authenticating the current call, it can't be the target of that same call's revocation — revoke it from a different key (usually the master that minted it) or from the dashboard's account page.
Grants are per project
A key's apps list is fixed at mint time, but which projects it can
reach beyond its own home project changes over time, via
project_grant_key/project_revoke_grant — see
projects and scoping.
Next
Public ids and urls — what a key's work actually gets served at.