LLMLab supports both cloud-managed encryption and client-controlled private data encryption keys (DEKs), so teams can choose where operational convenience ends and hard key custody begins.
Organizations can choose which data remains on Google Cloud KMS and which data requires the org's private DEK. Secrets, stored text chunks, and logs can be moved onto the private-DEK path, keys can be rotated, recovery can be enabled, and a trusted computer can keep a local copy for day-to-day use.
Some teams want platform-managed encryption with simpler recovery and operations. Others want a harder boundary without the possibility of external decryption. LLMLab supports both inside the same product surface.
When an org keeps a data type on KMS, LLMLab stores encrypted payloads using a cloud-managed key path. That is the operationally simpler mode and it fits teams that want strong encryption with platform-managed custody.
When an org enables the private DEK path, LLMLab encrypts the payload before storage using the org's current private DEK. That key is supplied by the client, and protected records cannot be decrypted later unless the right DEK is available again.
In LLMLab, the private DEK is a 256-bit data encryption key shown to admins as a base64url value. It is separate from identity, auth, and permissions. If a record is protected by the private DEK path, possession of that key is what makes decryption possible.
The admin privacy surface lets organizations choose whether secrets, stored text chunks, and logs stay on KMS or require the org private DEK. That means encryption policy can be tightened where it matters most without forcing every record into the same custody model.
Orgs can rotate their private DEK from the admin panel whenever needed, as long as the previous key remains available. LLMLab-managed keys rotate automatically in the background every 30 days, keeping protection current without extra admin work.
Convenience features do not turn private-key custody back into server-side plaintext custody. Recovery and trusted-computer support exist, but they are not accessible by LLMLab.
If recovery is enabled when a private DEK is generated or rotated, LLMLab stores only a wrapped recovery record server-side. The saved recovery phrase derives a key-encryption key through HKDF-SHA256 and unwraps the DEK later. That gives customers a recovery path without requiring LLMLab to retain a plaintext private DEK.
When an admin chooses the trusted-computer option, LLMLab saves a local copy of the DEK in that browser's local storage for that machine and user profile. It is there to reduce paste fatigue during normal operations, but it stays completely inaccessible to LLMLab.
LLMLab can rotate a private DEK and re-encrypt existing org-private records when the current DEK or a valid recovery phrase can still unlock the old key. If not, the fallback is a destructive reset path that replaces the key and purges data that can no longer be decrypted.
The private DEK option is meant to ensure no one outside the org has access to protected data. If an organization protects secrets, stored text chunks, or logs with a private DEK and loses that key, LLMLab cannot decrypt those records. The only options are finding a trusted computer that has stored the key or providing the recovery phrase. Without a client held DEK, the only ways to get pipelines working again are re-ingesting data and rotating secrets with a new key.
LLMLab gives teams built-in encryption choices, org boundaries, runtime visibility, and customer-controlled key direction where sensitive pipeline data needs it most.