Sapa

Security

What we do, and what we have not done yet

A security page is a set of commitments, so this one only carries what we can show you evidence for. Where the evidence does not exist yet, it says that instead — including in the places a buyer usually expects a logo.

In the meeting

Media encrypted in transit

Audio, video and screen use TLS between you and the relay. Everything else — the app, the API, the recordings — is TLS 1.3.

End-to-end encryption, and what it costs you

Available on every plan, and an organisation can require it. With it on there is no recording, no cloud transcript and no server-side preview — captions still run, on your own device.

Your media and your files are end to end encrypted. Who you met and when is not.

What it covers, and what it does not
DataCoveredBecause
Audio and video, including screen shareYesencrypted on your device before it is sent; our servers forward it and cannot open it
Files you share in chatYesencrypted on your device with the meeting’s key; we store and serve them without being able to read them
Live captionsYesproduced on your own device — the audio is never sent anywhere to be transcribed
Chat messages while the meeting is runningYesthe same encryption as your media
Chat history after the meetingNosaved history is readable by us, unless the room is set to keep none
Who was in the room, who spoke, and whenNoour servers route your media, so they can see the pattern of it even without its content
Names, roles, membership, attendance, policy and billingNothis is the account information the service runs on; encryption of your media was never a claim about it
Reactions, raised hands and presenceNothese are signals our servers forward, and their existence is visible either way
Recordings, transcripts and summariesNoa recording has to be readable to exist — so a meeting is either end-to-end encrypted or recorded, never both
Connection quality measurementsNoaggregate statistics about the connection, not about what was said

Nothing is recorded silently

Everyone is told before the first frame. Where affirmative consent is required, each person is asked and a refusal is recorded as such.

Live media is not stored

Relayed and gone unless a recording is running. No meeting content trains anything of ours, ever.

Identity, and who can get in

Company sign-in

Not built yet

Not built yet, and this page will say so until it is. When it arrives: SAML and OIDC through your own provider, and an organisation that requires it will refuse passwords and passkeys for its own people. Multi-factor will be yours to enforce; we will not weaken it or offer a bypass.

Unverified provider email

If a provider hands us an address it has not verified, we do not treat it as proof of identity — and we say why on the screen rather than implying the person did something wrong.

Shared machines

Every session is listed with its device, and one control ends all of them. When a session expires we drop what we remembered about the device and tell you we have.

Guests

Unauthenticated by design and never silently upgraded. A host admits them, and an attendee cannot reach the roster.

Policy, and how ties resolve

Group rank decides between groups; at equal rank the more restrictive value wins. Every resolution is visible in the console, with the reason it won.

Where the service runs

You choose the EU or the US, and the choice binds relay placement as well as storage — media does not leave the region to get to someone. Enterprise customers can run the relay on their own network, in which case their bytes never reach us at all. Region is a promise about where data sits; it is not a statement about which country’s law applies, and those are set out separately in the Privacy notice.