Sharing Vaults with Your Team

This guide teaches you to stop sharing passwords over chat, email, and spreadsheets, and to run shared access properly instead. By the end you will know how vault-level sharing works, which role to give someone, how a share is delivered without ever sending a password, and, most importantly, what happens when you remove someone: their access ends, and the vault key is rotated so the copy they held stops working.

Sharing Happens at the Vault Level

After this section you will understand the one rule that makes sharing predictable. You share a vault, not an item. Granting someone access to a vault lets them open every entry in it. There is no per-item sharing to track, which means there is also no way to accidentally share one login and forget another in the same vault.

This is why the habit from Vaults, Items and the Password Generator matters: organize your secrets into vaults that match how you want to share them. A Marketing logins vault for the marketing team and a separate Ops infrastructure vault for engineers is a structure you can reason about at a glance. If you find yourself wanting to share half a vault, that is the signal to split it into two.

Sharing a vault with a teammate lets them view and use the credentials in it, which is the point of sharing. What it replaces is the loose copy: no password gets pasted into a chat, mailed around, or parked in a spreadsheet, and the credential stays in one managed place you can revoke. If what you need is for a machine or an agent to use a secret without anyone seeing its value, that is a different tool, covered in Secrets for Machines, Integrations and AI Agents.

The Three Roles

After this section you will know exactly which role to give someone. Vault access uses three roles:

  • Member can view and use the secrets in the vault. This is the right role for most people you share with: they get the logins they need and nothing more.
  • Manager can also create, edit, and delete items, and add other people to the vault as members. A manager cannot appoint another manager or an owner.
  • Owner can additionally change anyone's role, remove people, issue and revoke grants, export the vault, and rename or delete it.

Two guarantees keep this safe. A vault always keeps at least one owner, so it can never be orphaned, and the owner of your Personal vault (you) cannot be removed from it. And delegation is self-ceiling: a person can only grant the access they themselves hold, never more. This is what stops a shared vault from quietly sprawling: no one can hand out authority above their own.

Avoid the single-key-holder trap. Because you can appoint more than one owner on a shared team vault, do so: two owners means the team is never locked out because one person is unavailable, or because one person lost both their master password and their recovery kit. Your Personal vault is yours alone by design, but any vault you share for the team should have a backup owner.

Add People to a Vault

After this section you will be able to give a teammate access in a few clicks, and explain honestly that it never sends a password. Select a named vault in the rail and choose Manage Vault. The panel opens in place, with three tabs: Parent folder / project, Members, and Sharing & permissions.

  1. Open the Members tab. Current members are listed with their roles.
  2. Choose the role to add someone as under Add member: owner, manager, or member.
  3. Choose Add beside the person. The list offers the people in your organization who are not on the vault yet.

When you add someone, Backbuild does not email them a password or hand them a shared secret to copy. The vault's key is wrapped to that person's own key, on your device, so that only they can unwrap it. The server never sees a vault key in the clear, and no password travels anywhere. Because the key is wrapped to theirs, a person can be added only after they have set up their own Backbuild Secrets in your organization; until then the app tells you they need to set up their secrets first.

Manage Vault for the Ops infrastructure team vault, on the Members tab. The vault rail on the left lists the Personal vault and Ops infrastructure, with New vault, New folder, Import, Export, Watchtower, and Trash. Callout 1 marks the current members: Jordan Ellis (you) as owner and Priya Natarajan as member. Callout 2 marks the owner, manager, and member role chips on Priya's row, and callout 3 marks its Remove control at the far right. Callout 4 marks the Add member role chips, with member selected.
Manage Vault, Members: (1) who holds the vault key and at what role, (2) changing a role, (3) removing someone, and (4) the role a new member is added as.

Removing Someone Ends Their Access

After this section you will be able to answer the question every owner asks: when I remove someone, are they really locked out? Yes. An owner removes a person with Remove on the Members tab. From that moment the vault no longer opens for them: Backbuild refuses them the vault and its contents. In the same step the app rotates the vault key. It generates a fresh key on your device, re-encrypts every item under it, and wraps the new key to each person who stays, so the copy of the old key the removed person held no longer opens anything in the vault.

Machine access is bound to the key it was granted for, so a rotation also ends every machine grant on the vault, whoever authorized it: a workstation or CI runner authorized with the command line, or an on-demand container. Re-authorize the machines that should keep access, for example by running backbuild secrets login again on each one (see Secrets from the CLI).

