Invite & revoke members
Add teammates to the team brain by importing the public identity they exported, and remove them with a revocation that rotates the vault key and re-encrypts the store — not just a permission flag.
Only the Owner can add, remove, or re-role members. Every one of those operations re-signs the roster with the Owner's key, which is what makes membership tamper-evident. Admins cannot do it.
Invite a member
They export their public identity
On their machine, your teammate opens Settings → Account → Identity and exports their public identity file. It contains their signing (Ed25519) and encryption (X25519) public keys — nothing secret. They send it to you however they like.
You import it
In your own Identity settings, import their public identity. They now appear as a known identity, ready to be added to a vault.
Add them to the team vault
From the team dashboard, pick them from the list of known identities and add them. Their copy of the vault key is wrapped for their public key on the spot — nothing is shared in plaintext, and they don't have to accept anything.
Set their role
A newly added member is a Writer by default. Change them to Admin or Reader if that's what you want — see Roles & permissions. You cannot assign Owner.
Adding a member re-wraps the existing vault key for them, so nothing has to be re-encrypted and everyone else's copy keeps working. Every member you add consumes a seat, whatever their role; if the roster is already at your licensed seat count, the addition is refused and the message tells you the count and the limit.
If your team is managed in your Apilium organisation, the Owner can also reconcile the vault against that roster in one action: people on the organisation roster who aren't in the vault are added, and people no longer on it are revoked. Reconciliation carries membership, not roles — you still set roles in the vault.
Revoke a member
Removing someone from a team brain isn't a soft "hidden from the UI" change — it is cryptographic.
Remove them from the vault's membership
Only the Owner can do this.
The vault key is rotated
A fresh data key is generated and wrapped for every remaining member. The old key — the one the revoked member holds — is retired.
The store is re-encrypted
The vault's encrypted contents are re-encrypted under the new key before the change is saved, and the roster is re-signed with a bumped version so an older roster cannot be replayed to bring them back.
Revocation cuts off future access. Anything a former member already synced or read while they had the key cannot be un-seen — no end-to-end encrypted system can do that. Treat revocation as a boundary in time, not a retroactive erase. This mirrors how Altretta's signed history treats removals everywhere: a forward-looking retraction, never a silent rewrite of the past.
Changing someone's role
The Owner can change a member's role at any time — promoting a Reader to Writer, or dropping a Writer to Reader. The change is written into the roster and re-signed with the Owner's key; it does not rotate the vault key, and it is independent of any organisation-roster reconciliation. The read-only lock for Readers is applied on the client and enforced again when other devices decide whether to accept a change (see Roles & permissions).
Next
See how members' devices stay current once they're in → Encrypted sync.
Related
Team brain overview
The section this page belongs to.
The encryption model
Why wrapping and rotating a key is what makes revocation cryptographic.
Roles & permissions
The four roles, and who is allowed to manage membership.
Signing keys & identity
Exporting your public identity, and importing someone else's.
Signed history
Why revocation is a forward boundary, like every removal in Altretta.