How KeyVault keeps your API key vault secure

Last updated: August 3, 2026

KeyVault exists to replace plaintext API key sharing — Slack messages, email threads, and .env files passed between laptops — with an encrypted, access-controlled vault. This page describes exactly how stored keys are protected. It states what the product actually does, not marketing claims.

Encryption at rest

Every API key is encrypted before it touches the database using Fernet from the Python cryptography library: AES-128-CBC with an HMAC-SHA256 authentication tag. The encryption key is supplied through the ENCRYPTION_KEY environment variable, and production deployments refuse to start without it — there is no insecure fallback.

Server-side masking for read-only access

Access to keys is granted per project at one of three levels: read, write, or admin. Members with read access never receive plaintext: the server returns a literal mask (••••••••••••) with a masked: true flag. The decision is enforced server-side, so the real secret never leaves the server for a read-only role.

Tenant isolation

Every signup creates an isolated organization, and every SQL query filters by organization_id. Cross-tenant data access is impossible by query construction — there is no code path that reads another organization's rows.

Account and session protection

• CSRF: synchronizer-token pattern. Every mutating request needs a per-session X-CSRF-Token header matching the server-bound token, plus an Origin/Referer check.
• Cookies: HttpOnly, Secure in production, SameSite=Strict. Stolen cookies cannot ride along on cross-site navigations.
• Rate limiting and lockout: Redis-backed, keyed on (email, source-IP) — not on email alone — so an attacker cannot pre-lock arbitrary accounts to deny service.
• Timing-attack resistance: login responses take constant time whether or not the email exists, defeating email-enumeration timing attacks.
• Invitation safety: a leaked invitation URL alone cannot add an existing user to another organization — the recipient must be signed in with the matching email address.
• Content-Security-Policy, frame-ancestors, and base-uri restrictions on every response.

Audit logging

Every organization has a complete activity log: who accessed which key, who invited whom, and what changed — scoped per organization and visible to authorized roles. This supports the access-logging recommendations of NIST SP 800-63B for credential material.

Infrastructure

• Hosting: Vercel (serverless), HTTPS only.
• Database: PostgreSQL on Supabase with parameterized queries throughout — no string-built SQL.
• Rate limiting / sessions: Redis on Upstash over TLS.
• Billing: handled by Polar. KeyVault never stores or sees card details.

Why this matters

• The Verizon 2024 Data Breach Investigations Report found 31% of breaches over the past decade involved stolen credentials.
• GitGuardian counted 23+ million secrets exposed in public GitHub commits in 2023 alone.
• Keys shared in Slack, email, or .env files are plaintext, searchable, and have no access control or audit trail.

Ready to move your keys out of Slack? Create a free vault — the Free plan includes every security feature on this page.