StellarBase
Docs Security & Compliance Encryption
Security & Compliance

Encryption

Encrypted in transit, at rest, and in use. Every byte, every boundary. Customer-managed keys on self-hosted deployments.

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 automatic rotation. 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)

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

🛠 Ready in Q4 2026. TLS and service-mesh certificate rotation are live today. Automated rotation of data encryption keys and the master key on the cadence below is ready in Q4 2026.

LevelDefault rotation
TLS certificates90 days (Let’s Encrypt) or per your CA
Service mesh certs24 hours
Data encryption keysQuarterly
Master keyAnnual
API keys / tokensCustomer-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.

Related