Ciphertext, with metadata.
Secret values and names are encrypted. Account information, app and environment slugs, and operational metadata remain visible. A server compromise can expose that metadata and encrypted data.
Private by architectureTrust starts with
Trust starts with
where the keys stay.
We can store and sync your encrypted secrets.
We do not hold the keys to read them.
The boundaryYour machine holds
Your machine holds
the keys.
Local encryption and local execution are the foundation. The cloud handles storage and synchronization of encrypted data.
Your machineTrust boundary
01
Your AI agent
Requests an operation
using secret names.
OpaqueVault
Decrypts locally.
Injects into a subprocess.
02
Your subprocess
Uses the credentials
to do its work.
Encrypted sync
OpaqueVault cloud
Ciphertext storage.
No decryption keys.
No decrypt endpoint.
Simplified flow. The local agent holds scoped key material during use. A subprocess receives plaintext credentials for the operation you authorize.
The cryptographic foundation
Each layer has a job.
01
Derive locally.
Argon2idYour master password derives a key on your machine. Client-defined parameters prevent the server from negotiating weaker settings.
02
Encrypt before syncing.
AES-256-GCMEach secret has its own randomly generated data encryption key. The secret is encrypted, the key is wrapped, and the service receives the encrypted result.
03
Read the encryption specification ↗Protect the connection.
ML-KEM-768 + X25519The CLI enforces hybrid post-quantum key exchange for the OpaqueVault API connection. The transport layer is separate from encryption at rest.
Know what you’re trustingClear boundaries.
Clear boundaries.
Honest limits.
A useful security model explains the boundary as carefully as the benefit.
Values stay out of responses.
MCP tools return names, status, and metadata. The vault_run response omits stdout and stderr. The interceptor checks remaining content for secret-shaped patterns; it is a backstop that can miss encoded credentials.
The subprocess is trusted.
Credentials must be available to the process using them. A malicious command could misuse that access. Protect your machine and review the operations you authorize.
Evidence over promisesBuilt to be
Built to be
understood.
Review the documented architecture, release verification, and published security advisories.
Independent assurance
Our work continues.
A third-party security audit, a bug bounty program, and SOC 2 assurance remain roadmap items. This page does not claim a completed independent audit or SOC 2 certification.
Responsible disclosure
Found a vulnerability?
Share your findings privately so we can investigate and address them.
[email protected] ↗A closer look
Security, explained.
What can the server see?
The service can see account information, app and environment slugs, timestamps, and operational audit metadata. Secret values and names are encrypted; lookup tokens and encrypted key material are stored alongside them. Zero-knowledge refers to the service’s inability to decrypt your secret values, not to all metadata being hidden.
Is this a sandbox for an AI agent?
No. OpaqueVault keeps secret values out of its MCP responses. A subprocess receiving a credential can use it, and hostile code running under your user account may access local resources. Choose commands and tools you trust.
What does post-quantum transport protect?
The CLI’s connection to api.opaquevault.com enforces a TLS 1.3 hybrid key exchange using ML-KEM-768 and X25519. This addresses future decryption of recorded transport traffic. It is separate from AES-256-GCM encryption of stored secrets.
Can the server weaken key derivation?
Argon2id parameters are fixed in the client rather than negotiated with the server. Your master password and the derived key are not sent to the service.
A better boundary starts here