How we protect your meetings

Workspace isolation, enforced by the database

The usual way multi-tenant applications leak is that a query somewhere forgot its WHERE tenant_id = ?. We do not rely on remembering.

Every table holding customer data has PostgreSQL Row-Level Security enabled and forced. Application queries run inside a transaction as a dedicated database role that has no privilege to bypass those policies, with the identity of the person asking attached to the transaction. A query that forgets to filter returns nothing rather than returning somebody else's meeting, because the database refuses it rather than the code declining to ask.

This is verified rather than assumed. An automated check creates two workspaces and proves that every read and write across the boundary is actually refused. It runs against the real database, and it fails the build if any table is missing a policy.

Encryption

• In transit: TLS everywhere, with HSTS so a browser will not fall back to plain HTTP.
• At rest: the database and file storage are both encrypted at rest by the platform.
• Recordings: stored in a private bucket with no public URL. Playback goes through short-lived signed links issued only after a membership check.
• Third-party credentials: the Slack, Asana, Trello and ClickUp tokens a workspace connects are encrypted individually with AES-256-GCM under a key held outside the database, so a database compromise alone does not yield working tokens.
• Passwords: bcrypt, cost 12. Reset tokens are stored only as a SHA-256 hash, so a stolen backup contains no usable reset links.

Access control

Four roles inside a workspace: owner, admin, member and viewer. Billing is visible only to the owner. Integration credentials are visible only to owners and admins, and are masked even for them.

Platform administration is a completely separate boundary from any workspace role. A workspace owner has no path to it, nobody can grant it to themselves through the application, and a database trigger stops the attempt. Every administrative action is written to an audit log with the actor, the target and what changed.

Share links

A workspace owner or admin can publish a single meeting to a link that anyone holding it can open without signing in. It is off by default on every meeting, and it is the only way content leaves a workspace without an account.

The link carries 32 random bytes, so it cannot be guessed or enumerated. Publishing one meeting exposes nothing else: the shared page has no navigation into the workspace, no member list and no other meeting. The full transcript is a second, separate choice from sharing at all, and is excluded unless it is explicitly ticked. Shared pages are marked noindex so they do not enter search engines. A link can be given an expiry date, and revoking one takes effect immediately for everybody, including anyone who saved it. Every share, change and revocation is written to the audit log.

Abuse and integrity

• Every inbound webhook signature is verified before the payload is trusted: Recall.ai, Stripe and PayPal alike. An unsigned or tampered request is rejected, not processed.
• Sign-in, sign-up, password reset, invites and anything that starts a model call are rate limited.
• The password reset form gives the same answer whether or not an address has an account, so it cannot be used to find out who our customers are.
• The Slack webhook URL a workspace supplies is restricted to Slack's own host, so the field cannot be pointed at an internal address to make our servers fetch it.
• Text that reaches a browser or an inbox from a transcript or a language model is escaped on the way out, never inserted as markup.

What happens to your data

We do not train models on your meetings, and our processing providers are contractually barred from doing so. Nobody here reads your transcripts. Deleting a meeting removes the recording, transcript, summary and action items; backups age out within 30 days. The privacy policy has the full retention schedule and the list of subprocessors.

What we have not done

We would rather tell you this than let you assume otherwise:

• No SOC 2 or ISO 27001 certification. We have not been through either audit. If your procurement process requires one, we are not ready for you yet.
• No third-party penetration test yet. The controls above are real and tested by us, but nobody external has tried to break them.
• No SSO or SCIM. Google sign-in and email, not SAML.
• No contractual uptime commitment. See the terms.

These are on the roadmap in roughly that order.

Reporting a vulnerability

If you find something, tell us at security@notepik.com and give us a reasonable window to fix it before publishing. We will acknowledge within two working days and keep you updated until it is closed.

We do not currently run a paid bounty programme, and we will not threaten anyone who reports a genuine issue in good faith.