Envault
Core Concepts

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.

RoleDescriptionBest For
OwnerFull admin access. Can delete projects, manage users, and rotate keys.Check Tech Leads, DevOps.
EditorCan read, create, update, and delete secrets. Cannot manage users.Backend Developers.
ViewerRead-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:

  1. Current owner initiates a transfer request for a specific target user.
  2. Target user explicitly accepts or rejects the request.
  3. 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 pull to 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 Forbidden error.

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 + preview only).

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:

  1. A developer runs envault pull without an existing project membership.
  2. Envault checks if their GitHub account is a collaborator on the linked repository.
  3. If yes they are permanently registered as a Viewer in the project's access list and immediately receive secrets for the requested environment.
  4. 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.