Present and denying by default

You want a dashboard. Something that shows your users, grants a refund, retries a failed email, revokes an entitlement.

The normal way to get one is to send your data to a service that renders it. Which means your production data now lives in two places, and one of them is not yours.

The control plane is the other approach: a management client reaches into your Worker, and nothing is copied out.

Denying by default, with no backdoor

It ships inside @pithy-sh/core, so it is already installed. Composing it turns it on. But turning it on does not open anything:

With no connection registered, every route answers 403.

There is no default credential, no bootstrap token, no admin password in an environment variable. The absence of a granted connection is not a gap you might forget to close — it is the closed state, and it is where you start.

Connecting a client is a separate, deliberate act:

pithy dashboard connect --env prod

That grants exactly the operations you name, in exactly the environment you name. A staging credential can never touch production, because it was issued for staging and nothing about it generalizes.

The credential is asymmetric

This is the part that changes what a breach means.

The client holds a private key. You hold the public one, and you can revoke it.

Nothing secret of yours ever leaves your infrastructure. If the management client is compromised — including if the client is our dashboard and we are the ones compromised — the attacker has their private key. They do not have anything of yours, because you never gave them anything of yours.

A breach on their side is not a breach on yours. That property is worth more than any amount of assurance about how carefully somebody else stores your secrets, because it does not depend on them being careful.

Rotation cannot lock you out

Key rotation is where credential systems usually fail, and the failure is always the same shape: you replace the old key with a new one, something goes wrong in the middle, and now nobody can get in.

Here rotation is append, prove, then expire — never replace.

1. Append the new key. Both keys are now valid.
2. Prove the new key works, by using it.
3. Expire the old one.

A rotation that fails at any step leaves the old key working. The worst outcome is that you still have the credential you started with, which is not an outage.

Revocation is the opposite and deliberately so: a row you delete. Immediate, unilateral, and requiring nothing from the client. You do not ask them to stop using it. It stops working.

Every call, individually

A granted connection is not a session. Each call carries a token that is:

• Signed and short-lived — sixty seconds.
• Single-scope — good for one operation, not for everything the connection may do.
• Bound to a digest of its own body — so an intercepted token cannot be replayed against different content.
• Checked for replay, so it cannot be used twice even inside its minute.

And every call lands in your audit trail under its own actor kind. That last detail matters more than it looks: what the dashboard did is answerable separately from what your users did. When you read the trail back, an admin action taken through a management client is visibly that, rather than blending into ordinary traffic.

Capabilities bring their own admin routes

The surface grows as you compose.

Payments contributes manual entitlement grant and revoke. Email contributes job read and retry. Support contributes its inbox.

Adding a capability adds its management surface with nothing to wire, and each route arrives already behind the same gate. You do not build an admin API; you compose capabilities and they bring theirs, denied by default until you grant the scope.

What it does not do

It does not render anything. The control plane is an interface; the dashboard is one client of it, and you can write another.

It does not give you a way in if you lose your keys. Denying by default means denying, and there is no recovery path that would not also be a backdoor.

And it does not make your Worker reachable from anywhere it was not already. This is a set of routes on your own deployment, behind a gate you control, in your own account.