PassControl legal
What survives a restore.
Provider API keys cannot be recovered from a backup and are re-entered by hand after total project loss. This page says what else does and does not come back, so the answer is known before it matters.
Why this page exists
A recovery limit an operator discovers during an outage is a different product from one they read about beforehand. This is the second kind. Nothing here is a change of behaviour — it is a description of how PassControl already stores things, published so that it can be relied on.
What comes back
These are configuration, held in ordinary database rows, and restore with the database:
- Agents: names, status, and their passport public keys.
- What each agent may reach — scopes, policy rules and failover order.
- Budgets, in tokens and in currency.
- Your ownership declaration, and whether it was verified.
- Call history, signed receipts and admin audit rows.
Your passport private keys are not in that list and do not need to be: they are generated on your own machine and never sent to PassControl, so a restored agent still recognises the key you already hold.
What does not come back
| Item | Why | What to do |
|---|---|---|
| Provider API keys | They are encrypted in Supabase Vault with a root key the hosting project holds and never writes into a database dump. A dump therefore contains ciphertext that only the original project can read, and the reference to it restores as a pointer to nothing. | Re-enter one key per provider. Everything else about the credential — which agents used it, under what policy — is restored around it. |
| Control API keys and Direct Agent Keys | Only a hash of each key is stored, so that a stolen database does not yield working credentials. A hash cannot be turned back into a key. | Issue new ones and update whatever holds them. |
| Two-factor enrolment and recovery codes | Enrolment lives with the authentication provider, and recovery codes are stored only as verifiers. | Re-enrol two-factor authentication and generate fresh recovery codes. |
| Active sessions | Sessions are short-lived by design. | Sign in again. |
Why the provider keys are not in the backup
Making provider keys recoverable across projects means producing an artifact that contains every operator's plaintext provider keys. That file is precisely what PassControl exists to prevent, and holding it would make us custodian of credentials we otherwise never hold. The cost of the decision is minutes of re-entry after a rare failure; the cost of the alternative is every operator's provider account, in one file, forever. We took the first.
Whether a backup exists at all
That depends on the hosting plan behind a given deployment, and PassControl cannot see it. The dashboard says so rather than displaying a reassuring tick it cannot justify. If you run your own deployment, check your database provider's backup settings directly. If someone else runs it for you, ask them what their restore procedure is and when it was last tested.
Taking your own copy
Any operator can export their workspace configuration as JSON at any time, from Dashboard → Settings → Recovery, or with passcontrol export. It contains agents, scopes, policies, budgets, failover order and your ownership declaration, and it deliberately contains no secret values — no provider keys, no key hashes, no two-factor material, no private signing keys. It can be restored into a fresh instance with passcontrol import, which creates what is missing and never modifies an agent that already exists.
A restore goes into a fresh deployment, not alongside the workspace the file came from. A passport public key identifies exactly one agent per instance — that is how the gateway knows whose call it is holding — so importing a file back into the same instance refuses every agent whose passport is still registered there, and says so per agent rather than reporting them as already restored.