LLM Data Encryption at Rest
LLM data without encryption at rest can be exposed in case of theft or database compromise. Four controls: database encryption, filesystem encryption, key management and encryption-at-rest policies.
What is LLM Data Encryption at Rest? Simply Explained
LLM data encryption at rest is like a safe for data at rest: database encryption encrypts database files with TDE or field-level. Filesystem encryption encrypts disks or volumes with LUKS/BitLocker. Key management stores keys securely in KMS or HSM with automatic rotation. Encryption-at-rest policies enforce encryption for all LLM data by sensitivity classification. Without encryption at rest, attackers can read plaintext in case of theft or database compromise — GDPR compliance is impossible.
↓ Jump to encryption at rest controls
4 Data Encryption at Rest Controls
Encrypt LLM data at rest in databases. Use transparent data encryption (TDE) or application-level encryption for sensitive data.
# Moltbot database encryption:
database_encryption:
enabled: true
# Transparent data encryption (TDE):
tde:
enabled: true
# Use database-native TDE for encryption at rest
# Encrypts: data files, log files, backups
# Supported: PostgreSQL, MySQL, MongoDB
# Key management: database KMS integration
# Application-level encryption:
app_level:
enabled: true
# Encrypt sensitive fields before storage
# Use: AES-256-GCM for field-level encryption
algorithm: "AES-256-GCM"
# Key management: per-tenant keys or KMS
# Column encryption:
column_encryption:
enabled: true
# Encrypt specific columns:
# - User prompts (may contain PII)
# - Agent outputs (may contain sensitive data)
# - API keys (if stored)
columns:
- user_prompt
- agent_output
- api_keysEncrypt LLM data at rest on filesystems. Use full-disk encryption or encrypted volumes for sensitive data storage.
# Moltbot filesystem encryption:
filesystem_encryption:
enabled: true
# Full-disk encryption:
full_disk:
enabled: true
# Use LUKS (Linux) or BitLocker (Windows)
# Encrypts: entire disk, including OS and data
# Protects against: physical theft, disk access
# Encrypted volumes:
encrypted_volumes:
enabled: true
# Use encrypted volumes for LLM data storage
# Mount: /var/lib/moltbot (encrypted)
# Filesystem: ext4 with LUKS encryption
# Key management: key file or KMS
# Encrypted directories:
encrypted_dirs:
enabled: true
# Use eCryptfs or fscrypt for directory encryption
# Encrypts: specific directories only
# Example: /var/lib/moltbot/prompts, /var/lib/moltbot/outputs
# Key management: per-directory keysManage encryption keys securely. Use key management service (KMS) or hardware security module (HSM) for key storage and rotation.
# Moltbot key management:
key_management:
enabled: true
# Key management service (KMS):
kms:
enabled: true
# Use cloud KMS for key storage
# Providers: AWS KMS, GCP KMS, Azure Key Vault
# Features: key rotation, access control, audit logging
provider: "aws_kms"
# Hardware security module (HSM):
hsm:
enabled: true
# Use HSM for on-premises key storage
# Protects: keys in hardware tamper-resistant module
# Use: for highest security requirements
# Key rotation:
rotation:
enabled: true
# Rotate encryption keys periodically
# Interval: 90 days
# Automatic: yes
# Re-encrypt data: on rotation
# Key access control:
access_control:
enabled: true
# Restrict key access to authorized users
# Use: IAM roles, least privilege
# Audit: all key accessDefine and enforce encryption-at-rest policies. Ensure all LLM data is encrypted according to policy.
# Moltbot encryption-at-rest policies:
encryption_policies:
enabled: true
# Default encryption policy:
default:
# Encrypt all LLM data by default
# Exceptions: public data only
enabled: true
# Algorithm: AES-256-GCM
# Key size: 256 bits
# Data classification:
classification:
# Classify data by sensitivity:
# - Public: no encryption required
# - Internal: encryption recommended
# - Confidential: encryption required
# - PII: encryption required + key isolation
enabled: true
# Policy enforcement:
enforcement:
# Block writes to unencrypted storage
# Audit: encryption violations
# Alert: policy violations
enabled: trueFrequently Asked Questions
What is the difference between TDE and application-level encryption?
Transparent data encryption (TDE) is database-native encryption that encrypts data at the storage layer. The database handles encryption and decryption transparently to the application. Application-level encryption encrypts data at the application layer before sending it to the database. The application handles encryption and decryption. Both are necessary: TDE provides protection against disk theft and unauthorised database access. Application-level encryption provides protection against database administrators and database compromise. Example: TDE encrypts the entire database file. Application-level encryption encrypts specific fields (user prompts, agent outputs) with per-tenant keys.
How do I choose between KMS and HSM for key management?
KMS (Key Management Service) is a cloud-based key management service (AWS KMS, GCP KMS, Azure Key Vault). It provides key storage, rotation, access control, and audit logging. HSM (Hardware Security Module) is a hardware device that stores keys in a tamper-resistant module. HSM provides the highest security but is more expensive and complex to manage. Choose KMS for cloud deployments and cost-effective key management. Choose HSM for on-premises deployments and highest security requirements (e.g., regulated industries). Both provide secure key storage, but HSM provides additional protection against physical attacks.
How does key rotation work with encrypted data?
Key rotation involves generating a new encryption key and re-encrypting data with the new key. The process: 1) Generate new key. 2) Decrypt data with old key. 3) Encrypt data with new key. 4) Delete old key. For large datasets, this can be time-consuming. Optimisation strategies: 1) Rotate keys incrementally — re-encrypt data in batches. 2) Use key hierarchy — encrypt data with data encryption keys (DEKs), encrypt DEKs with master keys, rotate master keys only. 3) Schedule rotation during low-traffic periods. 4) Use lazy re-encryption — re-encrypt data on access.
What are the risks of not encrypting LLM data at rest?
Not encrypting LLM data at rest can lead to: 1) Data theft — attackers can steal unencrypted data from disk, backups, or database dumps. 2) Regulatory violations — non-compliance with GDPR, HIPAA, PCI DSS, etc., which require encryption of sensitive data. 3) Legal liability — lawsuits for data breaches. 4) Reputation damage — public backlash for data breaches. 5) Insider threats — database administrators or employees with database access can read unencrypted data. 6) Physical theft — stolen servers or disks contain unencrypted data. Encryption at rest protects against these risks by rendering data unreadable without the encryption key.