Revoking us

One command

The credential model is why it takes effect immediately and needs nothing from us. Disconnect and rotate and revoke are the narrower versions, and the zero-logging commitment is what remains true afterwards.

pithy dashboard disconnect --env prod

Or delete the registration row yourself. It is in your own database.

Immediate, unilateral, and requiring nothing from us.

pithy dashboard revoke-key --env prod --key-id <id>

Stamps that key revoked and leaves everything else in place.

Revocation is checked before any validity window, so it takes effect on the next request.

Expiry is the orderly end of a rotation and is refused when it would leave nothing live.

Revocation is the disorderly one — and an adopter holding a leaked key must never be told they have to keep trusting it.

The connection then denies every call, which is the correct state for a credential you no longer trust, and connect is the way back.

Your data is untouched. None of it was ever here.

Your Worker keeps running. The CLI keeps working. Every capability stays fully usable — the dashboard gates its own UI and nothing else.

The dashboard stops. Every call answers controlplane/not_connected, which is the shipped, denying default rather than an error state.

Our own users, our own subscriptions, and the connection metadata — project, environment, endpoint, credential reference.

Not a copy of anything of yours, because there was never one to keep.

Scopes are stored and enforced on your side, and matching is exact — no prefix rule, no wildcard.

So you can grant a users pane without granting secrets status, or grant reads and withhold every write, and re-register with a narrower set.

pithy dashboard connect --update re-points an existing connection when your address changes.

Query your own audit trail. A denied control-plane call is a first-class outcome and is recorded.

And an audit write that fails never turns a correct denial into a 500 — the denial is decided before it is recorded.