Every Prodegy Vault plan uses client-side AES-256-GCM encryption. Your plaintext never leaves your device, and no server-side key can decrypt your data — not even ours.
Design principles
Prodegy Vault's security model starts from the assumption that servers get compromised. That assumption shapes every architectural decision.
Encryption keys are derived from your master password and never transmitted. The server receives, stores, and transmits only ciphertext — there is no server-held key that would compromise all secrets if leaked.
Every access, modification, and share is logged immutably. Logs are cryptographically anchored to a blockchain record — no admin action can retroactively alter what was recorded.
Access is granted at the secret level, not the vault level. JIT requests add time-boxing. DLP policies prevent leakage to unauthorised recipients. Every permission decision is logged.
Encryption at rest, TLS 1.3 in transit, 2FA for authentication, rate limiting on API endpoints, anomaly detection on access patterns, and DLP at the sharing layer — multiple independent controls, not a single perimeter.
All connections use TLS 1.3 with HSTS headers. Certificate pinning is enforced in the web application. Plaintext HTTP is rejected at the load balancer — there is no graceful downgrade path.
Even a full database dump exposes only ciphertext. Each secret uses an independent IV so patterns between secrets cannot be inferred. Rotation limits the damage window if a single key is compromised.
How encryption works
Here's the exact sequence from the moment you type a secret to the moment it reaches our database:
PBKDF2-SHA256 derives a symmetric key from your master password. This key never leaves your browser session.
AES-256-GCM encrypts the plaintext value with a randomly generated IV unique to each secret. The plaintext is discarded immediately after.
The encrypted ciphertext (never plaintext) is sent over TLS 1.3. Our API receives a payload it cannot decrypt — no key is included.
PostgreSQL stores only ciphertext with AES-256-GCM at the storage layer as a second defence. A database breach exposes nothing usable.
Client (your browser)
plaintext: "sk_live_abc123…"
ciphertext: "eyJhbGc…xXkL9"
Prodegy Vault API server
receives: "eyJhbGc…xXkL9"
db: encrypted_value = "eyJhbGc…xXkL9"
Server sees only encrypted bytes — not the key, not the plaintext.
Technical architecture
Every layer of the Prodegy Vault stack is hardened independently, so a breach at one layer doesn't cascade.
Client-side AES-256-GCM with per-secret random IVs. Keys derived via PBKDF2-SHA256 with high iteration count. No server-side key material is stored. Bcrypt for password hashes (cost factor 12+).
All endpoints enforce TLS 1.3 minimum. HSTS headers with preload submission. Certificate transparency monitoring. Automated certificate rotation via Let's Encrypt. HTTP connections rejected at load balancer.
JWT access tokens (short-lived, 15min) + refresh tokens stored as HttpOnly cookies. TOTP-based 2FA with HMAC-SHA1. Recovery codes hashed at rest. Rate limiting on all auth endpoints. Brute-force lockout with fail2ban.
Append-only audit log with no admin delete capability. Cryptographic hash chain links each log entry to the previous. Periodic blockchain anchoring of log state for independent verifiability. Export via tamper-evident signed bundles.
Operational controls
Security controls that protect both your data and the platform that stores it.
Block secrets from being shared outside approved recipient groups or domains. Real-time enforcement with violation logging.
Scheduled or on-demand rotation with rotation history preserved in the audit log for compliance evidence.
Time-boxed access grants with automatic expiry. No permanent elevated access — all JIT grants are reviewed and logged.
Automated email notifications at 30, 14, 7, 3, and 1 day before a secret expires. No missed rotation deadlines.
Permission checks on every API call. Roles enforced at the database query layer — not just in application logic.
Unusual access patterns — off-hours access, bulk downloads, geo-anomalies — trigger alerts for your security team.
Per-endpoint rate limits prevent credential stuffing, brute-force, and enumeration attacks on all public API surfaces.
Audit log state is periodically anchored to a public blockchain. The hash is independently verifiable — no trust required in Prodegy Labs infrastructure.
We take security reports seriously. If you've found a vulnerability in Prodegy Vault, please report it via our responsible disclosure process. We commit to acknowledging your report within 48 hours, providing a remediation timeline within 7 business days, and crediting you in our security advisories if you'd like.
We ask that you avoid automated scanning, do not access or modify other users' data, and give us reasonable time to remediate before public disclosure.
Send reports to security@prodegyvault.com — PGP key available on request. For general support inquiries, use support@prodegyvault.com.
Start with 10 secrets free and inspect the encryption layer yourself — or request a security-focused enterprise demo.
