Security Architecture
A technical overview of how VaultProof stores, proxies, and protects your API keys. This page is an architecture document, not marketing copy.
The short version
Your API key is split into two shares on your device before it leaves your browser or CLI. Share 1 is encrypted with authenticated encryption and stored on our servers. Share 2 is encrypted with your developer key and stays on your device. Neither share alone reveals the original key. When you make a proxied API call, both shares are temporarily assembled in server memory, used, then wiped. The key is never logged, never written to disk, and never stored whole at rest.
Key Storage
How your API keys are split and stored.
VaultProof splits every API key into two encrypted shares. Both shares are required to reconstruct the original key. This splitting happens entirely on your device (in the browser or CLI) before any data is sent to our servers.
You paste your API key
The key exists in your browser or CLI. Nothing has left your device.
The key is split into two shares on your device
A secret sharing algorithm produces two shares. Neither share contains enough information to derive the original key. This runs client-side before any network request.
Share 1 is encrypted and sent to VaultProof
This encrypted share is stored in our database. It is all we receive and all we hold.
Share 2 is encrypted with your developer key and stays on your device
This share is stored in your local configuration. It is never transmitted to our servers.
What this means in practice
Our database holds encrypted fragments, not keys. If an attacker gains full access to our database, they get one encrypted share per key. Without the corresponding second share from your device, that data is not usable.
Proxy Architecture
How API calls are proxied and what happens to your key during a request.
Your device sends Share 2 and an authorization proof
Your SDK or CLI transmits its share along with a cryptographic proof that you are authorized to access Share 1.
Both shares are assembled in server memory
The server decrypts Share 1, combines it with Share 2, and reconstructs your full API key in memory. This assembly takes approximately 100 milliseconds.
The API call is forwarded to the provider
VaultProof makes the API call to the provider (OpenAI, Anthropic, Supabase, etc.) using the reconstructed key. The provider receives and processes the full key, as it would with any direct API call.
The key is wiped from memory
After the response is returned, the reconstructed key is zeroed from memory. It is never written to disk, never logged, and never persisted. The complete key existed in server memory for the duration of that single request.
Important caveat
During proxy requests, your full API key does exist briefly in VaultProof's server memory. It also reaches the API provider (e.g., OpenAI) as part of the forwarded request. The security design ensures the key is not stored at rest, not logged, and not persisted -- but it is assembled in memory for the duration of each proxied call.
What We Protect Against
The specific risks this architecture is designed to address.
Keys leaking in source code. Your API keys are never in your codebase. You use a VaultProof developer key (vp_live_) instead. If your code is pushed to a public repo, no API keys are exposed.
Keys in .env files, CI logs, or git history. Since your actual API keys are split and proxied, they don't appear in environment variables, build logs, or commit history.
Keys leaking through AI tool context. If an AI coding assistant reads your project files, it sees a vp_live_ key, not your OpenAI or Anthropic key.
VaultProof's database being breached. An attacker who compromises our database gets one encrypted share per key. Without the second share from your device, the data is not usable to reconstruct any key.
What We Don't Protect Against
Honest limitations of this architecture.
Someone with both shares. If an attacker obtains both shares (e.g., by compromising your device and our servers simultaneously), they can reconstruct your key. The split-key design raises the bar significantly, but it is not unbreakable if both sides are compromised.
The API provider seeing your key. When VaultProof proxies a request to OpenAI, Anthropic, or any other provider, the provider receives your full API key as part of the HTTP request. This is how API authentication works. VaultProof does not change that.
Compromised client devices. If your device is compromised (malware, physical access), an attacker could extract Share 2 and your developer key. The security model assumes your client device is trusted.
In-memory attacks during proxy assembly. During the brief window when both shares are assembled in memory, a sophisticated memory-level attack on our server could theoretically extract the key. We mitigate this with per-request memory isolation, but we do not claim this is impossible.
Our approach to honesty
No security system is perfect. We think being explicit about what we do and don't protect against is more valuable than vague claims. If you find a gap we haven't listed, please tell us at security@vaultproof.dev.
Breach Scenario
What a full compromise of VaultProof's infrastructure would yield.
An attacker with full database and server access would obtain:
One encrypted share per stored key (not usable alone)
Request metadata (timestamps, providers, usage counts)
User account information (email, billing)
They would NOT obtain:
Any complete API key (requires the second share from your device)
Any plaintext key material
If VaultProof were breached, we recommend rotating your API keys as a precaution. A database breach alone does not expose complete keys, but defense in depth means acting as though it might.
Infrastructure
The services VaultProof runs on.
| Service | Role | Details |
|---|---|---|
| Edge Network | Edge compute and proxy | Runs the proxy logic at the edge with per-request memory isolation. DDoS protection included. |
| Database | Storage and auth | Stores encrypted shares, user accounts, and usage data. Row-level security enforced. All data encrypted at rest. |
| Stripe | Payment processing | Handles billing and subscriptions. VaultProof never stores credit card numbers. PCI DSS compliant. |
All data is encrypted in transit (TLS 1.3) and at rest. We use no custom infrastructure for compute or storage -- we build on established, audited platforms.
Logging & Monitoring
What we record, what we don't, and how we alert you.
What we log
Every proxied API call: which developer key was used, which provider endpoint was hit, the HTTP status code returned, request latency in milliseconds, and a timestamp.
Scanner actions: GitHub connect and disconnect events, scans started and completed, findings ignored by the user.
Administrative actions: tier changes, user bans, key revocations. All logged with timestamps and the identity of the actor.
What we do NOT log
Raw API keys. The reconstructed key exists in memory for the duration of the request and is never written to any log or database.
Request and response bodies. We do not inspect, store, or log the content of your API calls. The proxy forwards the body as-is.
Personally identifiable information beyond email. We store your email for account management. We do not collect names, addresses, or other PII.
Log retention
| Tier | Retention Period |
|---|---|
| Free | 7 days |
| Starter | 30 days |
| Pro | 90 days |
| Enterprise | Unlimited |
Real-time monitoring & alerts
Rate limit tracking. Every proxied call increments a real-time counter. You can see your current usage relative to your monthly limit in the dashboard and via the X-VaultProof-Usage-Warning response header.
Usage alerts. When you hit 90% of your monthly call limit, the proxy adds a warning header to responses. At 100%, calls are blocked with a 429 status.
Per-key webhook notifications. You can configure a webhook URL on each developer key. When your usage exceeds a threshold you set, VaultProof POSTs a signed payload to your webhook endpoint. The payload is cryptographically signed using a secret you provide, included in the X-VaultProof-Signature header.
Email alerts. You can set an alert email on each developer key. When usage crosses your configured threshold, the event is recorded and an email notification is sent.
Threshold alerts fire once per crossing
If you set a threshold of 100 calls per hour, you will get one alert when that threshold is crossed, not one per subsequent call. The alert state resets at the start of each hour.
Open Source
The client-side code is open source. Read it, audit it, build it yourself.
The key splitting library, authorization proof logic, SDK, and CLI are all open source. These are the components that run on your device and implement the security-critical operations. You can verify that keys are split client-side and that no key material is sent to our servers in plain text.
Splits your key into two shares on your device before storage.
Generates cryptographic proofs that authorize key access without revealing credentials.
The client SDK. Handles splitting, proxied API calls, and share management.
The terminal client. Key management, session handling, local configuration.
Responsible Disclosure
Found a security issue? Here is how to report it.
Email: security@vaultproof.dev
Response time: We respond to all reports within 48 hours.
Legal safe harbor: We will not take legal action against good-faith security researchers who follow responsible disclosure practices.
Credit: We will credit researchers who report valid issues, if they want to be credited.
Please report vulnerabilities directly before public disclosure. Include steps to reproduce, affected components, and potential impact if possible.
security@vaultproof.dev