Encryption at Rest + In Transit: CallSphere vs Vapi Defaults

TL;DR

Encryption is now table-stakes for any compliance posture: HIPAA Security Rule technical safeguards, SOC 2 CC6.7 and CC6.8, GDPR Art. 32, PCI-DSS 4.0. The defaults matter — auditors examine "what ships out of the box" because customer drift from defaults is a common audit finding. CallSphere ships with TLS 1.3 in transit, AES-256 at rest, KMS-backed keys, and per-tenant database isolation. Vapi.ai's encryption posture is the union of what each upstream vendor (STT, LLM, TTS, telephony) and the customer's own glue code happen to enable. This post shows the encryption layer model, where each platform fits, and what to ask in procurement.

Why Encryption Defaults Matter

Most security failures come from misconfiguration, not algorithm weakness. AES-256 has been NIST-approved for 25+ years; the breaches happen because:

• TLS 1.0/1.1 is left enabled on a legacy load balancer
• A debug bucket is created without server-side encryption
• A new microservice forgets to use the corporate KMS
• A vendor's "free tier" downgrades encryption silently

A platform with strong defaults removes most of these risks before a customer engineer can introduce them. A platform with per-component customer-configured encryption maximizes them.

Encryption Layers in a Voice AI System

A voice AI call has at least seven encryption-relevant layers:

1. Caller-to-carrier: SRTP / TLS — controlled by the carrier
2. Carrier-to-platform: SIP TLS — controlled by the platform
3. Platform-to-STT: HTTPS / WebSocket — controlled by the platform
4. STT-to-LLM: HTTPS — controlled by the platform
5. LLM-to-TTS: HTTPS — controlled by the platform
6. TTS-to-platform: HTTPS — controlled by the platform
7. Platform-to-storage: at-rest encryption (S3 SSE / RDS) — controlled by the platform

Plus admin / dashboard / API access (HTTPS), database connections (TLS), backup encryption, and key management.

CallSphere Defaults

Layer	Default
Caller→carrier (Twilio)	SRTP / SIP-TLS
Carrier→CallSphere	TLS 1.3
Internal service-to-service	TLS within K8s service mesh
LLM provider	TLS 1.3
Database connections	TLS 1.3 (Postgres SSL required)
Storage at rest	AES-256 (S3 SSE or RDS encryption)
Backup encryption	AES-256
Dashboard access	TLS 1.3 + JWT
Admin API	TLS 1.3 + JWT + RBAC
Key management	AWS KMS / equivalent regional KMS
Cipher suites	Modern only (no SHA-1, no RC4, no 3DES)

These are not toggles — they are the only enabled options.

Vapi DIY Posture

Vapi customers must verify encryption per layer per vendor, and may discover:

• TTS vendor offers HTTPS but no TLS 1.3 enforcement
• STT vendor allows plaintext on a low-latency path
• LLM vendor's enterprise tier defaults to TLS 1.2
• Vapi's own internal storage encryption is unclear without disclosure
• Customer's storage bucket may not have server-side encryption enabled by default

The customer's audit obligation is to verify and document each of these. Misses become findings.

Mermaid: Encryption Layers

graph TB
  CALLER[Caller Phone] -->|SRTP/SIP-TLS| TWILIO[Twilio Carrier]
  TWILIO -->|TLS 1.3| CSP[CallSphere Edge]
  CSP -->|mTLS| AGENT[Voice Agent Service]
  AGENT -->|TLS 1.3| STT[STT Provider]
  AGENT -->|TLS 1.3| LLM[LLM Provider]
  AGENT -->|TLS 1.3| TTS[TTS Provider]
  AGENT -->|SSL| DB[(Postgres TLS)]
  DB -. AES-256 SSE .- KMS[AWS KMS]
  AGENT -->|HTTPS+JWT| DASH[Dashboard]
  DASH -->|RBAC| OPS[Ops User]
  AGENT -. AES-256 .-> S3[(S3 Recordings)]
  S3 -. SSE-KMS .- KMS

Every edge in the diagram is encrypted, and the keys for at-rest data are KMS-managed.

Comparison Table

Encryption Capability	Vapi DIY	CallSphere
TLS 1.3 enforced everywhere	Per-vendor verify	Default
AES-256 at rest	Per-vendor verify	Default
Customer-managed keys (CMK)	Per-vendor	Available via KMS
Database TLS required	Customer-configured	Required
Backup encryption	Customer-configured	Default
Cipher hardening	Per-vendor	Default modern-only
Key rotation policy	Per-vendor	Documented
Cross-component mTLS	Build yourself	Available
FIPS 140-2 endpoints	Per-vendor	Available on request
Audit log encryption	Per-vendor	Default

Procurement-Friendly Encryption Checklist

1. Is TLS 1.3 enforced for all customer-facing endpoints?
2. Are TLS 1.0 and 1.1 explicitly disabled?
3. Is AES-256 the at-rest default for primary database, recordings, and backups?
4. Are customer-managed keys (CMK) supported via KMS?
5. What is the documented key rotation cadence?
6. Are administrative interfaces protected by mTLS or strong identity binding?
7. Are cipher suites restricted to a modern allowlist?
8. Are all sub-processor links encrypted with documented protocols?
9. Are there any plaintext debug paths in non-production?
10. Are encryption settings part of the SOC 2 / HIPAA scope?

