Encryption
Encrypted in transit, at rest, and in use. Every byte, every boundary. Customer-managed keys on self-hosted; on managed deployments planned Q3–Q4 2026.
In transit
External connections
- TLS 1.3 exclusively on all ingress. TLS 1.2 disabled.
- HSTS with long max-age
- Certificate pinning on mobile clients
- HTTP Strict Transport Security (HSTS) preloaded on stellarbase.ai
- Perfect forward secrecy via ECDHE ciphers
Internal service mesh
- mTLS between every internal service
- Per-service certificates rotated automatically
- Service mesh (Istio / Linkerd) enforces encryption
- Zero plaintext traffic on internal network
Source-system connections
- Every connector uses provider-native TLS
- Credentials (OAuth tokens, API keys) stored encrypted
- IP allowlisting supported for sensitive sources
At rest
Primary data
- Postgres: AES-256-GCM transparent data encryption
- Object storage (S3 / MinIO): server-side encryption (SSE-KMS or SSE-S3)
- Vector index: encrypted at the filesystem layer
- Backups: encrypted with a separate key for cross-compromise defense
Per-tenant isolation
- Each tenant’s data is encrypted with a separate tenant-level key
- Compromise of one tenant’s key cannot decrypt another tenant’s data
- Key hierarchy: data key → tenant key → master key (KMS-protected)
Audit log
Audit log is encrypted at rest in append-only storage with separate keys. The chain of custody is cryptographically verifiable.
In use
“In use” means during processing, not just at rest and transit:
- Secrets wiped from memory after request completion
- GPU memory scrubbed between tenant requests
- Temporary files (if any) encrypted and deleted after use
- Logs scrubbed of secrets and PII via pattern matching + StellarGate
Key management
Managed deployments
Keys live in a managed KMS (AWS KMS / Google CKM / HashiCorp Vault depending on our data centre). HSM-backed. Quarterly key rotation per policy. Immutable audit trail on every key operation.
Self-hosted deployments
Bring your own KMS. Supported backends:
- HashiCorp Vault
- AWS KMS / Google CKM / Azure Key Vault (for cloud-deployed self-hosted)
- PKCS#11 HSMs (on-prem)
- Thales CipherTrust
- Gemalto SafeNet
You control rotation cadence, access policy, and emergency revocation.
Customer-managed keys (BYOK)
🛠 In active development — Q3–Q4 2026. Customer-managed keys (BYOK) on managed deployments are planned for Q3–Q4 2026; offered on enterprise plans.
For customers who need control over keys even on managed deployments, BYOK is available on enterprise plans. Your key wraps the tenant key; we never see your raw key material.
Key rotation
| Level | Default rotation |
|---|---|
| TLS certificates | 90 days (Let’s Encrypt) or per your CA |
| Service mesh certs | 24 hours |
| Data encryption keys | Quarterly |
| Master key | Annual |
| API keys / tokens | Customer-configured; we recommend quarterly |
Key revocation
🛠 Ready in Q4 2026. Single-credential revocation works today. Tenant-scope and full-system revocation runbooks are ready in Q4 2026.
Emergency key revocation is a documented runbook. Scope options:
- Single credential — one API key revoked, everything else unaffected
- Tenant — all encrypted-data access for one tenant blocked
- Full system — master key revoked, data unreadable until key restored (use only for confirmed breach)
Decryption audit
Every decryption operation is logged. Pattern analysis alerts on unusual access (after-hours, from unusual locations, at unusual volumes).
Cryptographic choices
We favor widely-deployed, well-audited primitives:
- AES-256-GCM for symmetric encryption
- RSA-4096 or ECDSA P-384 for asymmetric
- SHA-256 / SHA-3 for hashing
- Argon2id for password hashing (when applicable)
- TLS 1.3 with modern ciphersuites
No custom cryptography. No “novel” schemes. Nothing that hasn’t been public-reviewed for at least five years.