Encryption for recorded sessions: what we do and what we cannot promise

When someone asks "how do you protect my data?", there are two types of answers we can give. The marketing answer: "we use end-to-end encryption and your data is completely secure." The honest answer: "we use robust encryption, but there are structural limitations in any AI-assisted system that you should understand."

This is the honest answer.

What we do

In-transit encryption with TLS 1.3. All communication between your browser, the bot, and our servers travels encrypted with TLS 1.3 — the most modern and secure standard available. This means that if someone intercepts network traffic, they cannot read what is being transmitted.

At-rest encryption with AES-256. Session audio, transcriptions, and reports are stored encrypted at rest using AES-256. The encryption key is not stored alongside the data.

Short retention by default. Audio recordings are automatically deleted after the transcription is generated. Transcriptions and reports are retained by default for 90 days — not indefinitely. At the end of that period, data is archived in encrypted format or deleted according to user preference.

Right to immediate deletion. If a professional wants to delete all their data, they can. It is not a process that takes weeks and requires writing to a support team — it is a button in settings that executes permanent deletion.

Access audit logs. Every time someone on our team accesses session data — for technical support reasons, for example — it is logged with a timestamp and reason. The professional can request that log.

Role-based access control. In teams with shared workspace, only members with explicit permissions can see other members' sessions. The account owner controls who has access to what.

What we cannot promise

Here is the part most security products prefer not to mention.

We cannot offer zero-knowledge. Zero-knowledge means that not even we can read your data — because it is encrypted with a key only you hold. It is the highest standard of privacy.

The problem is structural: CauceOS is an AI assistance system. The language model needs to read the text of the transcription to generate suggestions, alerts, and reports. If data were encrypted with a key only the professional holds, the system could not process it.

This is not a limitation specific to CauceOS. It is a limitation of any system that uses AI to analyze content. Tools like Otter, Fathom, or any automated notes system have the same structural limitation.

We cannot guarantee a breach is impossible. No system connected to the internet can make that promise. What we can promise is that we follow industry best practices to reduce the probability and impact of a breach, and that we have an incident response protocol that includes notification to those affected.

We are not a HIPAA-certified solution. If your practice requires strict HIPAA compliance — you process PHI from patients in a clinical context in the United States — CauceOS is not the right tool at this time. We are working toward that certification, but claiming it prematurely would be dishonest.

Why we are explicit about this

We have seen clinical assistance products that promise "end-to-end encryption" without explaining that the AI model needs to read the content to function. That is, at best, imprecise.

Professionals who work with sensitive information deserve to understand exactly what protection they have and where the limits are. Only with that information can they make informed decisions about which tools to use in which contexts.

We built CauceOS to be worthy of the trust of those professionals. That starts with being honest about what we can and cannot promise.

---

Do you have specific security questions we did not cover here? Write to us at security@cauceos.com. We respond directly.