[ VAULT ]
HSM-backed secrets for AI agents
1Claw Vault stores your API keys, tokens, and credentials with envelope encryption and Google Cloud KMS. Every secret gets its own unique Data Encryption Key — wrapped by an org-level KEK backed by hardware security modules.
[ FEATURES ]
Six layers of protection for every secret
Envelope encryption, policy enforcement, versioning, customer-managed keys, multi-party computation, and a tamper-proof audit chain.
Envelope encryption
Each secret encrypted with a unique DEK, wrapped by an org-level KEK in Google Cloud KMS. HSM-backed for paid tiers — software keys for free tier. No two secrets share a data key.
Policy-based access
Agents only access paths explicitly granted by humans. Glob patterns, IP restrictions, time windows — all enforced server-side before a secret is ever decrypted.
Secret versioning & rotation
Every PUT creates a new version. Server-side rotation generates cryptographically random values. Disable old versions without deleting — full history preserved for audit.
Customer-managed keys (CMEK)
Business/Enterprise: add your own AES-256-GCM layer on top of HSM envelope encryption. Your key never touches the server — only its SHA-256 fingerprint is stored.
Multi-party computation (MPC)
Split DEKs across GCP, AWS, and Azure KMS. 2-of-2 XOR client custody or 2-of-3 Shamir — no single provider holds the complete key.
Audit hash chain
Every event is SHA-256 chained (prev_hash | event_id | actor | action | resource | timestamp) for tamper detection. Full compliance trail, from day one.
[ ENCRYPTION ]
Envelope encryption in detail
Your secrets are never stored in plaintext. Each one gets a unique DEK, wrapped by a KEK that lives in the HSM.
Write (encrypt)
- 1Generate a unique 256-bit DEK for this secret
- 2Encrypt the plaintext with the DEK (AES-256-GCM)
- 3Wrap the DEK with the org KEK via Google Cloud KMS
- 4Store ciphertext + wrapped DEK. Discard plaintext DEK.
Read (decrypt)
- 1Unwrap the DEK via KMS (requires org KEK access)
- 2Decrypt the ciphertext with the unwrapped DEK
- 3Return plaintext to the caller. DEK cached briefly (5 min TTL).
- 4Audit event chained and logged.
[ HOW IT WORKS ]
From request to plaintext in four steps
Every secret read follows the same path: authenticate, authorize, decrypt, audit. No shortcuts, no bypasses.
Agent authenticates
JWT (short-lived, scoped) or API key. Auth middleware resolves the caller identity including org, scopes, and vault bindings.
Policy engine checks access
Path glob matching, read/write permissions, IP restrictions, time windows. No matching policy and no vault ownership → 403.
Secret decrypted via KEK → DEK
Wrapped DEK unwrapped by the org KEK in Google Cloud KMS. DEK decrypts the ciphertext. Plaintext returned to the caller.
Audit event chained and logged
SHA-256 hash chain: prev_hash | event_id | actor | action | resource | timestamp. Every read, write, and rotation is recorded.
[ SDK ]
Store and retrieve secrets in three lines
The TypeScript SDK, CLI, and MCP server all use the same API. Store a secret, retrieve it, rotate it — every operation is audited and policy-checked.
await client.secrets.put(vaultId, {
path: "providers/openai/api-key",
value: "sk-proj-...",
type: "api_key",
});
// ✓ Encrypted with unique DEK
// ✓ Wrapped by org KEK in KMS
// ✓ Audit event hash-chainedconst secret = await client.secrets.get( vaultId, "providers/openai/api-key" ); // Policy engine checked: path, permissions, IP // DEK unwrapped via KMS → plaintext returned // Agent never stores the key — fetches on demand
[ MPC ]
No single provider holds the complete key
Enable MPC on any vault. DEKs are split across multiple cloud KMS providers using XOR or Shamir secret sharing. Even if one provider is compromised, your secrets stay encrypted.
2-of-2 XOR client custody
One share on the server (GCP KMS), one returned to the client. Reconstructs with X-Client-Share header on read. You hold the second key.
2-of-3 Shamir multi-HSM
Shamir 2-of-3 across GCP KMS, AWS KMS, and Azure Key Vault. No client share needed — any two providers reconstruct the DEK.
2-of-3 Shamir client custody
Two shares on separate HSMs, one returned to the client. Requires X-Client-Share on read. Maximum control.
Tier-aware custody: Pro/Team vaults default to XOR 2-of-2 client custody. Business/Enterprise default to Shamir 2-of-3 multi-HSM — no client share management needed.
[ POLICIES ]
Humans grant. Agents obey.
Agents have zero access by default. A human must create an access policy — specifying path patterns, permissions, and optional conditions — before an agent can read a single secret.
- Glob path patterns — grant access to
providers/openai/*without exposingproviders/stripe/* - IP restrictions — only allow reads from specific CIDR ranges
- Time windows — policies can expire or only be active during certain hours
- Read / write / rotate — fine-grained permission control per policy
- Token revocation on change — when a policy is created, updated, or deleted, all active agent JWTs are revoked
await client.access.create(vaultId, {
principal_type: "agent",
principal_id: agentId,
secret_path_pattern: "providers/openai/*",
permissions: ["read"],
conditions: {
ip_allowlist: ["10.0.0.0/8"],
time_window: {
start: "09:00",
end: "17:00",
timezone: "America/New_York"
}
}
});Start storing secrets securely
Your agents deserve better than environment variables
Free tier includes 3 vaults, 50 secrets, and 1,000 API requests per month. Upgrade for MPC, CMEK, and unlimited secrets.
Already have an account? Sign in to your dashboard →