Backed by: @pithy-sh/secrets. Scopes: secrets:status:read · secrets:rotate.
What it shows
Metadata only, permanently — the master key never leaves your Worker. Rotation is the ordering behind the button, rotating a secret is the walkthrough, and roles and permissions is who may press it.
Every declared secret’s status — when it was last rotated, how often it should be, and whether it is overdue. One secret’s rotation history.
Metadata only, and structurally so
A failed rotation reports as a status, never as a message. An error message is free text written at a failure site, which is exactly where a value gets pasted by accident.
Two scopes, and the split is not tidiness
secrets:status:read is its own grant because the list of which credentials a project holds, which are stale, and which no automation will ever rotate is a map of where to push.
You must be able to grant a users pane without also granting that.
secrets:rotate is separate again, and folding it would have been an escalation with a name that hid it: matching is exact, so a rotation behind the status scope would have handed credential replacement to everybody who ever wanted a status pane — retroactively, and without being asked.
It never enters a default grant either, because default grants classify by route method and every route requiring it is a POST.
Rotating from here
The write is a rotation and nothing else, and that is what makes it possible.
Create and update cannot exist here: a management client holds neither your registry nor your Zod schemas, so it could not write a value against the schema that governs it.
A rotation supplies nothing — the successor is produced inside your Worker, minted from the entry’s own recipe or returned by its rotator — so no value crosses in either direction.
A Worker rotates less than the CLI does, and says so
It holds one environment’s database and its own master key.
Refused, before anything is called:
| Why | |
|---|---|
| A Secrets Store secret | An account-level entry written with a token an app Worker must never hold |
A global secret | Identical in every environment by definition — writing one would strand the rest under one name |
| A name this environment has never stored | Discovering that after a provider roll would manufacture an unrecoverable incident |
Each answers secrets/rotation_unsupported naming pithy secrets rotate.
The one outcome to act on immediately
unrecorded — rolled at the issuer, successor never stored.
It is critical, and it means somebody must go to a console now. failed means the old value is still live and the command can simply be run again.
Every rotation, successful or not, is audited with the operator, the secret, the environments and the outcome.