Why one encryption key for every tenant is a risk
If every tenant’s sensitive data is encrypted under a single shared key, a compromise of that one key exposes every tenant at once. It also makes it operationally awkward to fully destroy one tenant’s data on offboarding without affecting others.
DEK-per-tenant: one key per tenant, wrapped by a platform key
Under this model, each tenant has its own Data Encryption Key (DEK), used to encrypt that tenant’s sensitive content (recordings, voicemail, SIP secrets) with AES-256-GCM — an authenticated encryption mode that also detects tampering with the ciphertext.
Key wrapping: why the DEK is not stored in the clear
The tenant’s DEK is itself encrypted ("wrapped") by a platform-wide Key Encryption Key (KEK) using AES-KW, the key-wrap algorithm defined in RFC 3394. This means compromising the database alone does not expose usable DEKs — the KEK, typically held in separate key-management infrastructure, is also required.
What this enables operationally
A tenant’s DEK can be rotated independently of every other tenant’s key, without requiring a platform-wide re-encryption. Fully destroying a tenant’s DEK on offboarding renders that tenant’s encrypted content permanently unrecoverable, independent of other tenants.
Can the vendor tell you — in one sentence — which of their AI capabilities are rule-based, which are generative, and which are still roadmap?