Rotate the team DEK on membership change (defense in depth, not offboarding)

[kipavy]

Split out of #72 so its rationale is recorded honestly rather than assumed.

Current behaviour

Removing a member deletes their row from team_vault_keys (server/src/routes/teams.rs:545-550) and revokes their session grants, and the client evicts the in-memory vault key (src/services/sync.ts:882-886). The team DEK itself is never rotated, and the team blob is never re-encrypted.

What rotation would and would not buy

It is tempting to treat rotation as the fix for offboarding. It isn't, because a departing member held the plaintext:

Exposure	Protected today?	Does rotation help?
Secrets they already read	No — permanently compromised	No. Only rotating the credentials themselves helps
Future team content	Yes — membership row, wrapped key row and session grants all deleted server-side	No, absent a server-authz bypass
Blob ciphertext they exfiltrated before leaving	They held the DEK, so they can decrypt it	No — a copy someone already holds cannot be retroactively re-encrypted
Plaintext left in their local keychain	No — see #216	No

Rotation protects only blobs written after rotation, which a removed member can no longer fetch anyway.

The case for doing it anyway

Defense in depth on the ciphertext at rest. Today a single DEK covers the entire lifetime of a team, so any leak of the encrypted blob — a database backup, a stale replica, a misconfigured storage bucket — exposes everything the team has ever stored, including data added long after a member left. Rotating on membership change bounds that blast radius to one membership epoch.

That is a real property, and it is worth stating as the reason. It is not an answer to "what happens to a removed member's access", which is #72's question.

Rough shape

• Generate a new team DEK, re-encrypt the team blob, re-wrap for every remaining member.
• Handle partial rotation: some members re-wrapped, some not, and the blob in one state or the other. This needs to be atomic or resumable — a half-rotated team where some members cannot decrypt is worse than no rotation.
• Handle offline members: someone who is not connected at rotation time must re-key on next connect without losing access in the meantime.
• Decide the trigger: automatic on every removal, or an explicit admin action. Automatic is safer but makes every removal a heavyweight operation.
• Decide what "rotate" does to older blob versions retained server-side, if any.

Related

• Team administration & offboarding — roles, pending-invite status, seats, leave/remove #72 — team administration & offboarding. Rotation was explicitly scoped out of that issue after this analysis, so Team administration & offboarding — roles, pending-invite status, seats, leave/remove #72 ships honest consequence copy instead: a departing member loses access to future changes, keeps whatever they already saw, and the credentials they used should be rotated.
• Team secrets survive removal in the departed member's OS keychain #216 — team secrets left in the departed member's OS keychain. Higher priority and unrelated to rotation.
• Design context: docs/superpowers/specs/2026-09-07-team-admin-offboarding-design.md

[kipavy]

Triage: the rationale above is measured against a schema we no longer run

Keeping this open, but the "case for doing it anyway" needs rewriting before anyone builds it, because the storage model it argues about was superseded.

One blob became two tables

This issue models a team as a single encrypted blob. That was migrations/007_team_vault_sync.sql. migrations/021_team_vault_objects.sql split team data in two:

• team_vault_secrets.ciphertext — connection passwords, private keys, passphrases. Encrypted under the team DEK.
• team_vault_objects.metadata — plaintext JSONB.

saveTeamVaultObject pushes the whole object as metadata: item (src/services/teamObjectPersistence.ts:19). For a connection that is host, port, username, auth_type, tags, jump_hosts, env_vars, pre_command, post_command and notes (src/stores/connectionStore.ts:81-118). Nothing strips it client-side (src/services/teamObjects.ts:97-104), and the server binds it straight into the column (server/src/routes/team_objects.rs:202, .bind(&body.metadata)).

Why that undercuts the argument for rotation

The stated reason to rotate is defense in depth on ciphertext at rest: bound what a leaked database backup, stale replica or misconfigured bucket exposes. But in such a leak the team's entire infrastructure inventory — every hostname, username, jump host, env var and pre/post command — is already readable without any key, and DEK rotation cannot change that. Rotation bounds the blast radius of the credential column only.

The missing row in the exposure table is the load-bearing one:

Exposure	Protected today?	Does rotation help?
Object metadata in a database leak — hosts, usernames, jump hosts, env vars, commands	No — plaintext at rest	No

That does not make rotation worthless. It makes it a second-order improvement that is currently described as a first-order one.

The "rough shape" section also targets the old model

"Re-encrypt the team blob" describes 007. Both paths are still live on the client — fetchTeamData reads blobPayload.secrets at src/services/teamVaultSync.ts:389, while _hydrateTeamObjectStores reads the per-object rows at :406. Any implementation therefore has to rotate two storage models, and has to handle a team that is mid-migration between them. That cost is not in the estimate above.

Proposed ordering

1. Team secrets survive removal in the departed member's OS keychain #216 first, unchanged. Plaintext team secrets left in a departed member's OS keychain, one-substitution fix.
2. Encrypt or strip team_vault_objects.metadata (filed separately). Same threat model as this issue, strictly more data covered, and a prerequisite: rotating a DEK that protects a minority of the sensitive fields is misleading defense in depth.
3. Then this issue, with the rationale narrowed to "bounds the credential column to one membership epoch" and the shape covering per-object secrets as well as the legacy blob.

Marking blocked on step 2.

[kipavy]

Server-side rotation live (server PR #17 merged + deployed, migration 41). Client fix merged to dev (#254) but not yet in a tagged release. Closing as fixed — will ship in the next Voltius release.