Sharing a key is a one-way operation

Sharing credentials with a teammate has an obvious method — send them the value — and the method has no undo. Once the string has been read, it is theirs, and removing them from the Slack channel changes nothing.

Teams work around this with shared password managers and shared notes, which is better, but those still hand out the value itself. The distinction that matters is between granting access and transferring a copy.

How it actually bites

1. Offboarding does not revoke anything

   A leaver’s accounts get disabled the same afternoon. The keys they used every day are still valid, because a key does not know who is holding it.

2. Shared vaults share too much

   A team vault is usually all-or-nothing per folder. A contractor who needs one provider ends up able to read the folder that contains all of them.

3. Nobody knows who has what

   After a year of ad-hoc sharing, the honest answer to "who can read the production Stripe key" is "we would have to ask around", which is not an answer that survives an audit or an incident.

4. Re-sharing is invisible

   The person you shared with can forward it. Nothing about the original share records or prevents that, and the second recipient never appears in any list.

What we do about it

1. Access to a project, not a copy of a string

   Sharing grants membership in an encrypted project. The plaintext never travels — what moves is a wrapped key only the recipient can unwrap.

2. Wrapped per recipient with ephemeral ECDH

   Each project has its own data-encryption key. For every member it is wrapped using an ephemeral ECDH P-256 exchange, HKDF-SHA-256, and AES key wrapping per RFC 3394. The server routes the wrapped blobs and can open none of them.

3. Removal rotates the key

   Revoking a member generates a new project key and re-wraps it for everyone who remains. Their stored copy no longer opens anything added afterwards — the removal is cryptographic, not a database flag.

4. Fingerprints you can check

   Each member has a public-key fingerprint, pinned on first use. If it changes, you are told, because a silently-changed key is what a server-side substitution attack looks like.