Security Model

Key Man Out encrypts secret text and attachment contents in your browser using age. Each user has a personal X25519 identity. Your unlock passphrase protects that identity; it is never shared with your team or sent to the server.

What the server can see

The server stores public keys, passphrase-wrapped private identities, and encrypted payloads. It also stores unencrypted metadata: asset names, websites, instructions, attachment names/types/sizes, team settings, guardian assignments, access requests, and recipient fingerprints. Team members can browse asset metadata while their identity is locked. Keep passwords, recovery codes, and confidential instructions in the Secret field or an attachment.

The server never receives raw private identities, unlock passphrases, or decrypted secret/file contents. This protection assumes a trustworthy browser and client application. It does not make metadata private or protect an unlocked device from malware.

Your personal identity

On your first visit to a team, enrollment generates an age identity in your browser. Choose a unique unlock passphrase of at least 12 characters. The browser wraps the private identity with age's scrypt passphrase encryption and uploads only the wrapped identity and public key.

Unlocking downloads the wrapped identity, decrypts it locally, and checks that its derived public key matches the stored public key. No hash or other passphrase proof is sent to the server. Account login and identity unlock are separate: resetting a login password does not recover an identity.

Enrollment offers a raw identity backup compatible with the age CLI. That file can decrypt ciphertext addressed to your identity without your unlock passphrase. Protect it as carefully as the secrets themselves. Losing both the passphrase and backup prevents you from decrypting with that identity; another enrolled recipient may still have access to the affected assets. The service cannot recover your private identity.

Login passkeys authenticate your account. Passkey-based vault identities are not part of this release.

Locking and plaintext lifetime

Unlocking lasts up to 30 minutes from unlock, with a countdown button for locking sooner. The raw identity is kept in user-bound browser session storage. Locking, expiration, logout, or switching accounts clears the unlocked identity and displayed plaintext. Locking applies to your identity across teams in that browser session; it does not lock other users out.

The asset list remains visible while locked. Secret viewing, decryption, and encrypted edits require unlock. Secret drafts are not auto-saved to local storage, and old persisted secret drafts are purged. Unsaved secret edits can be lost when the identity locks. Downloaded files and clipboard copies are outside the application's ability to erase.

Who receives encrypted content

Each secret and attachment is encrypted to the asset's Custodian and every enrolled Successor, plus the team owner's identity when owner escrow is enabled. Gatekeepers and ordinary team members are not recipients by virtue of those roles. Current team membership is required.

Successors are cryptographic recipients before approval so that time-delay access can work while the Custodian is unavailable. The server still checks the existing access-request approval policy before returning ciphertext. That is a server-side gate, not cryptographic withholding: a Successor who obtains a ciphertext copy addressed to them can decrypt it offline before approval. Gatekeepers without an independent recipient entitlement cannot decrypt even if they obtain that copy.

Normal list, detail, and discovery responses contain metadata only. Secret and attachment ciphertext is returned through the gated payload-read route, which keeps the existing access notification behavior. Re-encryption, rotation, and migration reads use the same gate.

Owner escrow

Owner escrow is off by default. Enabling it adds the team owner's public key to each asset's expected recipients. Escrow does not bypass the server's payload-access policy: the app never delivers escrowed ciphertext to an owner who lacks a Custodian role or an approved Successor request, so escrow alone does not let the owner view an asset in Key Man Out. It is an out-of-band recovery measure. After re-encryption, a ciphertext copy obtained outside the app, such as from a data backup, can be decrypted with the owner's identity backup and the age CLI. Consider that before enabling it.

Changing escrow flags existing encrypted assets for re-encryption; it does not immediately rewrite them. Disabling escrow removes the owner from future recipient sets after re-encryption. It cannot revoke an old ciphertext copy or plaintext the owner already obtained.

Guardian changes and re-encryption

Adding or removing a Successor changes the expected recipients. The Custodian's unlocked browser attempts to re-encrypt the complete secret and attachments after the guardian change. Gatekeeper changes do not change recipients.

If a recipient has not enrolled, available enrolled recipients can still receive the payload, provided at least one exists. The asset remains marked Needs re-encryption. The same warning appears when a guardian removal or escrow change leaves the stored recipient set out of date. An unlocked Custodian or approved Successor who can decrypt can repair it. Another Successor approving removal without payload access leaves the warning for an eligible user to resolve.

Re-encryption checks both the payload version and current recipient set. A concurrent edit requires refreshing and trying again. It preserves the secret's presence and all attachment metadata/count; it cannot silently drop content. Removing a recipient affects future ciphertext, not copies already downloaded.

Personal identity rotation

Personal rotation is available from Account Security. It replaces your identity across all affected teams. The browser unlocks your old identity, generates and wraps a new one, then stages complete re-encrypted payloads one asset at a time. The pending wrapped identity is stored before staging so it is not lost if the browser closes.

Activation is all or nothing. The server rechecks the complete affected asset set, membership, access gates, recipient sets, and payload versions in one transaction. Only then does it replace all payloads, activate the new identity, and revoke the old one. Until commit, the old identity and live payloads remain active.

Inaccessible, legacy, or undecryptable assets block rotation; they are never silently skipped. Stale references from former teams can conservatively block rotation without revealing former-team metadata. Resolve access or migration first. A changed asset or recipient set requires a fresh staging attempt. Pending rotations expire after 24 hours and can be canceled before commit. The retired team-wide approval workflow and cooldown no longer apply.

Migrating a legacy team

Team owners see a migration action in Team Settings while legacy state remains. The legacy phrase is entered only in the browser, where existing AES-GCM content is decrypted and re-encrypted with age.

Ownership does not grant permission to read every asset. Migration discovery is metadata-only; every payload read uses the same guardian access gate and notifications as ordinary viewing. Blocked assets are reported without returning ciphertext. Eligible Custodians or approved Successors can migrate individual assets, after which the owner can finalize the team migration.

Original bytes stay intact until each complete replacement commits. Missing enrolled recipients leave assets flagged for later re-encryption; zero-recipient encryption is rejected. Owner-only finalization succeeds only after no legacy secret or attachment remains, then clears the legacy hash/reminder columns. Those columns are transitional migration markers, never authorization proofs. A team with blocked or undecryptable assets cannot be declared migrated.

File and request limits

Attachments use the same recipient set and gate as secret text, including assets that contain attachments only. Each file is limited to 10 MiB, each asset to 20 attachments, and each encrypted payload request to 64 MiB. File content is stored as inline armored ciphertext; names, sizes, and MIME types remain visible metadata.

Security boundaries

Strong passphrases reduce offline guessing attacks against stolen wrapped identities. Encryption does not prevent a compromised client from capturing typed passphrases, unlocked private identities, or plaintext. A compromised service that can change delivered application code is also outside the passive database-disclosure guarantee.

The server supplies the recipient public keys your browser encrypts to, and the browser does not pin or independently verify them. An attacker who controls the server or database could substitute or add a public key so that content encrypted afterwards is also readable by them. Existing ciphertext is not exposed this way, because it cannot be re-encrypted without a recipient's private identity. The zero-knowledge guarantee therefore covers passive disclosure of stored data, not an active server compromise.

Approvals, notifications, and membership checks control service access, not offline copies. Rotation and recipient removal cannot erase old backups or revoke a secret already learned. If a stored password or token may have been exposed, change it at the issuing service as well.

See Guardian System, Access Requests, and Account Management for the corresponding workflows.