A before-and-after diagram of removing a member. Before: three people, Ada, Ben, and Cara, each hold a wrapped copy of the vault key and can open the vault. Action: an owner removes Cara. After: the vault key is rotated to a new key; Ada and Ben receive the new wrapped key and keep access, while Cara's old key no longer opens the vault, shown by a struck-through lock. A caption notes revocation is immediate and cuts off forward access.
Removing a member rotates the vault key: the people who stay receive the new key, while the removed person's old copy no longer opens the vault.

Two situations make the rotation wait, and the app says so on the Members tab when they apply. The person is still removed straight away in both:

  • The vault has items in its Trash. The app asks you to empty the vault's trash. Empty it before you remove someone from a vault that matters, so the rotation runs in the same step.
  • The vault holds file attachments. Attachments cannot be re-keyed yet, so the vault keeps its key. The app suggests moving sensitive files to a new vault; for a sensitive departure, do that and rotate the credentials themselves.

In both cases the removed person also loses any machine access they had authorized on the vault.

Changing someone's role is different from removing them. Lowering a manager to member, for example, changes what they can do, but they remain a member who can read the vault, so their key stays valid. Lowering an owner also ends any machine access that owner had authorized.

One honest caveat applies to any secret manager: a person who already viewed and copied a specific password before you removed them has seen that value. Removal and rotation stop future access, not human memory. So for a departure that matters, the complete move is to remove their access and rotate the specific passwords they had used, exactly as your policy would after any offboarding. Backbuild makes both halves easy: removal is one action, and rotating a credential is the generator plus a save.

Grants for Services and Other Organizations

After this section you will know what the Sharing & permissions tab records, and what it does not do. Owners and managers can open the Sharing & permissions tab; only an owner can issue or revoke a grant. It holds three things:

  • Existing grants. Each grant with its recipient, whether it is in your organization or another one, and its permission. An owner can Revoke any of them.
  • Issue a grant. An owner chooses the recipient type, a built-in service, the entire organization, or another organization (one of the organizations you belong to, and optionally one of its members), sets the permission to read, or to write, which implies read, and chooses Issue grant.
  • Machines with access. A section meant to list the machines that hold a grant to this vault. It does not show machine grants yet, so list and revoke them over the REST API instead (see Secrets for Machines, Integrations and AI Agents).

The tab states the rule that governs all of this: a grant is an authorization record, and the recipient can decrypt only once the vault key is delivered to them. For a person, delivery is adding them on the Members tab; for a service, it is the machine-grant ceremony that service completes. The app does not deliver the key through an entire-organization or a cross-organization grant yet, so give a person access by adding them on the Members tab, and bring a partner from another organization into your own organization when they need a vault.

See Who Has Access, and Who Did What

The Members tab is the current picture of who holds the vault key and at what role, and the Sharing & permissions tab lists the grants recorded on the vault. Beyond that, every add, removal, role change, key rotation, grant, export, and item change is written to a tamper-evident audit log with the actor, the time, and the target, and never the secret value. The audit trail and how to read it are covered in Administration, Zero-Knowledge and Compliance.

How do I share a set of logins with my team without them getting pasted around?
Put those logins in a vault and add your teammates to it on the Members tab. The credentials stay in the managed vault; no password is emailed or copied into chat, and you can remove anyone in one action.

When I remove someone, are they really locked out of everything immediately?
Yes. Their access ends at once, and the vault key is rotated so the copy they held stops working, unless the vault has items in its trash or holds file attachments, in which case the app tells you what to do. For a sensitive departure, also rotate the specific passwords they had used, since nothing can un-see a value someone already copied.

Can a teammate grant access to more people than I intended?
Only within limits their role sets. A member cannot add anyone; a manager can add people as members but cannot appoint a manager or an owner, or remove anyone; only an owner can change roles, remove people, and issue grants. No one can grant access above their own level.

Can I share a vault with a whole group, a department, or my entire organization at once?
Not as a single action today. An owner can record a grant for the entire organization on the Sharing & permissions tab, but each person still receives the vault key when they are added on the Members tab, so add the people who need the vault there.

What stops me being the only person who can get in?
Appoint a second owner on any shared team vault. A vault always keeps at least one owner, and having two means the team is never locked out because one person is unavailable.

Can I see who accessed what?
The Members tab shows who currently holds the key and their role, the Sharing & permissions tab shows the grants, and a tamper-evident audit log records every change with the actor and the time.

Next Steps