> ## Documentation Index
> Fetch the complete documentation index at: https://docs.svantic.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Encryption

# Data Encryption

Svantic encrypts data at every layer — in transit, at rest on disk, and at the column level for sensitive fields. Encryption is always on and cannot be disabled.

***

## Encryption in Transit

All communication between components uses TLS 1.2+ (HTTPS/WSS):

* **Client → Svantic API** — HTTPS with TLS termination at the edge
* **Agent → Mesh (WebSocket)** — WSS (TLS-encrypted WebSocket)
* **Mesh → Agent (Hosted mode)** — HTTPS POST to the agent's public URL
* **Internal service-to-service** — TLS within the cluster

Certificate validation is enforced on all connections. The SDK rejects connections to endpoints with invalid or expired certificates.

***

## Encryption at Rest

### Disk Encryption

All persistent storage is encrypted at the disk level:

* **Database volumes** — AES-256 encrypted using the cloud provider's managed encryption (AWS EBS encryption, GCP Persistent Disk encryption, Azure Disk Encryption)
* **Knowledge store** — vector embeddings and card data are stored on encrypted volumes
* **Logs and telemetry** — written to encrypted storage; no sensitive data appears in log content by design

Disk encryption keys are managed by the cloud provider's KMS (Key Management Service) and rotated automatically.

### File-Level Encryption

Temporary files created during task execution (uploaded documents, intermediate processing artifacts) are encrypted individually. Files are deleted after the session completes — they do not persist beyond the task lifecycle.

***

## Column-Level Encryption

Sensitive fields are encrypted at the application layer before being written to the database. This provides an additional layer of protection beyond disk encryption — even direct database access does not expose plaintext values.

### What Gets Column-Level Encryption

| Data                                                               | Encryption  | Key Scope   |
| ------------------------------------------------------------------ | ----------- | ----------- |
| **API secrets** (client secrets)                                   | AES-256-GCM | Per-account |
| **Webhook signing keys**                                           | AES-256-GCM | Per-account |
| **OAuth tokens** (integration credentials)                         | AES-256-GCM | Per-account |
| **Session context** (when containing user-provided sensitive data) | AES-256-GCM | Per-account |

### How It Works

1. Each account has a unique data encryption key (DEK)
2. The DEK is itself encrypted by a master key (KEK) stored in the cloud KMS
3. When writing a sensitive field, the service decrypts the DEK, encrypts the field value with AES-256-GCM, and stores the ciphertext + IV
4. When reading, the process reverses — the DEK is decrypted from KMS, then used to decrypt the field
5. The plaintext DEK is held in memory only for the duration of the operation

This envelope encryption model means:

* Database backups contain only ciphertext
* A compromised database dump reveals nothing without KMS access
* Key rotation happens at the KEK level without re-encrypting every row

***

## Key Management

| Key                            | Storage                                             | Rotation                                                   |
| ------------------------------ | --------------------------------------------------- | ---------------------------------------------------------- |
| **Master key (KEK)**           | Cloud KMS (AWS KMS, GCP Cloud KMS, Azure Key Vault) | Automatic, per cloud provider policy                       |
| **Data encryption keys (DEK)** | Database, encrypted by KEK                          | On-demand or periodic                                      |
| **TLS certificates**           | Edge / load balancer                                | Automatic via ACME (Let's Encrypt) or managed certificates |
| **JWT signing keys**           | In-memory, derived from master                      | Rotated with deployments                                   |

***

## What Svantic Never Stores

Regardless of encryption, certain data is never persisted by Svantic at all:

* **Credential values** — handled via [zero-knowledge credentials](/security/credentials); never transmitted or stored
* **Raw data from your systems** — capabilities execute on your infrastructure; Svantic sees only the results you return
* **File contents after session close** — temporary files are deleted when the session ends