# Pattern: Key-per-Tenant

Status: seed
Readiness target: RL4 regulated production
Primary owners: NetKingdom, Railiance platform, product repos
Genesis family: Secrets and cryptography

## Problem

Shared encryption keys make tenant data separation and incident
containment weaker than the tenant model may require.

## Context

Use this pattern for sensitive tenant data, regulated tenants, object
storage, databases, backups, and export/deletion workflows.

## Forces

- Per-tenant keys strengthen isolation and revocation.
- Key lifecycle is operationally complex.
- Applications need safe key selection without tenant spoofing.
- Backups and derived data need the same key boundary.

## Solution

Assign tenant-specific encryption keys or key hierarchy roots where risk
requires it. Bind key use to trusted tenant context, policy, audit, and
rotation procedures.

## Verification

- Tenant data is encrypted with the correct tenant key or key hierarchy.
- Cross-tenant key use is denied.
- Rotation and revocation are tested.
- Backups and exports preserve tenant key boundaries.

## Related Patterns

- Tenant Data Partitioning.
- Tenant Context Propagation.
- OpenBao runtime secret authority.
- Central Audit Ledger.