Zero-knowledge vault.
Governed access.
Credentials are encrypted in the browser before they reach the server. The vault key never leaves the device. Every reveal, copy, and export is intercepted, logged, and cryptographically signed — before it happens.
The problem
Access to the vault ≠ authorization to use what is inside it.
Shared password managers give every team member read access to every credential. One compromised session, one insider, one phishing link — and an attacker can reveal, copy, or export everything without any friction, any log, or any approval.
The Strix approach
Every credential access is a governed action.
Strix treats each reveal, copy, and export as an action to be evaluated — not just logged. HIGH and CRITICAL items produce a signed evidence record on every access. Exports require quorum approval. The audit trail cannot be deleted.
Zero-knowledge architecture
The server never sees your secrets.
Encryption and decryption happen entirely in the browser using the Web Crypto API. The vault key is derived from your master password and held only in React state — it is never written to storage, never sent over the network.
Encryption
AES-256-GCM
Key derivation
PBKDF2-SHA256, 210,000 iterations
Key location
Browser memory only — never stored
Verifier
Separate PBKDF2 pass with purpose label
Server sees
Ciphertext + salt + verifier hash only
Session expiry
15 min inactivity auto-lock
Setup
Master password + random salt → PBKDF2 → vault key (in memory) + verifier hash (sent to server). Salt + verifier stored. Vault key: never leaves the browser.
Storing a secret
Plaintext → AES-256-GCM encrypt (browser) → base64 ciphertext → stored on server. Server stores only encrypted bytes. Decryption requires the vault key, which only you have.
Unlocking
Password + stored salt → derive verifier → server compares (timing-safe). On match, vault key re-derived in browser. Session auto-locks after 15 minutes of inactivity.
Supported secret types
Enforcement points
Every action governed. Nothing exempt.
Strix intercepts these actions before execution — not after. Each one produces a signed evidence record independent of whether it is allowed or denied.
| Action | Risk | Enforcement |
|---|---|---|
| Reveal credential | HIGH | Access logged, signed evidence record created |
| Copy to clipboard | HIGH | Clipboard access logged per-field, per-session |
| Export collection | CRITICAL | Requires quorum approval, signed artifact produced |
| Share credential | HIGH | Decision record, approval required for CRITICAL items |
| Edit secret | HIGH | Edit event logged with actor and timestamp |
| Delete secret | CRITICAL | Audit trail preserved after deletion (itemName snapshot, SET NULL FK) |
Immutable audit trail
Deleting a secret does not delete the audit trail.
Access logs capture a snapshot of the item name at the time of every access. When a vault item is deleted, the foreign key is set to null — the logs remain, with the name, timestamp, actor role, and action type fully intact. No log can be deleted by deleting what it references.
See the vault in a live demo.
We'll walk through vault setup, a credential reveal with live evidence logging, and an export attempt that requires approval — all in a production system, not a sandbox.