Encryption at Rest for Cache Payloads

Org-shared cache payloads should be encrypted at rest because Keeptrusts cannot reliably classify all user content before caching. Responses may contain sensitive code, proprietary logic, or regulated data. Encryption ensures that even if storage is compromised, payload content remains protected.

Use this page when

• You need to verify or configure encryption-at-rest for cached LLM prompt/response payloads.
• You are documenting your security posture and need details on key management and cipher suites.
• You want to rotate encryption keys or migrate to customer-managed keys (BYOK).

Primary audience

• Primary: Technical Leaders
• Secondary: Technical Engineers, AI Agents

Why Encryption Is Recommended

The cache stores complete LLM responses as payload blobs. These responses may include:

• Proprietary source code generated for your organization.
• Code that references internal systems, APIs, or architecture.
• Explanations that reveal business logic or security controls.
• Content derived from regulated data in your repositories.

Because the cache system cannot inspect and classify every response before storage, encryption at rest provides a blanket protection layer regardless of content sensitivity.

What Is Encrypted

Component	Encrypted	Reason
Payload blobs (responses)	Yes	May contain sensitive content
Embedding vectors	Yes	Can be used to reconstruct content similarity
Prompt digests	No	Already hashed; no recoverable content
Freshness signals	No	Contain only hashes and identifiers
Audit metadata	No	Required for query performance
Entry identifiers	No	Required for lookup operations

Why Metadata Is Not Encrypted

Cache metadata (entry IDs, timestamps, freshness signals, audit records) is not encrypted because:

• It is needed for query operations and indexing.
• It contains only hashes and identifiers, not raw content.
• Encrypting it would prevent efficient cache lookups.
• Access control already restricts who can query metadata.

Encryption Configuration

Object Storage Encryption

Configure server-side encryption for the cache payload bucket:

cache:
  object_storage:
    endpoint: "https://s3.eu-central-1.amazonaws.com"
    bucket: "your-org-cache-payloads"
    region: "eu-central-1"
    encryption:
      type: "SSE-KMS"
      kms_key_id: "arn:aws:kms:eu-central-1:123456789:key/your-key-id"

Supported Encryption Types

Type	Description	Key Management
SSE-S3	S3-managed keys (AES-256)	AWS manages keys
SSE-KMS	KMS-managed keys	You control key policy
SSE-C	Customer-provided keys	You provide key per request
AES-GCM-256	Application-level encryption	Keeptrusts manages keys

Application-Level Encryption

For maximum control, enable application-level encryption. This encrypts payloads before they reach the storage backend:

cache:
  encryption:
    enabled: true
    algorithm: "AES-GCM-256"
    key_source: "vault"
    vault_path: "secret/data/cache/encryption-key"
    key_rotation_interval_days: 90

With application-level encryption, payloads are encrypted in memory before being written to object storage. Even if the storage backend's own encryption is misconfigured or bypassed, the data remains protected.

Key Management

Key Rotation

You should rotate encryption keys periodically. The cache system supports key rotation without re-encrypting existing entries:

1. New entries are encrypted with the current key.
2. Existing entries remain readable with their original key.
3. Keys are identified by key ID in the entry metadata.
4. Old keys are retained in the key store until all entries encrypted with them have expired via TTL.

Key Storage Options

Option	Description	Best For
HashiCorp Vault	External secret manager	Production deployments
AWS KMS	Cloud-managed keys	AWS-native deployments
Azure Key Vault	Cloud-managed keys	Azure-native deployments
GCP Cloud KMS	Cloud-managed keys	GCP-native deployments
Environment variable	Key in env var	Development and testing only

Key Access Policy

Restrict access to encryption keys to:

• The cache service account (for encrypt/decrypt operations).
• Key administrators (for rotation and policy management).
• Break-glass procedures (for emergency access).

No other service or user should have access to cache encryption keys.

Vector Storage Encryption

Embedding vectors should also be encrypted at rest. Configure your vector database's encryption:

cache:
  vector_storage:
    endpoint: "https://pgvector.internal:5432"
    encryption:
      enabled: true
      type: "TDE"  # Transparent Data Encryption

Why Vectors Need Encryption

While individual embedding vectors do not contain readable text, a sufficiently large collection of vectors can be used to:

• Identify similar queries across users.
• Reconstruct approximate content through nearest-neighbor attacks.
• Reveal patterns about what your organization is working on.

Encrypting vectors at rest mitigates these risks.

Verification

Confirm Encryption Is Active

1. Check your configuration for encryption.enabled: true.
2. Verify the storage backend reports encryption on stored objects.
3. Attempt to read a raw object from storage without the decryption key — it should be unreadable.

Audit Key Usage

Monitor key usage to detect anomalies:

Metric	Expected	Investigate If
Decrypt operations per minute	Correlates with cache hit rate	Spikes beyond normal traffic
Key access from unknown principals	0	Any non-zero value
Failed decrypt operations	0	Above 0 — possible key rotation issue
Key rotation age	Under configured interval	Exceeds rotation schedule

Performance Impact

Encryption adds minimal latency to cache operations:

Operation	Overhead	Notes
Encrypt (write)	~1-2ms	AES-GCM hardware acceleration
Decrypt (read)	~1-2ms	AES-GCM hardware acceleration
Key lookup	~5-10ms	Cached locally after first access

The performance overhead is negligible compared to the latency of upstream LLM calls that the cache avoids.

Related Topics

• Data Residency for Cached Artifacts
• Cache and Compliance: Meeting Audit Requirements
• Org Isolation in Shared Cache

For AI systems

• Canonical terms: Keeptrusts, encryption at rest, AES-GCM, cache payload encryption, BYOK, key rotation.
• Config surface: encryption key configuration, key rotation procedures, customer-managed keys.
• When answering encryption questions, reference the cipher suite, key management, and rotation details from this page.

For engineers

• Verify encryption-at-rest is active by checking the encrypted flag in cache entry metadata.
• Rotate encryption keys using the documented key rotation procedure without cache invalidation.
• Configure customer-managed keys (BYOK) through the encryption settings in platform configuration.

For leaders

• All cached LLM payloads are encrypted at rest by default — no configuration required for baseline compliance.
• Key rotation is non-disruptive: old keys decrypt existing entries while new keys encrypt new writes.
• Customer-managed keys (BYOK) satisfy enterprise requirements without platform team intervention.

Next steps

• Data Residency for Cached Artifacts
• Cache and Compliance: Meeting Audit Requirements
• Org Isolation in Shared Cache