Encrypting AI Call Audio at Rest and in Transit: HIPAA in Practice

Voice recordings, transcripts, and embeddings are PHI. Treat them like the medical chart they are — not like a marketing call recording.

What the rule says

flowchart LR
  Patient["Patient call/chat"] -- "TLS 1.3" --> Edge["Cloudflare WAF"]
  Edge --> App["CallSphere App<br/>HIPAA + SOC 2 aligned"]
  App -- "encrypted" --> AI["AI Voice Agent"]
  AI -- "tool_call · audit" --> Audit[("Audit log<br/>§164.312")]
  AI --> EHR[("EHR · BAA-signed")]
  EHR --> AI
  AI --> Patient

The HIPAA Security Rule's encryption specifications live at 45 CFR 164.312(a)(2)(iv) for at-rest encryption and 45 CFR 164.312(e)(2)(ii) for transmission security. Both are currently "addressable," which means a covered entity must either implement encryption or document a reasoned alternative. The 2024 Notice of Proposed Rulemaking eliminates the addressable distinction and would make encryption mandatory at rest and in transit, with limited exceptions. HHS breach guidance points to NIST SP 800-111 (at rest) and NIST SP 800-52 (in transit) plus FIPS 140-validated cryptographic modules as the recognized standards.

What it means for AI voice/chat agents

A modern AI voice agent generates four classes of ePHI artifacts in every call: the live audio stream, the recording at rest, the transcript, and any vector embeddings used for retrieval. Each must be encrypted independently and with current cryptography.

For data in transit, the standard pattern is TLS 1.3, with TLS 1.2 acceptable as a fallback only with strong cipher suites. WebRTC media legs should run SRTP with DTLS-SRTP key exchange. SIP trunking should run over TLS, not plaintext. Internal service-to-service traffic should run mTLS — the AI voice control plane should not trust any internal hop with cleartext PHI.

For data at rest, AES-256 in GCM or XTS mode, with keys generated and managed in a FIPS 140-validated HSM or cloud KMS, is the table-stakes pattern. Transcripts and embeddings should sit in encrypted databases or object stores. The encryption keys must be rotated on a documented schedule and revocable. The often-missed step is encrypting backups and log files — HIPAA enforcement actions regularly cite unencrypted backup tapes and unencrypted SIEM dumps.

The HHS breach safe harbor under the Breach Notification Rule (45 CFR 164.402) treats encrypted ePHI as not a breach when the encryption keys remain protected. That single fact converts encryption from a checkbox into one of the highest-leverage investments a healthcare buyer can make.

CallSphere implementation

CallSphere encrypts every PHI artifact with AES-256-GCM at rest and TLS 1.3 in transit. Voice media runs SRTP with DTLS key exchange end to end. Our healthcare_voice PostgreSQL database is encrypted at rest with FIPS 140-validated KMS keys; backups are encrypted with separate keys; log files are encrypted before they reach our SIEM. Embeddings used by the Healthcare Voice Agent for retrieval are stored in a per-tenant encrypted vector store. Keys rotate every 90 days for data-encryption keys and annually for key-encryption keys, all via the cloud HSM. JWT auth tokens are signed with rotating asymmetric keys with a 1-hour expiry. We are HIPAA + SOC 2 aligned across 115+ database tables and 6 verticals, and the encryption posture is the same on every tenant — there is no "premium tier" for taking PHI seriously. See /about for our security posture overview.

Build/audit checklist

1. Run TLS 1.3 on every public endpoint and internal service-to-service hop that may carry PHI.
2. Run SRTP with DTLS-SRTP for all WebRTC media; run SIP over TLS for SIP trunks.
3. Encrypt every database, object store, and backup with AES-256 in GCM or XTS mode.
4. Use a FIPS 140-validated HSM or cloud KMS to generate, store, and rotate keys.
5. Rotate data-encryption keys at most every 90 days and key-encryption keys annually.
6. Encrypt log files and SIEM exports — auditors check this on every breach.
7. Document the encryption posture in your Security Risk Analysis to claim breach safe harbor.
8. Run an external penetration test annually that covers both control plane and media plane.
9. Confirm encryption keys live in your tenant or in a vendor HSM under your BAA — never in the same trust boundary as the encrypted data.

FAQ

Is TLS 1.2 still acceptable? Yes, with strong cipher suites and forward secrecy, but TLS 1.3 is the 2026 expectation. The NPRM signals all-modern-TLS as the future baseline.

Does encryption give us breach safe harbor? Yes — under 45 CFR 164.402, ePHI that is encrypted using HHS-recognized methods and where the keys remain protected is not "unsecured PHI," and the breach notification rule does not trigger.

Where are CallSphere encryption keys stored? In a FIPS 140-validated cloud HSM under our downstream BAA with the cloud provider, isolated from the data they protect, with documented 90-day rotation.

What about the call recording itself? The live media is SRTP-encrypted on the wire; the recording at rest is AES-256-GCM encrypted in object storage with a per-tenant key.

Sources

• 45 CFR 164.312 Technical safeguards: https://www.ecfr.gov/current/title-45/section-164.312
• HHS Guidance on encryption and the breach safe harbor: https://www.hhs.gov/hipaa/for-professionals/breach-notification/guidance/index.html
• NIST SP 800-111 Storage encryption: https://csrc.nist.gov/publications/detail/sp/800-111/final
• NIST SP 800-52 Rev 2 TLS guidelines: https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/final