Key Management Notes

CallSphere uses AWS KMS (and regional equivalents) for at-rest encryption keys. CMKs can be customer-owned for enterprise customers. Key access is logged via AWS CloudTrail, satisfying the "encryption logging" controls in SOC 2 and HIPAA.

In a Vapi-based stack, each upstream vendor brings its own key management. Reconciling these into a single audit narrative is non-trivial — and a misconfigured S3 bucket on the customer's side is a classic finding.

Real-World Audit Example

A 2025 SOC 2 audit of a healthcare technology company using a Vapi-style multi-vendor stack found:

• TTS vendor used TLS 1.2 by default; no enforcement of 1.3
• One internal microservice connected to Postgres without SSL during a rolling upgrade window
• Backup encryption was enabled but used a single KMS key shared across environments

Two findings led to qualified opinions. Remediation took 4 months. CallSphere's defaults would have prevented all three.

CTA

Encryption is the easiest control to get wrong by accident. Book a CallSphere demo and ask for our encryption-defaults summary. Or visit our pricing for plan tiers.

FAQ

Does CallSphere support customer-managed encryption keys?

Yes. Enterprise plans support CMK via AWS KMS, with documented key access auditing.

What about FIPS 140-2 validated cryptography?

FIPS 140-2 validated endpoints are available on request for federal and state government workloads.

Are recordings encrypted with the same key as transcripts?

By default they share a per-tenant master key, with separate data keys per object envelope-encrypted. Enterprise customers can use distinct CMKs per data class.

Is mTLS used between internal services?

Yes — internal service-to-service traffic in CallSphere's K8s mesh uses mTLS where supported, with strict cipher suites.

How often are TLS configurations re-tested?

CallSphere runs continuous TLS configuration scans (Mozilla Observatory / SSL Labs equivalents) on customer-facing endpoints, with results reviewed monthly.

Deep Dive: Cipher Suite Hardening

Modern TLS deployments benefit from explicit cipher suite restrictions, not just version restrictions. CallSphere's TLS termination points enforce:

TLS 1.3 cipher suites (allowed):

• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_GCM_SHA256

TLS 1.2 cipher suites (allowed for legacy carrier interop only):

• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-ECDSA-CHACHA20-POLY1305
• ECDHE-RSA-CHACHA20-POLY1305

Disabled across the board:

• All TLS 1.0 / 1.1 cipher suites
• All RSA key exchange (no PFS)
• All CBC mode ciphers
• All RC4, 3DES, MD5, SHA-1 hashes
• Export-grade ciphers

This list passes Mozilla's "Modern" recommendation as well as PCI-DSS 4.0 cipher requirements.

Key Rotation Cadence

Documented rotation cadence at CallSphere:

Key Type	Cadence	Method
TLS certificates	90 days	Automated via ACM / Let's Encrypt
Database encryption master key	Annual (or on personnel change)	KMS-managed
Application JWT signing key	Quarterly	Automated rollover with grace period
API keys (customer)	Customer-controlled	Self-service rotation
KMS data keys	Per-object envelope	AWS KMS-managed
SSH keys (operator access)	90 days	Centralized key management
Backup encryption keys	Annual	Managed alongside DB keys

At-Rest Encryption Layers

A single piece of customer data may be encrypted at multiple layers:

1. Application-layer field encryption for the most sensitive fields (e.g., insurance numbers) — encrypted before insert
2. Database-level transparent encryption (RDS encryption-at-rest)
3. EBS volume encryption (cluster storage)
4. S3 server-side encryption for objects (SSE-KMS)
5. Backup encryption at the snapshot level

The layered design means a single layer compromise does not expose plaintext.

Quantum-Resistant Cryptography Roadmap

NIST published the first post-quantum cryptography standards in 2024, and major TLS implementations are adding hybrid PQC support. CallSphere's roadmap includes:

• 2026: Hybrid X25519 + Kyber-768 key exchange evaluation in test environments
• 2027: Production rollout of hybrid PQC for TLS 1.3 ingress
• 2028+: Migration of long-lived data encryption keys to PQC algorithms

Vapi-based stacks will require each upstream vendor to migrate independently, with no coordination guarantee.

Encryption in Use (Confidential Computing)

For customers requiring "encryption in use" (data encrypted while being processed), CallSphere is evaluating AWS Nitro Enclaves and confidential compute options for the most sensitive workflows. This goes beyond standard encryption-at-rest and in-transit and is typically required only by very high-sensitivity customers (federal, financial, or biotech).

Customer-Facing Encryption Documentation

CallSphere publishes an encryption posture document covering:

• Algorithm choices and rationale
• Cipher suite allowlist
• Key management architecture
• Rotation cadences
• Incident response for key compromise
• Customer-managed key options
• Migration plans for deprecated algorithms

This document is updated quarterly and is included in the trust portal.

Real-World Defense

In a 2025 supply chain incident (industry-wide, not CallSphere-specific), a vulnerability in a popular TLS termination component allowed downgrade attacks on older deployments. CallSphere customers were unaffected because:

• TLS 1.2 was not the floor (1.3 was the default)
• Cipher allowlists prevented downgrade to vulnerable suites
• Centralized rotation closed the window quickly

Customers running multi-vendor stacks reported much longer remediation timelines because each vendor had to be patched independently.