WSL Vault for Compliance: One Tenant Never Opens Another’s Secrets

For compliance officers, risk committees, and regulators: WSL Vault makes sure one app, tenant, team, or environment can never open another’s tokens and secret keys. Unlike a classic HashiCorp Vault posture where a single root token in the wrong hands can expose everything, WSL Vault keeps custody personal — and requires both sides when a wide audience must obtain a shared secret. Deep dive: technical article · Product: /wsl-vault · wslvault.org features.

The compliance problem with a single root token

Many organisations still run a vault where one highly privileged root token (or a small set of break-glass credentials) can unseal and read across every team, application, and environment. If that token leaks — phishing, a laptop, a CI log, a well-meaning paste into chat — the blast radius is the entire secrets estate. Regulators do not ask whether you intended isolation. They ask what an attacker with that one credential can actually do.

HashiCorp Vault is powerful and familiar. The risk pattern we call out is organisational and architectural: when root-level power is concentrated, a single compromise becomes a serious data-breach event. Policies and namespaces help — until someone still holds a key that sits above them.

What WSL Vault changes for tenants and teams

Inspired by the product model on wslvault.org, WSL Vault seals secrets with envelope encryption and a per-tenant key hierarchy. A data key belongs to exactly one tenant. Finance cannot decrypt Payments. INT cannot casually open PROD. A cross-tenant request returns “not found” — cryptographic refusal, not a soft filter.

• One app / one team / one environment — each can be its own tenant with its own sealed world.
• No shared root walking stick — day-to-day access is a signed, per-tenant token, not a universal master key in every operator’s pocket.
• Zero plaintext at rest — a stolen disk or database dump yields ciphertext the database itself cannot open.
• Audit you can show — operations join a tamper-evident, hash-chained trail per tenant.

The ceremony: personal oath, dual control for shared secrets

When a WSL Vault ceremony concludes, each team and tenant custodian takes a practical oath: keep your own token secret. Do not share it in Slack. Do not commit it. Do not reuse it across tenants “for convenience.” That personal custody is the human half of zero trust.

When a wide audience or joint process must obtain a secret that spans tenants — a shared release gate, a joint audit export, a deliberate break-glass — policy can require both tenant tokens. Neither side alone is enough. That dual-tenant control turns “who approved this?” into something regulators recognise: two custodians, two authentications, one recorded purpose.

Zero trust that also ends secrets sprawl

Sprawl happens when people copy passwords into tickets, chat, and repos because the “proper” vault is too hard or too shared. WSL Vault is designed so the easy path is the safe path: short-lived leases, MFA for humans, workload identity for apps, and engines (KV, transit, PKI) behind one API. Teams stop scattering copies because the vault answers in seconds — and revoke actually stops access.

Watch and tour

Start with the silent console tour on the product site, then the longer presentation:

• Silent console tour (~2 min) — tenants, KV, transit, MFA, regions, audit
• Features tour — versioned KV, envelope encryption, transit, PKI, leases, two-factor identity
• Architecture tour — active/active multi-region mesh
• Security tour — audit chain, Shamir custody, tenant isolation, zero plaintext at rest
• Full presentation on YouTube (~20 min) — Steal the server. Not the secrets.

Related reading

• Technical deep dive — workflows, HA, MFA, diagrams
• Intro blog: Steal the server. Not the secrets.
• AI agents and cryptographic refusal
• Workstation WSL Vault product page

Need a secrets story your auditors can understand in one slide? Talk to Workstation.