Security
The strongest security property a meeting recorder can have is not holding the recording. That is the design here, and everything below follows from it.
What the design guarantees.
Audio is never uploaded.
Transcription and speaker separation run as WebAssembly and WebGPU inside your browser (packages/asr). There is no upload endpoint for audio in this product — not a disabled one, not an optional one.
Your library lives on your device.
Meetings are stored in your browser's IndexedDB (packages/core/src/browser/library.ts). On the free plan they are never sent anywhere.
Voice prints never leave the device that heard the voice.
They are stored separately from meetings and are excluded from sync. A voice print identifies a person even after the transcript is deleted, so it is treated as the most sensitive thing the product holds.
On the paid plan, only what you choose to sync is synced.
Synced meetings are rows in a Postgres database behind row-level security (supabase/migrations/0002_rls.sql). Policies are written so a query returns your rows, or rows shared into your workspace, and nothing else.
An agent reading your meetings reads them as you.
An access token resolves to a short-lived session for its owner, so the same row-level security applies (packages/mcp/src/auth.ts). The endpoint holds no standing privileges of its own.
We do not train anything on your meetings.
There is no training pipeline in this product. The speech, speaker and summarisation models are pre-trained and read-only; the summariser on the free plan is a deterministic function over your transcript, not a model call.
Row-level security, not application checks
Every table in the synced database has row-level security enabled and explicit policies. Requests run as an authenticated user, never as a service role, so the database itself decides what comes back. A missing .eq()in application code cannot leak another workspace’s meetings, because the query would return nothing.
This applies to agent access too. An access token is exchanged for a short-lived session belonging to its owner; the endpoint has no privileges of its own. An agent can read exactly what you can read.
Access tokens
A token is 256 bits of randomness. Only its SHA-256 is stored, so the plaintext is shown once and cannot be recovered — if you lose it, you generate another and revoke the old one. Revocation is immediate. An unknown token and a revoked token get the same error, so the endpoint does not confirm that a token was once real.
What we do not have
Publishing this list is more useful than publishing a badge:
- No SOC 2 or ISO 27001. We have not been audited. If your procurement process requires it, we cannot pass it today.
- No SSO, SAML or SCIM. Sign-in is email and password.
- No admin audit log. Access tokens record when they were last used, and that is the extent of it.
- No bug bounty programme. We will thank you properly and credit you, but we cannot pay.
- No penetration test report. None has been commissioned.
None of that makes the on-device design less true. It does mean that if your risk process depends on certifications, we are not there yet, and we would rather you knew before a procurement call than during one.
Reporting a vulnerability
with enough detail to reproduce it. We will acknowledge within three working days and tell you what we are doing. Please do not open a public issue for anything exploitable until there is a fix.
The source is public, so you are welcome to look. Testing against your own data and your own deployment is fine; testing against other people’s is not.
Also worth reading
The privacy notice covers what is collected, and the agent access page covers what a connected AI tool can and cannot see.