shebang!

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.