Administration
Roles and permissions
How Vaultigen separates creating a vault, being accountable for it, and reading its secrets.
Vaultigen separates three things that many password managers mix up: who may create a container, who is accountable for it, and who may read its secrets.
The concepts
- Vault: the access boundary. Each vault has its own encryption key. Folders, tags and entries live inside it.
- Folders: one flat level per vault. They organize entries and can carry additional grants. An entry may also sit at the vault root.
- Grants: give a user or a team a role on a vault, a folder or a single entry, optionally with an expiry date.
- Permissions are additive. A folder or entry grant can add access, never take it away. That is why a vault’s Manager sees every entry in the vault.
- Creating a vault does not grant access to it. The creator becomes Manager only through an explicit, audited grant.
- Platform roles never grant access to secrets.
Vault roles
| Role | Purpose | Secret access |
|---|---|---|
| Viewer | Views metadata and reveals individual values and files. Every reveal is audited. | Read and reveal |
| Editor | Creates and updates entries within its granted scope. Cannot create or rename folders. | Read and edit |
| Manager | The vault’s operational owner: entries, folders, trash, revisions and membership. | Full, within the vault |
| Custodian | Accountable for the vault’s lifecycle: rename, read-only/archive/reactivate, transfer custody, initiate purge, read the member list. Exactly one per vault. | None |
Platform roles
| Role | Purpose | Secret access |
|---|---|---|
| Super Admin | Users, teams, settings, backups, keys, imports, vault shells. | None directly; only the audited emergency access. |
| Vault creator | May create vaults, nothing else. | None |
| Auditor | Reads the audit log and authorized metadata. | None |
One account can hold many roles: a person can be Super Admin, Custodian of one vault and Viewer of another at the same time.
What each vault role may do
| Ability | Viewer | Editor | Manager |
|---|---|---|---|
| See entries and metadata | ✓ | ✓ | ✓ |
| Reveal secrets, download files | ✓ | ✓ | ✓ |
| Create and edit entries | — | ✓ | ✓ |
| Move entries | — | Within its scope | ✓ |
| Delete and restore entries | — | — | ✓ |
| Create and rename folders | — | — | ✓ |
| Grant and revoke access | — | — | ✓ |
The rules that keep it safe
- A platform role never grants secret access, including Vault creator.
- Only a Manager changes access. Not the admin, not the Custodian. Nobody can grant themselves a way in.
- A Custodian governs without reading. The person who decides a project is over does not need its passwords.
- A Super Admin cannot create ordinary grants. A vault left without any active Manager is recovered through a separate, strongly re-authenticated and audited recovery action.
- Moves protect version history. An entry’s old versions are for its Managers. Someone without Manager rights on an entry that has history cannot move it to another vault, or into a folder they manage. A Manager’s cross-vault move takes the history along, so the destination vault’s Managers can see it.
- The server operator remains trusted. See Security model.
Restricted vaults
Because permissions are additive, no grant can hide an entry from a vault’s Manager. If a secret must be invisible to the group’s Manager, put it in its own vault with its own Manager and Custodian.
Rule of thumb:
- One vault per project, customer, system or department for everything the group shares.
- Folders and entry grants for least privilege inside it (the designer sees the design folder, a developer sees one SSH key).
- A second, restricted vault only when a secret must be hidden even from the group’s Manager.
“Why can I see this?”
Every vault shows a Why can I see this? panel that names the direct or team grants that give the current user access. Grant changes and their effects are also visible in the audit log.
Example: a web agency
A 30-person agency runs many client projects.
- The Super Admin runs the installation and cannot read client passwords.
- Senior project managers hold the Vault creator role and create a vault per client, for example “Acme – Website”. The account lead for Acme is the Custodian; the project manager is Manager.
- Inside the vault: folders
Design,CMS,Hosting,Analytics. - The designer gets Viewer on
Design. A developer gets Viewer on one SSH entry. An external contractor gets Editor on one folder, with an expiry date. - When the project ends, the Custodian archives or transfers the vault without ever knowing Acme’s passwords.
Example: a manufacturing company
- Central IT holds Super Admin and gives each department’s IT coordinator the Vault creator role.
- The maintenance coordinator creates “CNC Line 3”. The maintenance head is Custodian, the senior technician Manager.
- Operators receive a team grant (Viewer), so joining or leaving the department is one team change. The vendor admin password is restricted to two named people with entry grants.
- R&D needs one supplier credential from Finance. A Finance Manager grants R&D that single entry, never the whole vault.
Found a mistake? Tell us at [email protected].