WSLVault: Why AI Agents Need Cryptographic Secrets Isolation

Long-form companion to the blog. For platform and security architects shipping AI agents on shared infrastructure: why secret lifecycle is non-negotiable, and why isolation must be cryptographic — not a WHERE clause. Product: TenthMatrix WSL Vault · wslvault.org · GitHub.

~20 min — youtu.be/O6q3_H0k2M8 · same recording angled for tenancy

1. Why protecting, rotating, and managing secrets is even more critical for AI agents

Classic apps usually fetch a small set of credentials at startup. Agents are different:

• Tool sprawl — one session may need cloud APIs, databases, ticketing, email, and MCP servers. Each credential is a live capability, not a config value.
• Session persistence — keys sitting in env files, chat context, or MCP configs outlive a single request. Without rotation and leases, compromise windows stay open.
• Autonomous action — once an agent holds a token, it will use it. There is no “wait for the human to notice” between leak and abuse.
• Multi-tenant agent platforms — Team A’s agent and Team B’s agent may share schedulers, storage, and observability. A bug or a stolen database dump must never hand one tenant the other’s plaintext.
• Compliance and audit — regulators and customers ask who accessed which secret, for which agent, and whether the trail can be tampered with.

That is why the control set for agents is stricter: protect (envelope encryption at rest), rotate (KEK/DEK and static roles on a period), and manage (identity-bound policies, short-lived leases, real revoke).

2. Why tenant IDs alone are cosmetic isolation

Most “multi-tenant vaults” isolate with application filters: WHERE tenant_id = ?. That fails closed only if every code path is perfect forever — including backups, analytics jobs, support tools, and the next junior PR.

When Team A and Team B share a platform, ask: can a bug or a stolen database dump ever hand one team the other’s plaintext? If the answer depends on a filter, the answer is yes.

3. Cryptographic refusal — WSLVault’s answer

WSLVault seals every secret before storage under a per-tenant hierarchy: DEK → tenant KEK → root KEK (KMS / HSM / Shamir). Each data key belongs to exactly one tenant. A cross-tenant request returns not found, not another tenant’s row with the wrong label.

That is cryptographic refusal: Team A cannot decrypt Team B even if an upper layer misroutes an identifier. Isolation holds at the crypto service — the place filter bugs cannot quietly rewrite.

4. Engines still work per tenant

Isolation does not mean you lose Vault-compatible workflows. Per tenant you still get:

5. Protect → rotate → manage (agent checklist)

1. Protect — envelope encryption; root custody outside the data plane; no plaintext in backups or audit payloads.
2. Rotate — rotate tenant KEKs and static roles on a period; keep old ciphertext readable via transit versioning where needed.
3. Manage — identity-bound tokens (not trusted headers alone), fine-grained policies, MFA for operators, leases with real revoke for agent sessions.
4. Prove — tamper-evident, hash-chained audit per tenant so you can show who did what without storing secrets in the trail.

6. Video chapters

7. Where to go next

• Site: https://www.wslvault.org/
• GitHub: https://github.com/bwalia/wslvault
• Getting started: GETTING-STARTED.md
• TenthMatrix product page: /en/wsl-vault
• Intro brief: Steal the server. Not the secrets.
• Related: Agentic AI security — MCP, OAuth, Vault leases

Published by TenthMatrix.