Encryption and Sanitization
Column-Level Encryption
Sensitive database fields are encrypted at the application layer using AES-256-GCM before storage.
Format
Encrypted values are stored with a versioned prefix:
enc:v1:<base64-encoded-ciphertext>
The prefix enables future algorithm rotation without breaking existing data.
Overhead
AES-256-GCM encryption adds approximately 35-60 bytes of overhead per value (IV + auth tag + encoding). Columns storing encrypted data should be sized as text rather than fixed-length varchar to accommodate this overhead.
Key Management
Encryption keys are managed via GCP Secret Manager and injected as environment variables. The encryption module is provided by @elysium/security using libsodium-compatible primitives.
Implemented in packages/security/ at commit 4b572c2.
PII Sanitization
The Sanitization Service (port 3004) provides PII redaction before data is sent to AI models or LLM services.
Capabilities
| Feature | Description |
|---|---|
| Single record sanitization | Redact PII from a single data object |
| Batch sanitization | Process up to 1,000 records per request |
| Configurable policies | Custom rules for PII detection and redaction per entity type |
| Strict compliance mode | Enforces maximum redaction for regulatory contexts |
| Policy validation | Validates sanitization policy definitions before application |
| Vectorization | Prepares sanitized data for embedding/ML processing |
Sanitization Flow
- Upstream service sends data to the Sanitization Service
- Service applies configured sanitization policies
- PII fields are redacted or replaced with safe placeholders
- Sanitized output returned to caller
- Operation logged in audit trail
Use Case
The primary consumer is the Agent Orchestrator, which sends customer data through the Sanitization Service before passing it to LLM clients for analysis or recommendation generation. This ensures no PII reaches external AI providers.
Implemented in services/sanitization-service/src/ at commit 4b572c2.
HMAC Request Signing
Service-to-service requests are signed with HMAC-SHA256 to prevent unauthorized access to internal endpoints. See Service-to-Service Auth for details.
Webhook Signature Verification
Inbound webhooks are verified using HMAC-SHA256 with per-type secrets (WEBHOOK_SECRET_{TYPE}). Signature comparison uses constant-time algorithms to prevent timing oracle attacks.
Implemented in services/api-gateway/src/app.ts at commit 4b572c2.