Invite a teammate

Inviting someone to a project makes them addressable. It gives them no access to anything. Access is granted per environment, afterwards, on purpose.

Send the invitation

You choose an email and a role — admin or member. (owner cannot be invited; there is exactly one, and it is whoever created the project.)

They get a link containing a single-use 256-bit token that expires in 7 days. You can revoke it any time before it’s used, and you can see every outstanding invitation in the project.

They accept, and publish a key

Accepting creates their account if they don’t have one, and publishes their public key to the project. At this point they appear on the roster as invited · pending.

Pending is a real state, not a cosmetic one: no environment key has been wrapped to them, so they can read nothing.

You confirm them

This is the second step, and it’s the one that matters. Before your client will wrap any environment key to their public key, the two of you compare a 20-character fingerprint out of band — over a call, in person, not in the chat thread you are already using.

Only after that does confirmation flip them to active, and only then can you grant environments.

The fingerprint ceremony explains why this cannot be skipped, and why the server cannot do it for you.

Then grant what they need

Confirmation is not access. A confirmed member still has no access to every environment until you grant it — see grants.

That ordering is the whole point of the two-level model: someone can be a fully-confirmed admin of a project and still be unable to read production.

Why two steps

One step would be simpler, and one step is what almost every tool does. It also means that at the moment a key is handed out, the only thing vouching for the recipient’s identity is the server — and a compromised server can substitute its own public key at exactly that moment and receive an environment key it can open.

That is the one gap zero-knowledge does not close by itself, because the server has to be in the loop to route the key, and it cannot verify what it is routing.

So there are two steps, and a human check between them. The friction is the feature.

Removing someone

Removing a member drops their grants and shows you which environments they had access to, along with a recommendation to rotate.

Take the recommendation. Removing access stops the next read; it cannot un-know what they already read. See rotation.