OPEN BETA — FREE TO START

Your customers' LLM keys deserve a vault, not a database column.

LLMVault stores LLM credentials with envelope encryption, mints scoped tokens for sandboxes, and proxies requests to any provider. Your code never sees a plaintext key.

Deploy in 15 minutesRead the architecture
terminal
# 1. Store a customer's API key (encrypted automatically)
curl -X POST https://api.llmvault.dev/v1/credentials \
  -H "Authorization: Bearer $ORG_TOKEN" \
  -d '{"provider":"anthropic","api_key":"sk-ant-..."}'
# 2. Mint a short-lived token for the sandbox
curl -X POST https://api.llmvault.dev/v1/tokens \
  -d '{"credential_id":"cred_8x7k","ttl":"1h"}'
# → {"token":"ptok_eyJhbG..."}
# 3. Proxy requests — your app never sees the real key
curl https://api.llmvault.dev/v1/proxy/v1/messages \
  -H "X-Proxy-Token: ptok_eyJhbG..." \
  -d '{"model":"claude-sonnet-4-20250514","messages":[...]}'
# → streams response, key never exposed
SECURITY BUILT IN

The questions your customers will ask. We have the answers.

When your customers ask how their keys are protected, you'll have specific, technical answers — not hand-waving.

Q1"How are our keys encrypted at rest?"Envelope encryption. Every key gets a unique DEK (AES-256-GCM), wrapped by HashiCorp Vault Transit KMS. Plaintext is zeroed from memory immediately.
Q2"What if your database is compromised?"Attackers get encrypted blobs. Decryption requires Vault access, which runs on separate infrastructure with its own auth boundary.
Q3"Can we revoke a key instantly?"Sub-millisecond. Redis pub/sub propagates revocation to every proxy instance simultaneously. No cache windows. No stale credentials.
HOW IT WORKS

Three API calls. That's the whole integration.

01StoreYour customer pastes their key. You POST it to LLMVault. We generate a unique DEK, encrypt with AES-256-GCM, wrap with Vault Transit KMS, and zero the plaintext from memory. Done.
POST /v1/credentials
{
  "provider": "anthropic",
  "api_key": "sk-ant-..."
}
02MintNeed sandbox access? Mint a scoped JWT with a TTL. Bound to one credential, expires automatically, dies everywhere the instant you revoke it.
POST /v1/tokens
{
  "credential_id": "cred_8x7k",
  "ttl": "1h"
}
03ProxySend LLM requests through LLMVault. We resolve the real key from encrypted storage, handle auth differences between providers, and stream the response back. Your sandbox never sees the key.
POST /v1/proxy/v1/messages
X-Proxy-Token: ptok_eyJhbG...
{
  "model": "claude-sonnet-4-20250514"
}
FEATURES

What you get. Specifically.

Envelope EncryptionEvery key gets its own DEK (AES-256-GCM), wrapped by Vault Transit KMS. Compromise your database and Redis — you still get nothing usable.
Sub-5ms OverheadThree-tier cache: sealed memory, Redis, Postgres. Hot path resolves in 0.01ms. Cold path: 3-8ms. Your users won’t feel the extra hop.
Scoped TokensMint JWTs bound to one credential. Set a TTL from seconds to 24 hours. Hand it to a sandbox. Sleep well.
Every ProviderOpenAI, Anthropic, Google, Fireworks, OpenRouter — each authenticates differently. You send one request. We handle the rest.
Instant RevocationCustomer disconnects? Token compromised? Revocation hits every instance via Redis pub/sub. Sub-millisecond. No stale windows.
Tenant IsolationEvery DB query scoped by org_id. Every Redis key namespaced. Tenant A can never reach Tenant B — by architecture, not convention.

Ship BYOK support in days, not months.

Free tier. 10 credentials. 10,000 proxy requests. No credit card.

Start buildingTalk to an engineer