Field-Level vs Volume-Level Encryption for Knowledge Bases
TL;DR — Volume-level encryption (TDE, full-disk) protects against physical theft when the system is powered off. Field-level encryption (AES-256-GCM at the application layer) protects sensitive columns even from database administrators. AI knowledge bases need both: volume-level for storage security, field-level for defense-in-depth against insider threats. AI pipelines have a structural encryption gap — data is unprotected in memory during ingestion, transformation, and recombination. Field-level encryption closes this gap by protecting individual fields at the point of capture.
Most organizations have TLS in place and encrypt databases at rest. Both protections are necessary. But both have the same limitation: they are removed the moment an application reads data into memory to process it. For traditional batch workloads, this window is narrow and controlled. For AI pipelines, which ingest, transform, and recombine data across multiple systems continuously, the unprotected window is structural, not incidental (Utimaco 2026).
The answer is field-level encryption: protecting individual data fields at the point of capture so that a customer name, a payment card number, or a healthcare record remains a protected value as it moves through every downstream system. An AI model training on tokenized values never sees the original data. An analytics pipeline running on encrypted fields never has cleartext in memory.
This post compares the two encryption approaches and explains why AI knowledge bases need both. For how to keep enterprise AI data private, encryption is the foundational layer.
The Three Encryption Layers
Database security requires three layers, each addressing a different threat:
| Layer | What it encrypts | Threat it addresses | When it's active |
|---|---|---|---|
| In transit (TLS 1.3) | Data moving over network | Network interception, MITM | During data transfer |
| At rest (TDE, FDE) | Database files, disk volumes | Physical theft, disk access | When system is powered off |
| Field-level (AES-256-GCM) | Specific sensitive columns | Insider threats, DBA access, compromised credentials | Always — even in memory |
Volume-Level Encryption: TDE and Full-Disk
Volume-level encryption protects data at the storage layer. Two approaches:
| Approach | How it works | Protection scope |
|---|---|---|
| Full-disk encryption (FDE) | Encrypts entire disk at OS level | Protects against physical theft when powered off |
| Transparent Data Encryption (TDE) | Encrypts database files at DB engine level | Protects against OS-level access to database files |
Both operate transparently: when the database starts, keys are unlocked and data is decrypted on the fly. A running database serves queries against plaintext data in memory and page cache. FDE and TDE provide no protection against authenticated queries (BuildWithAIToday 2026).
When volume-level is sufficient: Protecting against physical theft, lost backup tapes, cloud storage breaches, and compliance requirements for "encryption at rest."
When volume-level is insufficient: When you need to protect data from database administrators, when different fields need different encryption keys, or when regulatory compliance requires demonstrable data isolation per tenant.
Field-Level Encryption: Application-Layer Protection
Field-level encryption encrypts specific sensitive columns individually, at the application layer. The application encrypts before INSERT and decrypts after SELECT. The database stores only ciphertext. A DBA running SELECT * FROM users sees encrypted bytes, not plaintext (Bioquro 2026).
| Implementation pattern | How it works | Examples |
|---|---|---|
| Application-level encryption | App encrypts/decrypts; DB stores ciphertext | Custom AES-256-GCM in application code |
| Database native functions | DB engine provides encrypt/decrypt functions | PostgreSQL pgcrypto, MySQL AES_ENCRYPT |
| Client-side field-level encryption | Database driver encrypts before sending | MongoDB CSFLE, SQL Server Always Encrypted |
AES-256-GCM: The 2026 Standard
AES-256-GCM is the correct choice for database field encryption in 2026. The GCM (Galois/Counter Mode) variant provides authenticated encryption — it simultaneously ensures data confidentiality and detects tampering. Earlier modes like AES-CBC do not provide this guarantee and have known vulnerabilities (Bioquro 2026).
Requirements for secure field-level encryption:
- AES-256-GCM (not ECB, not CBC)
- Unique nonce generated per encryption operation (never reused)
- Encryption keys stored in dedicated KMS (not in code, env vars, or Git)
- Separate keys for development, staging, and production
- Automatic key rotation (90-180 day schedule)
- Database backups encrypted with separate keys
The Query Limitation Tradeoff
Field-level encryption introduces a fundamental tradeoff: encrypted fields cannot be queried normally.
| Encryption mode | Query support | Security level |
|---|---|---|
| Deterministic (same plaintext → same ciphertext) | Equality queries only | Lower (pattern analysis possible) |
| Probabilistic (AES-GCM with random IV) | No server-side queries | Higher (recommended) |
| Blind indexing (HMAC of plaintext as separate column) | Equality queries on HMAC | Medium (separate searchable column) |
For AI knowledge bases, most sensitive fields (API keys, PII, PHI) do not need to be queried directly. Use probabilistic encryption for these fields. For fields that need equality searches (email addresses, employee IDs), use blind indexing alongside field-level encryption.
Why AI Knowledge Bases Need Both Layers
AI pipelines create a unique encryption challenge. Data flows through multiple stages:
At each stage, data is in memory — unprotected by volume-level encryption. The encryption gap in AI pipelines is structural:
| Pipeline stage | Data exposure | Volume-level protection | Field-level protection |
|---|---|---|---|
| Ingestion | Raw data read from source | None (in memory) | Protected (fields encrypted) |
| Transformation | Data processed, chunked | None (in memory) | Protected (fields encrypted) |
| Embedding | Text converted to vectors | None (in memory) | Protected (PII redacted before embedding) |
| Vector store | Embeddings stored | Protected (at rest) | Protected (sensitive fields encrypted) |
| RAG retrieval | Vectors queried, context assembled | None (in memory) | Protected (fields remain encrypted) |
| LLM response | Generated text returned | None (in memory) | Protected (decrypted at application layer) |
With volume-level encryption only, data is unprotected at every in-memory stage. With field-level encryption, sensitive fields remain encrypted throughout the pipeline until the application explicitly decrypts them for the final response (Utimaco 2026).
Comparison: Field-Level vs Volume-Level
| Factor | Volume-level (TDE/FDE) | Field-level (AES-256-GCM) |
|---|---|---|
| Threat addressed | Physical theft, disk access | Insider threats, DBA access |
| Performance overhead | Negligible (AES-NI) | Moderate (client-side computation) |
| Query capability | Full (transparent to queries) | Limited (no range/sort on encrypted fields) |
| Key management | Single key for database | Per-field or per-tenant keys |
| DBA can read data | Yes | No (only ciphertext visible) |
| Compliance | HIPAA, PCI DSS at-rest requirement | GDPR data protection by design, per-tenant isolation |
| Implementation complexity | Low (built-in DB feature) | High (application-layer changes) |
| AI pipeline protection | At rest only | Throughout pipeline |
Compliance Mapping
| Regulation | Requirement | Which layer satisfies it |
|---|---|---|
| HIPAA | Encryption of PHI at rest | Volume-level (TDE) |
| PCI DSS | Cardholder data encryption | Field-level (for PAN) + volume-level |
| GDPR Art. 25 | Data protection by design | Field-level (design-level control) |
| GDPR Art. 32 | Security of processing | Both layers (defense in depth) |
| SOC 2 | Logical access controls | Field-level (protects from DBA) |
| EU AI Act Art. 9 | Risk management | Both layers (risk mitigation) |
For tenant isolation, field-level encryption with per-tenant keys provides the strongest isolation — one tenant's key cannot decrypt another tenant's data even in a shared database.
FAQ
What is the difference between field-level and volume-level encryption?
Volume-level encryption (full-disk or TDE) encrypts the entire database at the storage layer. Field-level encryption encrypts specific sensitive columns at the application layer. Volume-level protects against physical theft; field-level protects against insider threats and compromised database credentials.
Which encryption should AI knowledge bases use?
Both. Volume-level encryption (TDE or full-disk) protects data at rest against physical theft. Field-level encryption protects sensitive fields (PII, PHI, API keys) even from database administrators. AI pipelines that ingest, transform, and recombine data need field-level encryption because the unprotected window in memory is structural, not incidental.
What encryption algorithm is recommended for field-level encryption in 2026?
AES-256-GCM is the industry standard. GCM provides authenticated encryption — it detects tampering. Earlier modes like AES-CBC are no longer recommended due to known vulnerabilities and lack of integrity verification.
Can you query encrypted fields in a database?
Deterministic encryption (same plaintext always produces same ciphertext) supports equality queries but not range queries. Probabilistic encryption (AES-GCM with random IV) is more secure but unsearchable. For searchable encrypted fields, use blind indexing (HMAC of plaintext as a separate column).
Does field-level encryption protect against database administrators?
Yes. With field-level encryption at the application layer, the database server only stores ciphertext. A DBA with full server access sees encrypted bytes, not plaintext. This is the only encryption layer that defends against insider threats with legitimate database access.
Want a self-hosted AI company brain that does all of this out of the box?
Book a demo →