Project access & keys
Why joining a project is instant but opening its vaults can take a moment — what the wait means, who can end it, and what each role can reach.
Project membership is a Team and above capability — on Solo Professional a project has no Members tab, because it is only you. Adding somebody to a project — as a person or as a whole team — takes effect immediately. Opening the project's vaults can take a little longer, and that delay is deliberate. This page explains what is happening, what you will see, and who can finish it.
Two things happen, not one#
Joining a project grants permission. Opening a vault needs a key. They are separate, and only the first one is instant.
| What it is | When it takes effect | |
|---|---|---|
| Permission | You are on the project. You can see it, see its vaults listed, and use whatever else your role covers. | Immediately |
| Key | Your own copy of the vault's encryption key, encrypted so that only you can use it. | Once a colleague who already has the key completes the handover |
The reason for the split is the same one behind everything else in PulsVault: we cannot read the secrets in your vaults. They are encrypted with a key that exists only inside the browsers of the people who hold it. We store copies of that key, but every copy is sealed to one person's identity, and none of them can be opened by us.
So when you join a project, there is no key for us to hand you — we have none to give. A new copy has to be created for you by someone who already holds one, inside their browser, and sent to us already sealed.
This is exactly how sharing a vault with one person works, applied to everyone a project covers. See Vault sharing & DEK re-wrapping.
What you will see while you wait#
The vault appears in the project's Vaults tab with a note saying its key handover has not happened yet. The vault is real and yours to use — you simply cannot decrypt it until your copy of the key arrives.
Nothing is lost while you wait, and you do not need to do anything. The request does not expire, and you will be notified the moment your key arrives — you do not have to keep checking the page.
Who can finish it#
Anyone who can already open that vault and is allowed to share it:
- the vault's owner, or
- a member who holds it at Manager level with re-sharing allowed.
When one of them opens the project, the console shows "N members waiting for a vault key" and completing it is a single action. Their browser creates a sealed copy of the key for each waiting person and uploads only the sealed copies.
If nobody with a key opens the project, nothing happens — the handover is not automatic, and it cannot be, because it needs a key only a person has.
After a staffing change, ask one project admin who can open the vaults to visit the project. Their single visit completes the handover for everybody waiting, not one person at a time.
Roles, and which ones reach vaults at all#
A project role decides which side of the project you work on.
| Role | Project secrets | Project vaults |
|---|---|---|
| Admin | ✓ | ✓ — receives a key |
| Viewer | read | ✓ — receives a key |
| DevOps | ✓ | ✗ — never receives a key |
DevOps is deliberately a secrets-only role. It exists so you can give somebody a project's deployment work without also handing them the team's vaults. Nobody in that role is waiting for a key, because no key will ever be created for them — if they need the vaults, change their role to Viewer or Admin and the handover begins as usual.
What DevOps (and Admin) may do with the project's machine identities depends on one organization
setting, DevOps → Permissions → "Let project admins and DevOps members manage their project's machine
identities". When it is on, they create the project's machines, issue and revoke their keys, and grant
them this project's permissions — never another project's, never across environments, never on
shared. When it is off, that work needs the organization's own DevOps permissions. A project role
never lets anyone read a secret's value.
This applies to teams the same way: a team added to a project as DevOps gives every one of its members DevOps access, and none of them vault access.
Adding a team#
A team is a shortcut for the people in it. Adding a team to a project puts every active member of that team on the project at the team's role, and each of them is queued for their own key copy — keys are always per person, because each one is sealed to that person alone. There is no shared team key.
Someone who joins the team later is added to the project automatically, and queued for a key the same way.
If somebody never gets their key#
Two ordinary reasons, both self-correcting:
- They have not finished setting up their account. A sealed copy can only be made for somebody whose account is fully set up, so they stay in the queue until it is, and are picked up automatically afterwards.
- Nobody with a key has opened the project yet. Ask a project admin who can open the vaults to visit it once. After a few days the vault's owner is reminded automatically, so this resolves itself even if nobody chases it — but asking is faster.