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