Contextual Encryption for LLM and Vector Database Pipelines

We implemented a contextual encryption architecture that selectively encrypts sensitive fields before storage while preserving semantic searchability through a layered approach — encrypting PII in metadata while keeping sanitized, non-sensitive content available for embedding.

Architecture

• Encryption Engine: AES-256-GCM with per-tenant encryption keys
• Key Management: AWS KMS for key generation, rotation, and access control
• PII Detection: NER-based (Named Entity Recognition) PII classifier
• Vector Database: Milvus for similarity search on sanitized embeddings
• LLM Layer: Sanitized context sent to LLM, sensitive fields re-injected post-generation
• Audit System: Every decryption event logged with user, timestamp, and purpose
• Database: PostgreSQL for encrypted metadata

Contextual Encryption Strategy

Data Classification

Before any data enters the pipeline, a PII classifier categorizes each field by sensitivity level:

• Highly Sensitive (e.g., government IDs, financial account numbers, medical IDs) — Encrypted, never embedded, never sent to LLM
• Sensitive PII (e.g., full names, email addresses, phone numbers) — Encrypted at rest, placeholder-replaced before embedding
• Contextual (e.g., job titles, company names) — Encrypted at rest, available for embedding with consent
• Non-Sensitive (e.g., product descriptions, public information) — Stored and embedded as-is

Encryption Layers

Layer 1: Field-Level Encryption at Rest

Sensitive fields are encrypted with AES-256-GCM before storage. Each tenant gets a dedicated data encryption key (DEK) managed through a key hierarchy via AWS KMS. Shadow fields store searchable hashes for exact-match lookups without requiring decryption.

Layer 2: Sanitization Before Embedding

PII is detected and replaced with type-preserving placeholders before text is sent to the embedding model. This preserves semantic meaning for similarity search while removing identifiable information. The original-to-placeholder mapping is stored encrypted alongside the vector record.

Layer 3: Context Injection After LLM Generation

The LLM receives sanitized context with placeholders for generating responses. After generation, the system re-injects actual values from encrypted storage into the response. This prevents sensitive data from entering LLM training data or being cached by the provider.

Vector Database Security

Collection Design

Vector collections store sanitized embeddings alongside encrypted original metadata. Tenant isolation is enforced via partition keys, with each tenant's metadata encrypted using their own key. The API layer validates tenant ownership before any decryption operation.

Key Management & Rotation

Key Hierarchy

A multi-level key hierarchy is used: a master key in AWS KMS wraps per-tenant key encryption keys, which in turn wrap per-tenant data encryption keys used for field-level encryption. This enables efficient key rotation without re-encrypting the entire key chain.

Key Rotation Process

1. New DEK Generated — New data encryption key created under the existing key encryption key
2. New Writes — All new data encrypted with the new key; the old key remains valid for reads
3. Background Re-encryption — Batch job re-encrypts existing records with the new key
4. Old DEK Retirement — Once all records migrated, old key marked inactive
5. Audit Log — Rotation event logged with timestamps and affected record counts

Audit & Compliance

Decryption Audit Log

Every decryption event captures who requested it, what was decrypted, when, why (request context), and which key was used — providing a complete compliance trail.

GDPR Right to Erasure

The system supports full data deletion across both the relational database and vector database, with optional key rotation to cryptographically ensure no residual access. All deletion operations are logged in a GDPR audit trail.

Key Features

1. Field-Level Encryption — AES-256-GCM on sensitive fields, not entire records
2. PII Sanitization — Placeholders preserve semantic meaning for embeddings
3. Post-LLM Re-injection — Sensitive data never sent to LLM providers
4. Per-Tenant Keys — Isolated encryption keys with AWS KMS management
5. Key Rotation — Zero-downtime rotation with background re-encryption
6. Embedding Safety — Sanitized embeddings prevent inversion attacks on PII
7. Audit Trail — Every decryption logged for compliance reporting
8. GDPR Compliance — Automated erasure across encrypted stores and vector DB