Envault
Core Concepts

Security

Security architecture behind Envault's fast onboarding workflow

Security Architecture

Envault is built for fast developer onboarding without sacrificing sane security defaults. The goal is simple: teammates run envault login, run envault pull, and get the right variables without sharing raw .env files.

Envelope Encryption & Client-Side Encryption (CSE)

Envault implements a dual Envelope Encryption & Client-Side Encryption architecture. Your environment variables are never stored in plaintext within the database, and during CLI operations, they are encrypted locally on your machine before ever hitting the network.

  • Client-Side Encryption (CSE): During envault deploy and envault pull, the Go CLI is responsible for encryption and decryption. This ensures the Node.js API server never receives or processes your plaintext .env data. The cryptographic AES-256-GCM operations happen natively inside the CLI.
  • Data Encryption Keys (DEK): Every project has a unique, cryptographically secure Data Key. When your team saves an environment variable, it is immediately encrypted using this DEK via AES-256-GCM encryption.
  • Master Encryption Key (MEK): The Data Keys themselves are then encrypted using a global Master Encryption Key. We hand your CLI the locked box and the key, but the server never sees your plaintext secrets.

Key Rotation

In the event of a suspected security event (such as a leaked DATABASE_URL string), Envault allows Project Owners to seamlessly rotate the Data Key for a specific project. This re-encrypts all associated variables with a new DEK, limiting the blast radius of a potential breach without affecting other teams.

Transport Security

All communication between the Envault CLI, SDKs, MCP Agents, and the Core Server is strictly forced over HTTPS/TLS. The vault actively rejects any plaintext HTTP connections, ensuring secrets cannot be intercepted over public or compromised networks.

Data Governance & Identity Control

  • Row Level Security (RLS): Envault enforces access policies at the absolute lowest database tier. Even if a backend application flaw occurs, the database engine physically prevents an unauthorized user from reading rows belonging to a project they are not a member of.
  • Immutable Audit Logs: Every critical action—mutating a secret, rotating a key, agent delegations, and permission changes—is recorded in append-only audit_logs entries. Project Owners can review who changed what and when.
  • Identity Snapshots: If a team member leaves the company and their account is deleted, Envault preserves static, non-identifying metadata snapshots on the secrets they modified. This ensures your project's historical audit trail remains intact and readable.
  • Ownership Handshakes: Transferring project ownership requires a deliberate, two-step cryptographic handshake. The recipient must actively accept the transfer, preventing forced liability or unauthorized delegation.

Authentication Guardrails

  • Passkeys & WebAuthn: Envault supports passwordless, biometric authentication (e.g., TouchID, Windows Hello, YubiKey). This guarantees phishing-resistant, hardware-backed logins that are significantly more secure than traditional passwords. You can easily register your device under Settings > Security.
  • Rolling Secure Sessions: The CLI does not store plaintext passwords or long-lived authentication tokens in accessible files. Instead, it securely embeds Refresh Tokens directly into your operating system’s native Secure Enclave (macOS Keychain, Linux Secret Service, Windows Credential Manager).
  • Service Token Fencing: For CI/CD environments and headless machines, Envault issues scoped Service Tokens. The CLI possesses active context-awareness—if a developer attempts to accidentally run a Service Token on their local laptop, the CLI will automatically block the execution to prevent catastrophic local leakage.

Automated Agent Fencing (SDK/MCP)

When utilizing Envault's SDK or MCP for automated AI workflows, multiple security layers actively intercept the event:

  • Delegated Credentials: AI Agents are issued restricted, dynamically scoped envault_agt_ JWTs. They do not inherit your full user privileges.
  • Project Isolation: Agents are strictly fenced to the project explicitly defined in your .vscode/mcp.json or SDK initialization script.
  • Human-in-the-Loop (HITL): Crucial mutations (e.g., an AI attempting to overwrite your production STRIPE_SECRET_KEY) require explicit approval from a human Project Owner or Editor via the UI or CLI approve command before execution.
  • Kill Switches: You maintain ultimate control. Agent integration can be instantly severed via your user Security Settings (global) or specific Project Settings (isolated).

Verifiable Agent Control Surface (Hybrid Open Source)

Envault uses a hybrid model: the cloud core is proprietary, while the agent execution layer is open for inspection.

  • mcp-server/ is MIT-licensed and fully auditable.
  • src/lib/sdk/ is MIT-licensed and fully auditable.

This architecture is a direct DX advantage for teams that want verifiable behavior:

  • You can independently audit the exact HITL interception implementation.
  • You can inspect short-lived delegated envault_agt_ JWT handling in code.
  • You can verify that mutation execution remains approval-gated and cannot bypass human controls through opaque runtime behavior.

On this page