Skip to main content
Everything in Keychain hinges on who can authorize an agent. The Lit action releases a secret only when it sees a receipt that traces back to your credential, and Keychain’s servers never hold a key that can produce one. That is why sign-in is a wallet, a passkey or a Google account verified inside the enclave rather than a password the server checks.

​
The three methods

Your browser first generates a fresh Ed25519 session key that lives only in memory and expires after ten minutes. A hash of that public key and a random value is passed to Google as the OpenID nonce, so the ID token Google returns is bound to this specific session key.When you approve something, your browser signs that exact object with the session key and sends the signature together with the Google ID token to an immutable Lit Action running inside a hardware enclave. The action fetches Google’s public keys, verifies the token’s signature, issuer, audience, subject, expiry and nonce, and only then signs a durable receipt for that object. Keychain stores the receipt. It never stores your Google token, and the token cannot mint new receipts after it expires.Your identity is Google’s stable subject ID for your account, not your email address. Sign in with the same Google account, not merely the same email spelling on a different account.

​
The tradeoff

Google avoids managing a signing key yourself, has no device dependency, and offers account recovery through Google. The cost is that your Google account becomes the root of trust for your vault. Anyone who takes over that account, and Google itself, can obtain a token for your subject and authorize new agents. That is the same trust every “Sign in with Google” button implies, but here it gates your secrets. Wallet and passkey are self-custody. Every approval needs a signature from hardware or a device only you hold. Keychain, Google and Lit cannot produce one. The cost is that losing the key means losing access unless you have approved a second owner credential.
Start with whichever is convenient, then open Recovery & backups and add a passkey or wallet as a second approved owner credential before storing anything valuable.

​
Prepare recovery while you still have access

  1. Sign in and open Recovery & backups. Approve an additional owner credential you control and test it before relying on it.
  2. Download an encrypted backup and store it privately off-device. It contains current ciphertext and signed policies, not private keys or historical versions. Download a fresh copy after every credential change and secret rotation.
  3. For connected services, retain the original provider credentials independently. Those actions cannot export or migrate a key.

​
Restoring

Restore never overwrites an existing secret or an existing vault’s credential settings. On a conflict, compare versions rather than deleting current data to force an old restore.

​
Rotations and what they affect

Cancelling a subscription is not revocation. For suspected exposure, revoke at the upstream provider too.