Security built for secrets that matter

1. Encryption Model

Every secret stored in envnest is encrypted with AES-256-GCM, an authenticated encryption algorithm that provides both confidentiality and integrity. Each secret receives its own unique data encryption key (DEK) — a 32-byte random key generated at write time. No two secrets ever share a key.

Each DEK is then wrapped (encrypted) by a key encryption key (KEK) managed through a Key Management Service (KMS). This architecture is known as envelope encryption. The encrypted secret and the wrapped DEK are stored together. The KEK never leaves KMS and never touches the application database.

Even if the database is fully compromised, an attacker would only obtain ciphertext and wrapped DEKs — both useless without access to the KEK in KMS.

2. Key Management

envnest supports two KMS providers:

• envnest built-in KMS (default) — Managed key infrastructure that handles key generation, wrapping, and unwrapping. No configuration required.
• Bring your own AWS KMS — Connect your own AWS KMS key for full control over key encryption keys. You manage the key policy, rotation schedule, and access grants. Available on all plans.

Key rotation is available on the Business plan, allowing automatic rotation of key encryption keys on a configurable schedule.

KMS also exposes cryptographic operations for direct use: encrypt, decrypt, sign, and verify. All data is base64-encoded in transit.

3. Not Zero-Knowledge

envnest is not a zero-knowledge system. The server performs encryption and decryption using the KEK managed by KMS. This is a deliberate design choice that enables server-side features like secret versioning, leak detection, runtime injection, and integration syncing.

We believe transparency about our security model is more valuable than a misleading marketing claim. If you require client-side-only encryption where the server never sees plaintext, envnest is not the right fit.

If you need maximum control, you can bring your own AWS KMS key so that key material never resides within envnest's infrastructure.

4. Access Control

envnest implements role-based access control (RBAC) at three levels:

• Organization — Manage members, billing, and global settings.
• Project — Control who can access which projects within your organization.
• Environment — Restrict access to specific environments (e.g., production vs. staging). Protected environments add an extra safety layer for sensitive contexts.

Built-in roles include Owner, Admin, Member, and Viewer. Business plans support custom roles with granular permissions and policy enforcement including approval workflows for sensitive operations.

5. Audit Logging

Every secret read, write, delete, and permission change is logged with full traceability. Audit logs capture the action, actor, timestamp, IP address, and affected resource.

Retention varies by plan:

• Free — 7 days
• Team — 30 days
• Business — 1 year or more

6. Data Protection

• Encryption at rest — All secrets are encrypted using AES-256-GCM with unique per-secret DEKs, wrapped via envelope encryption through KMS. No plaintext is ever stored.
• Encryption in transit — All communications between clients (CLI, web, API) and envnest use TLS 1.2 or higher. No unencrypted endpoints are exposed.

7. Secret Lifecycle

Secrets follow a managed lifecycle with full version history:

• Versioning — Every change creates a new immutable version. Nothing is ever silently overwritten. You can roll back to any previous version.
• Soft delete — Deleting a secret preserves its history so you can restore accidentally deleted secrets.
• Permanent delete — Irreversible deletion that removes all version history. Use with caution.
• Leak detection — envnest checks secret values against known data breaches (via HIBP integration) and warns you if a value has been compromised.

8. Infrastructure

The security architecture is designed around separation of concerns:

• No plaintext secret values are ever stored in the application database.
• Key encryption keys (KEKs) are isolated in KMS, separate from the application database and services.
• Runtime injection (envnest inject) passes secrets directly into process memory — no files on disk, no export commands, no shell history exposure.

9. Integrations Security

When you configure third-party integrations, secrets are shared with the target service as you direct:

• GitHub Actions — Secrets are synced to GitHub repository secrets using GitHub's encrypted secrets API. Syncing is one-way (envnest → GitHub).
• Coming soon — GitLab CI/CD, Vercel, and additional providers.

Integration credentials are encrypted at rest using the same envelope encryption model as secrets.

10. Contact

For security questions, vulnerability reports, or concerns, contact us at [email protected].