VN-12 · Per-Tenant Encryption Keys

Status: Contract-designed / model accepted. Runtime key-management wiring (cloud KMS integration, rotation, re-encryption) is later work. This note tells a validator what they can confirm today and what is explicitly deferred. Roles needed: Tenant admin / reviewer of the design record

What the client asked for

"Per-tenant encryption keys are Phase 1. BYOK is Phase 2."

What this proves (today)

The platform has an accepted, documented per-tenant, platform-managed encryption-key model: keys are referenced by tenant/purpose/version, key references are treated as metadata (never authorization), disabled keys fail closed, and plaintext key material never appears in logs, events, APIs, audit, UI, or exports. This is a design and contract deliverable for Phase 1; the full runtime enforcement is scheduled separately.

How it works (at a glance)

Where to look

• This is primarily a design record review. The accepted model is documented in the developer documentation (tenant encryption key model) and the relevant architecture decision record.
• There is intentionally no tenant-facing key API (keys are platform-managed), so nothing to "Try it out" in Swagger for keys themselves. Instead, confirm in /api/docs that responses expose only encryption_key_ref metadata (e.g. on the SSH session record) and never raw key material.
• In the portal, confirm the negative guarantee: no plaintext key material is ever shown anywhere.

Validation walkthrough

#	Action	What you should see
1	Review the accepted per-tenant key model in the developer docs	A documented model: tenant/purpose/version key references, lifecycle, fail-closed on disabled keys, additive-only BYOK later
2	Confirm the boundary statement	Plaintext key material is explicitly excluded from logs, events, APIs, audit, UI, and exports
3	In the portal, look anywhere keys could surface (settings, exports, audit)	No raw key material is ever displayed

Pass / fail checklist

• A per-tenant, platform-managed key model is documented and accepted
• Keys are referenced by tenant / purpose / version
• Key references are treated as metadata, not as authorization
• Disabled keys are defined to fail closed
• No plaintext key material appears anywhere in the portal, audit, or exports

Intentionally not in Phase 1

• Live cloud KMS/S3 runtime integration, automatic key rotation, key-disable runtime enforcement, and re-encryption flows. These are scheduled after the AWS production architecture decisions.
• Bring-Your-Own-Key (BYOK) — explicitly Phase 2.

Evidence to capture

• The accepted key-model design record reference.
• Confirmation (screenshot) that no raw key material is exposed in the portal.