We can't read your vault.
We mediate every agent call.
SherpaKeys is built two ways at once. The vault is zero-knowledge — even our own database administrators can't decrypt your credentials. The agent bridge is mediated — when Claude or Cursor needs to call Stripe through us, we decrypt server-side only long enough to make the call, then zero the key. The model never sees plaintext. This page walks through both — because security pages with no math deserve no trust.
TL;DR for the busy
- Your master passphrase never leaves your device. We literally do not have it.
- Every credential is encrypted in your browser with AES-256-GCM before it reaches us. By the time it hits the database, it's ciphertext.
- The key that encrypts your data is derived from your passphrase using Argon2id — the algorithm that won the Password Hashing Competition, tuned for modern hardware.
- If our database leaked tomorrow, the attacker would get a list of email addresses and gibberish. No keys. No way to brute-force a strong passphrase in any human lifetime.
- When Claude or Cursor calls Stripe through SherpaKeys, we decrypt server-side only long enough to make the API call. The AI never sees the plaintext secret.
The big idea
Zero-knowledge, in one paragraph
Zero-knowledge means the encryption keys exist only on your devices, derived from a passphrase you alone know. We store ciphertext and metadata. That's it. The encryption keys never touch our servers, so no insider, no compromised admin, and no subpoena can force us to hand over what we don't have. This architecture has been used by serious security products for over a decade — SherpaKeys applies it specifically to developer credentials.
What it costs you: if you forget your passphrase and lose your recovery code, your data is gone. We can't email you a reset link, because we don't have the key. This is the tradeoff that makes the security real.
The crypto
The actual algorithms we use
t=3, m=64MiB, p=1 — winner of the Password Hashing Competition. Tuned to make a brute-force attempt on a strong passphrase take centuries on commodity hardware.
The same algorithm that protects HTTPS, U.S. classified data, and most enterprise vaults. 12-byte random IVs per encryption. Authenticated — tampering with ciphertext fails decryption loudly.
Each credential is encrypted with its own AES key, which is itself encrypted by a project key, which is encrypted by your vault key. Compromising one entry doesn't cascade to the others.
The same recovery format used by Bitcoin wallets. 12 human-readable words encode enough entropy that nobody is brute-forcing it. Memorize them, or store them somewhere offline.
The flow
What happens when you save a credential
- 1
You enter your passphrase on first unlock
Your browser runs Argon2id on the passphrase + a per-user salt we store. The output is your vault key — 256 bits of entropy that exist only in your tab's memory.
- 2
You paste a credential
Before any network request, your browser generates a fresh 12-byte IV and AES-256-GCM-encrypts the credential value with your vault key (well, with a derived per-credential key wrapped by the vault key — but you get the idea).
- 3
The ciphertext travels to our server
Over HTTPS. Our server receives a base64 blob and stores it. We never see the plaintext, the IV alone is useless, and the vault key never left your browser.
- 4
When you reveal a key, it's decrypted in your browser
The encrypted blob comes back, your browser decrypts it locally, displays it for the configured reveal window (10 seconds by default), and zeroes the variable when it's done.
The agent bridge
How Claude can use a key without seeing it
Zero-knowledge would normally mean agents can't use your keys either — because there's no plaintext on the server to call Stripe with. So we added a careful escape hatch: the MCP agent session.
The setup (once)
When you connect Cowork/Cursor/Codex to SherpaKeys, your browser unwraps an ephemeral agent session key and seals it with a server-held master key (AGENT_SESSION_MASTER_KEY). The sealed blob is stored. Your browser key is gone.
The call (every time)
When the agent calls sherpa_call_api, we unseal the session key, use it to decrypt only the credential needed for that call, make the API request, and zero the key. The agent receives the API response. It never receives the secret.
The tradeoff: agent sessions trust our server slightly more than your direct vault access does. You can revoke any agent token instantly, every call is rate-limited, and every call appears in your activity log with the prompt that triggered it. If you never enable an agent session, this code path is never used.
Honesty
What SherpaKeys is NOT
- Not a password recovery service. Forget your passphrase and lose your recovery words and your data is gone. That's the cost of zero-knowledge.
- Not a substitute for HSMs. If you're storing nuclear launch codes or running a publicly-traded fintech, you need a hardware security module, not a SaaS vault. SherpaKeys is for the credentials a solo founder actually has.
- Not invincible if your laptop is compromised. If malware on your device steals your passphrase, no cryptography protects you. Treat your device security accordingly.
- We do publish what we've learned. Discovered a vulnerability? Email security@sherpakeys.com or open a private advisory at github.com/sdavis30731/sherpa. Responsible disclosure gets credited in our changelog.
Ready to put your keys somewhere safe?
Free for your first app, permanently. Same browser-encryption on every tier.
Get started, free