Working in teams

murk’s vault is per-recipient: every teammate has their own key, and adding or removing someone is a normal git-tracked change to the vault file: no shared password to rotate, no separate secrets server to run.

Adding a teammate

Each person generates their own keypair first:

# Alice sets up the vault
murk init
murk add DATABASE_URL

# Bob generates his own key
murk init

Then an existing recipient authorizes Bob’s public key:

murk circle authorize age1bob... --name bob@example.com

Once Bob is authorized, the vault is re-encrypted to include his key, and he can decrypt everything in the shared layer:

murk export

Bob can still keep his own local overrides on top of the shared secrets. See shared vs scoped secrets:

murk add DATABASE_URL --group me

Authorizing via GitHub

Manual key exchange works, but the easier path for most teams is authorizing by GitHub username:

murk circle authorize github:bob

This fetches Bob’s SSH public keys from https://github.com/bob.keys (no authentication required) and adds them as recipients: no pasting an age public key over Slack. ssh-ed25519 keys are accepted by default; ssh-rsa keys need --allow-ssh-rsa because ed25519 is recommended.

Recipient pinning

The first successful murk circle authorize github:bob records the SHA-256 fingerprints of the fetched keys in the encrypted vault metadata. If Bob’s GitHub keys change later, the next authorize github:bob refuses to proceed silently: it flags the diff and requires --force to accept the new keys. This catches both benign key rotation and a compromised GitHub account adding an attacker’s key, and turns either into something a human has to actively confirm rather than something that happens invisibly.

Because this pinning trusts GitHub as a key directory and trusts that the username belongs to who you think it does, treat authorize github:user with the same care you’d give any access grant: verify identity out of band for sensitive vaults. See the threat model for the full trust analysis.

Listing and managing recipients

murk circle           # list recipients
murk circle revoke RECIPIENT   # remove a recipient (see offboarding)

For encrypting a secret to only a subset of the team (not the whole recipient list), use named groups: murk group create|ls|add|rm NAME. See the CLI reference for the full flag surface.

When someone leaves the team, don’t just stop there. See offboarding a teammate for revocation and rotation.