Security
How VaultProof ensures your API keys are never visible to our servers — even in the event of a full breach.
The short version
Your key is split into two pieces in your browser before any network request is made. We store one piece. Your device keeps the other. Neither piece alone reveals your key. We cannot reconstruct it without your device actively participating.
Keys are split before any data leaves your browser or CLI. We receive a piece, not the key.
Reconstructing your key requires compromising both VaultProof and your device simultaneously.
The splitting and authorization code that runs on your machine is fully open source. Verify it yourself.
The Problem
Every API key manager faces the same fundamental problem.
To be useful, a key vault has to store your key. And if it stores your key, it can see your key.
This creates a single point of failure. If the vault provider is hacked, your keys are exposed. If a rogue employee queries the database, your keys are exposed. If a server is misconfigured and logs requests, your keys are exposed.
Most "secure" key vaults encrypt keys at rest — but they hold the encryption key too. Encrypting data with a key you also control isn't security, it's just an extra step for an attacker.
The numbers: In 2024, GitHub detected 39 million leaked secrets in public repositories. A single leaked OpenAI key can generate thousands of dollars in charges within minutes. API keys are the most targeted credential type in modern breaches.
The Guarantee
What VaultProof promises — and why it's structural, not a policy.
"VaultProof's servers never see your full API key. Not when you store it. Not when you use it. Not ever."
This guarantee holds even if VaultProof's database is fully compromised, our servers are under an attacker's control, or an employee queries every table in the database. The reason is simple: your complete key doesn't exist anywhere on our infrastructure.
Why "structural, not a policy" matters
A policy says "we promise not to look." A structural guarantee means there is nothing to look at. We don't store your complete key — so even if we wanted to expose it, we couldn't. The architecture enforces the guarantee without requiring you to trust us.
Storing a Key
What happens when you add an API key to VaultProof.
You paste your API key
The key enters your browser or CLI. It has not left your device yet.
Your key is split into two pieces — on your device
A splitting algorithm divides the key into two pieces. Neither piece alone reveals anything about the original key. This happens locally before any network request is made.
Piece 1 is encrypted and sent to the vault
One piece is encrypted and transmitted to VaultProof's servers for storage. This is all we receive.
Piece 2 stays on your device
The second piece is stored in your local configuration. It is never transmitted to our servers under any circumstances.
The vault receives an encrypted half of a key. That's all. Even with full database access, an attacker cannot reconstruct your key from what we store.
Using a Key
What happens when you make an API call through VaultProof.
Your device sends Piece 2 and an authorization proof
Your device transmits its piece of the key along with a cryptographic proof that you are authorized to access Piece 1.
The vault combines both pieces
The vault reconstructs your full API key in memory. This takes less than 100 milliseconds.
The API call is made
VaultProof makes the API call to the provider (OpenAI, Anthropic, etc.) using your reconstructed key.
The key is immediately destroyed
The reconstructed key is zeroed from memory. It is never written to disk, never logged, never persisted. The key existed whole for the duration of one API call.
What an Attacker Needs
To steal your key, an attacker needs both of the following simultaneously.
Encrypted, stored in VaultProof's vault.
Requires compromising VaultProof's infrastructure.
Stored only on your device. Never transmitted to our servers.
Requires compromising your device.
Compromising VaultProof's servers gives an attacker only Piece 1 — cryptographically useless without Piece 2. Compromising your device gives an attacker only Piece 2 — useless without Piece 1.
An attacker would need to simultaneously compromise both VaultProof's infrastructure and your device. These are two independent systems. A breach of one does not enable a breach of the other.
What We Can See
A precise breakdown of what VaultProof stores and what we can reconstruct.
| Data | What we store | What we can reconstruct |
|---|---|---|
| Your API key | Encrypted Piece 1 only | Nothing — we don't have Piece 2 |
| Your requests | Provider, timestamp, token count, status code | Not the key used to make them |
| Your authorization | A one-time-use proof (consumed on use) | Cannot be replayed |
| Your account | Email, billing info, usage stats | Standard account data only |
We can see that you made a request to OpenAI at 3pm and used 500 tokens. We cannot see your OpenAI key.
Breach Scenario
What a full compromise of VaultProof's infrastructure would yield.
An attacker with full database and server access would obtain:
Encrypted Piece 1 for every stored key
Request metadata (timestamps, providers, usage counts)
User account information (email, billing)
They would NOT obtain:
Any complete API key
Any plaintext key material
Piece 2 for any key (it was never sent to us)
In the event of a VaultProof breach, your keys remain safe. We recommend rotating them as a precaution, but a breach of our infrastructure does not expose your API keys to attackers.
Open Source Core
The code that runs on your machine is fully open source. You don't have to take our word for it.
We have open sourced the four packages that implement the security guarantee — the key splitting library, the authorization circuit logic, the SDK, and the CLI. These are the packages that run on your device. You can read, audit, and build them yourself.
The algorithm that splits your key into two pieces on your device before storage.
The zero-knowledge proof logic that authorizes key access without revealing credentials.
The client SDK that handles splitting and proxied API calls.
The terminal client. Key management, env injection, session handling.
Why not open source the backend?
You don't need to trust the backend — by design, it never holds enough information to reconstruct your keys. The security guarantee comes from the client-side architecture, not from trusting our servers.
Security Audit
Independent review of the cryptographic core by external researchers.
An independent security audit of the open source core is currently underway. The full report will be published here upon completion.
We will not redact findings. The complete report — including all issues found and their resolutions — will be publicly available.
Responsible Disclosure
Found a security issue? We take all reports seriously.
If you believe you've found a security vulnerability in VaultProof, please report it to us directly before public disclosure. We will acknowledge your report within 24 hours and aim to resolve confirmed issues within 14 days.
We do not pursue legal action against researchers who discover and responsibly disclose vulnerabilities.
[email protected]