Skip to content
vaultigen

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

  1. A platform role never grants secret access, including Vault creator.
  2. Only a Manager changes access. Not the admin, not the Custodian. Nobody can grant themselves a way in.
  3. A Custodian governs without reading. The person who decides a project is over does not need its passwords.
  4. 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.
  5. 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.
  6. 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].