Project & vault access

Access to a project is a membership row. Not a role code, not a permission, not who created it — a row on the project's Members tab that an administrator can see in a list and remove from it.

That one sentence decides everything on this page, including the two things people find surprising: an organization administrator holds nothing on a project they are not a member of, and being a member is still not enough to open the vaults attached to it.

The four questions, and what answers each#

Question	Answered by
May I know this project exists?	A membership row, or the business:project:read permission
May I edit, archive or re-staff it?	Your role on the membership row
May I see which vaults are attached?	A membership row of Project Admin or Project Viewer — or a key to one of them
May I open one of those vaults?	A key wrapped for you personally — see Permission is not a key

business:project:read is visibility, never authority. It exists so an auditor or a platform lead can see the whole estate without being able to act on any of it, so that holding it shows up in the access report, and so that it can be taken away. BUSINESS_ADMIN bundles it — which is why an administrator sees every project in the list, and is still refused when they open one.

Project roles#

Role	Secrets plane	Vault plane	Member management
Project Admin	Full	Full	Yes
Project DevOps	Full	None, ever	No
Project Viewer	Read-only	Read-only	No

Project DevOps is a machine-plane role. It ranks between the other two numerically but is deliberately given no vault access at all — an operator who manages a project's secrets is not thereby given the credentials in its vaults.

An administrator is not automatically on your project#

An organization administrator — the owner included — holds no role on a project they have not been staffed onto. Opening one and being refused its vaults is the system working.

What business:config:manage grants instead is one organization-wide verb: staffing. Its holder may add members to any project in the organization, themselves included, from the project's Members tab. That is the way back into a project nobody is on.

Why it is not simply granted. Standing access that lives in a role code rather than a row is invisible in the member list, cannot be revoked by any screen, and survives offboarding — a departing employee keeps it and nothing can show you that they did. Staffing yourself takes one click, is recorded in the audit trail with your name and the time, appears in the member list afterwards, and is removed when you leave. Same reach; it is now something you can see and take away.

Permission is not a key#

The secrets in a vault are encrypted with a key the server never holds in a usable form. Each vault's key is wrapped separately for each person who may open it, using that person's own public key.

So joining a project grants the permission and not the key:

1. You are added to the project. Your access is recorded immediately.
2. A queued key handover appears. Someone who already holds that vault's key completes it from their own signed-in session — their browser does the unwrapping and re-wrapping, never the server.
3. Only then do the vaults open for you.

This is why no permission, role or administrator status can grant you a vault's contents.

The Vaults tab lists what you hold, not what your role suggests#

A project role is not a reliable answer to "can this person open this vault", so the Vaults tab does not use it as one. It shows:

• every vault attached to the project, if you have a membership row — including ones whose handover has not happened yet, marked Key handover pending, because that is how you learn one is owed to you;
• plus any attached vault you personally hold a key to, membership row or not.

That second line matters for key holders such as organization vault custodians, who hold a key to vaults their colleagues create. They could always open those vaults from the Vaults screen; the project's Vaults tab used to refuse them anyway and tell them they held no key, which was simply untrue. Two screens, one vault, two answers.

The organization's owner#

The owner is protected on the project plane the same way they are on the organization plane:

• They can be added to a project, and only as Project Admin.
• They cannot be demoted to a lesser role.
• They cannot be removed by anybody else — they may still leave themselves.

Every project belongs to the organization they own, so their standing on one moves by transferring ownership and not otherwise — exactly as their organization role does. The Members tab shows their row as Owner — role is fixed and offers no actions against it.

The owner still needs a membership row to open a project's vaults, for the reason above: a key is wrapped per person, and ownership does not conjure one.

Every project keeps an administrator#

A project can never be left with no Project Admin. Removing or demoting the last one is refused, and the message says so — promote somebody else first.

The count is of people, not rows: a Project Admin row held by a team with no active members grants that authority to nobody, and does not count.

Where to look when somebody cannot get in#

What they see	What it means	What to do
The project is not in their list	No membership row and no business:project:read	Add them to the project
"You need the … role on this project"	They are a member, at too low a role	Change their role on the Members tab
"You are not a member of this project, so you hold no key to its vaults"	No membership row and no key to any vault attached to it	Add them; an administrator can add themselves
A vault is listed as Key handover pending	They are entitled to it, but nobody has re-wrapped its key for them yet	Someone who holds the key opens PulsVault and completes the queued grant
A vault they expected is missing from the tab	They have no membership row, so they see only vaults they personally hold a key to	Add them to the project

To answer "what can this person reach?" across the whole organization, use the access report rather than checking each project — it reads every path from the things that actually enforce them, so it cannot drift from the server that decides.