Access Control (RBAC)
Manage team permissions with fine-grained roles.
Envault allows you to control who has access to which projects using a Role-Based Access Control (RBAC) system.
Roles
There are three primary roles available in Envault.
| Role | Description | Best For |
|---|---|---|
| Owner | Full admin access. Can delete projects, manage users, and rotate keys. | Check Tech Leads, DevOps. |
| Editor | Can read, create, update, and delete secrets. Cannot manage users. | Backend Developers. |
| Viewer | Read-only access to secrets. | Frontend Developers, Contractors. |
Owner
The Owner has the keys to the castle.
- Manage Members: Invite or remove users from the project, and approve/deny share requests initiated by Editors.
- Delete Project: Permanently remove the project and all its secrets.
- Rotate Keys: Perform cryptographic key rotation.
- Billing: Manage subscription (if applicable).
Ownership Transfer Handshake
Project ownership transfer in Envault is a strict two-step handshake to prevent forced liability transfer:
- Current owner initiates a transfer request for a specific target user.
- Target user explicitly accepts or rejects the request.
- If accepted, Envault executes owner promotion + prior-owner demotion/removal + secret liability reassignment in one transaction.
Transfer requests expire automatically after 48 hours if not accepted.
Ownership never changes on initiate. The target user must explicitly accept for transfer to complete.
Editor
The Editor is the standard role for day-to-day development.
- Manage Secrets: Add new environment variables or update existing ones.
- Manage Environments: Create new environments (e.g.,
feature-branch-1). - Manage Secret Shares: Initiate and approve temporary access for other team members.
- View Audit Logs: See who changed what and all project activities.
Editors can initiate Share requests to temporarily invite new members to the project, and can also manage existing shares. Owners must approve new share requests that grant environment-scoped access.
Viewer
The Viewer role is strictly read-only.
- View Secrets: See values in the dashboard.
- Pull Secrets: Use
envault pullto get secrets locally. - View Audit Logs: See audit trail of project activities (read-only).
- Cannot Edit: Any attempt to write will result in a
403 Forbiddenerror.
Granular Permissions
Permissions are managed at the project role level, with optional environment allow-lists for non-owner members.
- Owners always have access to all environments.
- Editors/Viewers can be granted either all environments or a restricted
subset (for example,
development+previewonly).
When a member is restricted, Envault enforces that scope in dashboard and CLI/API flows. Operations targeting disallowed environments return an access denied error.
Agent Access Kill Switches
Agent mutation paths (SDK/MCP) require two explicit enablement layers:
- Global Agent Access: user-level master toggle in account security settings.
- Project Agent Access: project-level toggle in project settings.
If either switch is disabled, delegated agent mutation requests are blocked with 403.
Governance & Auditing
Every action taken by a user is logged. Owners can view the Audit Logs in the project settings to see:
- Who accessed a secret (and when).
- Who changed a value and what was modified.
- Environmental context and timestamps.
- Complete history of member additions, removals, and permission changes.
This visibility enables collaborative teams to maintain security awareness and accountability across all project activities.
Account Deletion Behavior
When a member deletes their account, Envault preserves project integrity and attribution context:
- Deletion is scheduled (soft-delete) for a 7-day grace period instead of immediate hard deletion.
- Signing back in during the grace window cancels deletion and restores normal account status.
- Shared secrets are not deleted during account removal.
- Ownership pointers are safely reassigned to the project owner where required.
- Creator/updater identity snapshots are retained on secret records so project history remains understandable in variable tables and audit timelines.
After the grace window expires, automated purge jobs permanently remove the account and clean up linked user-scoped records.
If a live user profile can no longer be resolved, UI surfaces a fallback identity label while preserving available metadata from prior snapshots.
Just-in-Time (JIT) Access via GitHub
When a project is linked to a GitHub repository, Envault can automatically grant Viewer access to developers the moment they run envault pull - no manual invite or owner approval needed.
How it works:
- A developer runs
envault pullwithout an existing project membership. - Envault checks if their GitHub account is a collaborator on the linked repository.
- If yes they are permanently registered as a
Viewerin the project's access list and immediately receive secrets for the requested environment. - If no the CLI offers to submit an access request to the project owner, including the requested environment when applicable.
GitHub Collaborators bypass the "Pending Approval" flow entirely. Once
auto-granted, the user is a full Viewer member of the project. They will see
the project in their "Shared with me" dashboard, can run subsequent CLI
commands like envault status without errors, and the Project Owner can view
and manage their permissions in the project's access list.
See the GitHub Integration guide for setup instructions.