Security you can actually verify
Exactly what each part of Ollasync protects, and how — written to survive a buyer’s security review.
Protection, data type by data type
Live meeting video & audio
Every call travels over an encrypted transport. End-to-end encryption protects the media per frame under a key generated in your browser — the server relays ciphertext it cannot read.
In-meeting chat, DMs & files
When a meeting is end-to-end encrypted, chat, 1:1 direct messages and shared files are encrypted in your browser with AES-GCM under a key that never reaches our servers — we store only ciphertext. In a standard meeting they’re encrypted in transit but server-readable.
Deal-room documents
Uploaded over TLS, stored encrypted at rest, and gated by role and NDA with short-lived signed access links, per-viewer watermarks on view-only files and an access trail on every document.
Recordings
When enabled, recordings are written to private storage in your workspace and restricted to authorised viewers via short-lived links. Recording decodes media server-side, so end-to-end-encrypted meetings are excluded by design.
What the server can — and can’t — see
For an end-to-end-encrypted meeting the claim is precise: we can’t read it. Routing metadata still has to move. Here’s the split.
Can’t see (E2EE meeting)
- The video, chat and messages of a meeting you end-to-end encrypt (AES-GCM, ciphertext only)
- The encryption key for an E2EE meeting — it stays in your browser (in the invite link); we keep only a hash of it
- A recording or transcript of an E2EE meeting — those can’t be produced without the key
Necessarily sees
- Meeting metadata: who is connected, when, the room identifier, timing
- The media of a standard (non-E2EE) meeting — encrypted in transit, but readable server-side
- Documents and recordings you choose to store with us — encrypted at rest, access-controlled
Who gets in, and to what
Strong identity
Sign-in with email + password, magic-link, TOTP two-factor and passkeys (WebAuthn/FIDO2). OIDC single sign-on to your own IdP — Okta, Entra ID, Google Workspace and more.
Rooms default-closed
A guest needs an invite or the meeting id, and the host admits them from a waiting room before anything flows. Room tokens are short-lived and scoped to a single room with a role.
Role & NDA gating
Deal roles govern who sees which folders. A deal can require NDA acceptance before any document can be downloaded — audited, and the admin is notified.
View-only (deterrence)
View-only documents render in-browser with a per-viewer watermark and no download. We call this what it is: deterrence against casual leakage, not DRM.
What every meeting gets
Encryption and access control built into the platform — not bolted on per plan.
End-to-end encrypted meetings
Video, chat and screen share are encrypted in the browser, under a key held by the participants. The service stores ciphertext it cannot read.
Encrypted transit on every meeting
All meeting media travels over an encrypted transport, with per-session keys negotiated for the call.
Confidential deal rooms
Role-based access, NDA gating, per-viewer watermarks on view-only documents and a full access trail on every file.
Private hosting with a DPA
Meetings, recordings and documents live on our hosted service under a data-processing agreement, in private storage.
How a reviewer can check the claims
The guarantees above are backed by how the system is built and by automated checks against the live stack.
The key stays with you
When you turn on end-to-end encryption, the meeting key is generated in your browser and rides only in the invite-link fragment — it never reaches our servers, which store only a SHA-256 hash of it.
Tenant isolation
An automated test asserts one organisation cannot read or even list another organisation’s data.
Nightly end-to-end suites
Identity, deal-room, cross-org access and the full in-call feature set run every night against the live stack, with results reported on failure.
Contract conformance
Every API route is checked against its documented contract on every build.
Building a compliance programme on this? See our compliance posture and request the security whitepaper and DPA.
Security questions
How is my meeting encrypted?
Every meeting is encrypted in transit. End-to-end encryption protects media, chat and messages in your browser with AES-GCM under a key we never receive — we store only ciphertext and a hash of the key.
How is meeting video protected?
Every call is encrypted in transit, and end-to-end encryption protects the media per frame under a key held only in the participants’ browsers.
Do you hold any of my keys?
For an end-to-end-encrypted meeting, no — the key is generated on your device and rides in the invite link; we keep only a hash of it. For a standard meeting, transport keys are negotiated per WebRTC session as normal.
Does the AI ever see my private meetings?
No. AI runs on the recordings you choose, and end-to-end-encrypted meetings are excluded — they hold no server-readable content to process.
What controls does a compliance programme get?
Encryption in transit with end-to-end encryption available, role-based access control, audit logging and a DPA.
Can a court compel you to hand over meeting content?
For an end-to-end-encrypted meeting we hold no key and store only ciphertext, so there is no readable content for us to produce — only routing metadata. For a standard meeting, media is in encrypted transit but not end-to-end encrypted.
Put it through your security review.
We wrote our security model to be defensible line by line. Request the whitepaper and DPA, or bring your questions to a call.