Envelope Encryption: Per-Tenant Keys for AI Platforms
TL;DR — Envelope encryption uses two key layers: DEKs encrypt data, KEKs wrap DEKs. For multi-tenant AI, each tenant gets their own KEK — cryptographic isolation enforced at the KEK boundary. The KEK lives in a KMS (AWS KMS, GCP Cloud KMS, Azure Key Vault) and never leaves it. BYOK becomes a configuration change, not an architecture change. DEKs are generated fresh per operation, so rotation is only needed for KEKs (every 90 days). This is the enterprise standard for per-tenant encryption in AI platforms.
Multi-tenant AI platforms face a fundamental encryption challenge: how do you ensure that one tenant's data cannot be decrypted with another tenant's keys, even if they share the same database and infrastructure?
The answer is envelope encryption with per-tenant Key Encryption Keys (KEKs). This is the foundation of how production key management systems work, including AWS KMS, Google Cloud KMS, Azure Key Vault, and HashiCorp Vault (WorkOS 2026). Understanding it is a prerequisite for building tenant isolation at the cryptographic level.
This post covers the envelope encryption architecture, per-tenant key isolation, BYOK support, and key rotation. For Fernet encryption of API keys and secrets, envelope encryption adds the per-tenant key hierarchy layer.
What Is Envelope Encryption?
Envelope encryption is the process of encrypting a key with another key. Instead of using a single key to encrypt all data, you use two layers:
Data Encryption Key] DEK -->|wrapped by| KEK[KEK
Key Encryption Key] KEK -->|managed by| KMS[KMS / HSM
Never leaves boundary] KMS -->|stores| TenantKEK[Tenant-specific KEK]
| Key type | Purpose | Lifecycle | Storage |
|---|---|---|---|
| DEK (Data Encryption Key) | Encrypts actual data | Fresh per operation, short-lived | Never stored in plaintext |
| KEK (Key Encryption Key) | Wraps (encrypts) DEKs | Long-lived, per tenant | KMS or HSM (never exported) |
| Master Key | Root of trust for KMS | Annual rotation | HSM (never leaves hardware) |
The process for encrypting data:
1. Generate a fresh DEK locally
2. Encrypt the data with the DEK
3. Use the KEK to wrap (encrypt) the DEK
4. Store the encrypted data and the wrapped DEK together
5. Discard the plaintext DEK from memory
The KEK never leaves the KMS. Only the wrapped DEK is stored alongside the ciphertext. To decrypt: call KMS to unwrap the DEK, then use the DEK to decrypt the data (Google Cloud KMS 2026).
Per-Tenant Key Isolation
The critical architectural decision: each tenant gets their own KEK.
Cryptographic isolation is enforced at the KEK boundary. There is no path from Tenant A's KEK to Tenant B's data because Tenant B's DEKs were never wrapped with Tenant A's KEK. The math prevents it (WorkOS 2026).
| Isolation level | How it's achieved |
|---|---|
| Cryptographic | Per-tenant KEKs — one tenant's key cannot unwrap another's DEKs |
| Key context | KEK resolved from tenant ID — no key registry to manage |
| Access control | KMS IAM policies limit which services can use which KEKs |
| Audit | KMS logs every wrap/unwrap operation with tenant context |
Key Context: Eliminating the Key Registry
The traditional approach to per-tenant keys requires a key registry: a database mapping tenant IDs to KEK IDs. This creates operational overhead — you must manage the registry, handle key creation, and deal with edge cases.
The modern approach uses key context: the tenant ID is the context. When encrypting, the KMS resolves (or creates just-in-time) the KEK associated with that context. When decrypting, the KMS resolves the correct KEK from the stored context. No key registry needed (WorkOS 2026).
| Approach | How it works | Tradeoff |
|---|---|---|
| Key registry | Database maps tenant → KEK ID | Explicit, but operational overhead |
| Key context | KEK derived from tenant ID | Simple, no registry, just-in-time creation |
| Key derivation | KEK derived from master key + tenant ID | Stateless, but requires careful crypto design |
BYOK: Bring Your Own Key
Per-tenant KEKs make BYOK a configuration change, not an architecture change. The tenant provides their own KEK through their KMS. The platform uses it to wrap their DEKs.
| BYOK aspect | How it works |
|---|---|
| Tenant provides key | Tenant creates KMS key in their cloud account |
| Platform registers key | Platform stores the key ARN/URI with the tenant config |
| Encryption uses tenant key | All DEKs for that tenant are wrapped with the tenant's KEK |
| Revocation | Tenant revokes platform access → data becomes unreadable |
| Key rotation | Tenant rotates their KMS key → platform uses new version automatically |
For BYOK security, this is the architectural foundation. Without per-tenant KEKs, BYOK is impossible — you cannot let one tenant control their encryption without isolating their keys from other tenants.
Key Rotation
| Key type | Rotation frequency | How it works |
|---|---|---|
| DEK | Per operation (no rotation needed) | Fresh DEK generated for each encryption |
| KEK | Every 90 days | New KEK version created in KMS; new DEKs wrapped with new version |
| Master Key | Annually | KMS-managed, transparent to application |
When a KEK rotates:
1. New KEK version is created in KMS
2. New encryption operations use the new KEK version
3. Old wrapped DEKs remain decryptable with the old KEK version
4. Background process re-encrypts old data with new DEKs wrapped by new KEK
5. Old KEK version is retired after all data is re-encrypted
This enables zero-downtime key rotation. The KMS maintains multiple versions of each KEK — new versions for encryption, old versions for decryption of legacy data.
KMS Comparison for AI Platforms
| KMS | Key type | HSM support | BYOK | Cost model |
|---|---|---|---|---|
| AWS KMS | Customer managed keys | CloudHSM | Via cross-account key policy | $1/key/month + per-API-call |
| GCP Cloud KMS | CMEK | Cloud HSM | Via Cloud EKM | Per key + per operation |
| Azure Key Vault | RSA/AES keys | Managed HSM | Via key vault | Per key + per operation |
| HashiCorp Vault | Transit engine | External HSM | Via transit secrets engine | Self-hosted (infrastructure cost) |
For self-hosted AI platforms, HashiCorp Vault's Transit engine provides KMS functionality without cloud dependency. The Transit engine performs cryptographic operations without ever exposing key material — the same envelope encryption pattern as cloud KMS services.
Compliance Mapping
| Regulation | Requirement | How envelope encryption helps |
|---|---|---|
| GDPR Article 32 | Security of processing | Per-tenant encryption with KMS-managed keys |
| GDPR Article 25 | Data protection by design | Envelope encryption is a design-level control |
| HIPAA | Encryption of PHI | DEKs encrypt PHI; KEKs in HSM-backed KMS |
| SOC 2 CC6.7 | Data transmission and disposal | Crypto-shredding: revoke KEK → data unreadable |
| ISO 27001 A.10.1 | Cryptographic controls | NIST-approved algorithms, HSM-backed keys |
Crypto-shredding: When a tenant leaves the platform, revoke their KEK. All their data becomes permanently unreadable — the wrapped DEKs cannot be unwrapped without the KEK. This satisfies data deletion requirements without physically deleting every record.
FAQ
What is envelope encryption?
Envelope encryption uses two layers of keys: a Data Encryption Key (DEK) encrypts the actual data, and a Key Encryption Key (KEK) wraps (encrypts) the DEK. The KEK lives in a KMS or HSM and never leaves it. This allows encrypting data at scale without sending all data through the KMS.
How does envelope encryption work for multi-tenant AI platforms?
Each tenant gets their own KEK. When encrypting tenant data, a fresh DEK is generated, encrypts the data, and is then wrapped by the tenant's KEK. The wrapped DEK is stored alongside the ciphertext. Tenant A's KEK cannot unwrap Tenant B's DEK — cryptographic isolation is enforced at the KEK boundary.
What is the difference between DEK and KEK?
A DEK (Data Encryption Key) is a random key generated per encryption operation that encrypts actual data. It is short-lived and never stored in plaintext. A KEK (Key Encryption Key) is a long-lived key stored in a KMS or HSM that wraps DEKs. The KEK never leaves the KMS boundary.
How does envelope encryption support BYOK?
With per-tenant KEKs, BYOK is a configuration change, not an architecture change. The tenant provides their own KEK through their KMS. The platform uses the tenant's KEK to wrap their DEKs. If the tenant revokes access, their data becomes unreadable — the platform cannot decrypt it without the tenant's key.
How often should you rotate encryption keys in an AI platform?
DEKs are generated fresh per encryption operation, so they don't need rotation. KEKs should rotate every 90 days. When a KEK rotates, new DEKs are wrapped with the new KEK. Old wrapped DEKs remain decryptable with the old KEK version until data is re-encrypted.
Want a self-hosted AI company brain that does all of this out of the box?
Book a demo →