Admin-assisted recovery

If you lost your master password and your Recovery Kit, and you are on a team, your teammates can restore your access to shared environments only.

Read the scope before you start

This restores exactly what a grant-holding admin re-wraps to your new key. Anything you never shared with anyone is gone permanently — no admin holds a key for it, so there is nothing to re-wrap.

Solo projects, personal environments, that one experiment nobody else was added to: unrecoverable. See what is unrecoverable.

What happens, structurally

Unlike personal recovery, this deliberately replaces your key pair. You lost both factors, so there is no way to decrypt the old private key — a new pair is the only path.

That is why it needs other people: a new key pair means every environment key has to be wrapped to it again, by someone who holds those keys.

Your side

1. Request recovery. You verify your email with a one-time code, then your device generates a new key pair and a new credential from a new master password.
2. Read your new fingerprint to an admin. Your device shows it. This is a ceremony and it is mandatory.
3. Wait. Grant-holding admins re-wrap the environments they hold to your new key.
4. Check the count, then complete. Your client tells you how many environments have been staged and refuses to complete with zero staged unless you explicitly override — because completing early replaces your entire grant set with whatever is staged, and completing with nothing staged means you get nothing.
5. You’re back in, logged in but locked, with a new Recovery Kit to write down.

The fingerprint your device shows is always derived from the key pair it actually possesses — never from what the server served back. Fingerprinting a served key would launder a substituted key through the very check meant to catch it.

The admin’s side

1. See the request in the project.
2. Run the ceremony. Compare the requester’s new fingerprint out of band — a call, not a chat message.
3. Fulfil. Your client re-establishes each environment’s current key and wraps it to the newly verified key.

Bring more suspicion, not less

You may have verified this person’s key before. This is a different key, and a server-presented request to re-key an existing member is exactly the shape an attack would take.

The interface labels a replacement ceremony differently from a first contact for this reason. Verify it as carefully as the first time — more carefully.

What does not come back

• Anything never shared. No admin has a key for it.
• Payload history from before any rotation that happened while you were locked out.
• Environments where every grant-holder has left. If nobody remaining holds the key, nobody can re-wrap it.

Known rough edges

Two accepted limitations worth knowing before you start:

If an environment rotates between fulfilment and completion, the staged wrap is correctly stale and you will need an admin to re-fulfil. The system does not re-stamp a stale wrap as current, because doing so would mask a wrong key rather than surface it.

While recovery is in progress, normal grant operations toward you fail loudly with a key mismatch on other people’s devices. That is correct: any grant staged to your old key would die at completion anyway, so the alarm is refusing doomed work rather than malfunctioning.

Email is the root here

An actor controlling your email — plus an admin willing to fulfil — can drive a key-pair swap and a new login credential.

What that restores is no secret: every installed grant is a wrap that an admin deliberately staged to a key they verified out of band. The reach is account-shell control and denial of access.

The ceremony is the defence, and it is a human one. This is named plainly in the threat model, because email control is irreducible for any flow that recovers an account without either factor.