Encryption model
Encryption with both managed and client-controlled key paths.
LLMLab supports both cloud-managed encryption and client-controlled private 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.
How it works
Different custody models support different trust boundaries.
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.
Google Cloud KMS for managed encrypted storage.
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.
Google Cloud KMS
Encrypted JSON payloads
Managed custody
Client-held decryption for higher-sensitivity org data.
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.
AES-GCM
Org private DEK
Client-controlled decryption
A DEK is the data key that actually encrypts the sensitive payload.
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.
256-bit key
Base64url presentation
Data-level boundary
Encryption can be scoped by org data type.
Today 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.
Secrets
Stored text chunks
Logs
Recovery and storage
Recovery phrases and trusted computers reduce friction without erasing the boundary.
The important design choice is that convenience features do not turn private-key custody back into server-side plaintext custody. Recovery and trusted-computer support exist, but they work very differently.
Recovery wraps the DEK. It does not hand LLMLab the key.
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.
Trusted means local browser storage, but only that machine.
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. It is not a cloud escrow service and it does not make a lost client-only key magically recoverable from LLMLab.
Re-encryption is possible when the current key is still available.
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.
Important boundary
If you use a private DEK and lose it, LLMLab cannot recover the protected data for you.
This is the part that matters most. Client-controlled decryption is valuable precisely because LLMLab does not have an invisible back door to your key.
Recoverable only if the recovery phrase still exists.
If recovery was enabled, the recovery phrase can recover the current DEK from the wrapped recovery record. Lose the phrase and the DEK together, and that recovery path is gone.
No recovery copy is stored server-side.
If recovery was not enabled, LLMLab stores no wrapped recovery copy. The DEK exists only where the customer kept it, including any trusted-computer copy they chose to save locally.
There is no LLMLab admin override for a lost client-only private DEK.
If an organization protects secrets, stored text chunks, or logs with a private DEK and then loses that key, LLMLab cannot decrypt those records. We cannot email ourselves a copy, click around an internal console, or silently recover it from the platform. The only fallback is to generate a new key and accept destructive loss of data that was encrypted with the unrecoverable one.
Built for real deployment
Use a platform where encryption is part of the system design.
LLMLab gives teams built-in encryption choices, org boundaries, runtime visibility, and customer-controlled key direction where sensitive workflow data needs it most.