Secure, encrypted, and honest about the rest.
Noots holds your meetings, your mail and your plans, so this page lists the controls that are built and running — and then lists, in the same size type, the ones we do not have. Everything below was checked against the code before it was written down.
For a formal review, a DPA or a disclosure, write to security@cartexdata.com.
Who gets in, and what they can see.
Access control that is decided by the server on every request. The interface hiding a button is not a permission model, and none of the controls below depend on it.
SAML 2.0 single sign-on
We verify the assertion signature ourselves, against the certificate you gave us — the signature's own key material is ignored, claims are read only from the signed part of the document, SHA-1 and HMAC algorithms are refused, and a replayed assertion is rejected. Turn enforcement on and password sign-in stops working for your domain.
SCIM 2.0 provisioning
Joiners and leavers sync from your identity provider. The bearer token is stored only as a hash and can be revoked at any moment, and deactivating someone in your directory removes their membership and revokes their live sessions in the same pass.
Role-based access, filtered in SQL
Owner, admin, manager, member and viewer, plus custom roles — and a separate per-project standing layered on top. A project you may not see is removed by the database query rather than hidden by the interface, and the same predicate scopes the data export.
Sessions you can actually end
Session cookies are signed, httpOnly and same-site, with a 30-day ceiling and a six-hour idle timeout, backed by server-side rows. Sign out other devices is a real button, changing your password does it for you, and a SCIM deactivation does it for everything at once.
Two-factor codes
Time-based one-time codes on your account, enrolled only after a valid code proves the authenticator works, and required at password sign-in. When you sign in through Google, Microsoft or your own identity provider, that provider's multi-factor policy is the one that applies.
IP allowlisting
Restrict the workspace to your own networks in CIDR notation. It is checked in the request pipeline in front of every application route, not by a page deciding whether to render.
Yours to take, and yours to delete.
A workspace you cannot leave is a workspace you cannot trust. Export and deletion are ordinary features here, not a support ticket.
- Deleted items go to a recoverable bin and are purged on the schedule your workspace sets, by a job that runs on its own.
- Delete a whole workspace, or your entire account — owner-confirmed, typed out in full, and it really removes the rows.
- Export your own data, or the whole organisation's, scoped to exactly what you are allowed to see. Each export is itself recorded.
- A redaction pass can scrub protected health information out of meeting text before anything is analysed or stored, for workspaces that install it.
Four companies, and we name all four.
- Deepgram
- Speech-to-text. Receives the audio of a meeting you record, and the short snippets behind live call notes.
- Recall.ai
- The bot that joins a Zoom, Teams, Meet or Webex call on your behalf and returns the recording and transcript.
- OpenAI
- The model behind summaries, Autopilot, Hoot and the AI features you switch on. It receives the text of what it is asked to work on.
- Stripe
- Subscription billing. It receives your payment details; we never see or store a card number.
The private content of your meetings and your workspace is not used to train general-purpose AI models, and our providers are contractually barred from using it to train theirs.
The parts nobody puts on a security page.
Most of what actually keeps a workspace safe is unglamorous and never advertised. Here it is anyway, because it is the part a reviewer will ask about.
Transport security
TLS on every connection, with HSTS preloaded for two years including subdomains, so a browser will not attempt plain HTTP in the first place. Content sniffing, framing and referrer leakage are all headed off at the edge.
Rate limiting
Sign-in, the API, inbound webhooks and public boards each get their own budget, applied before a request reaches a route. The client address is taken from the trusted end of the forwarded chain, so an attacker cannot mint a fresh bucket per attempt.
No blind outbound fetches
Every URL you hand us — a webhook target, a link in a chat message — is resolved and pinned before the request is made, private and metadata address ranges are refused, and the check is repeated on each redirect. Validating the first URL says nothing about where it sends you.
Signed outgoing webhooks
Every delivery carries an HMAC-SHA256 signature over the exact body, computed with your endpoint's own secret, so your receiver can prove the payload came from us and arrived unchanged.
Credentials never stored in the clear
Passwords are hashed with scrypt and a per-account salt. API tokens are stored as a hash and shown once. The tokens behind your mail, calendar and meeting connections are sealed with AES-256-GCM under a random per-record nonce.
A watchdog, and a lockdown
Abnormal traffic is recorded and administrators are alerted; if it keeps climbing the site can put itself into lockdown and recover on its own. Platform staff can also revoke every session in an organisation immediately.
Two different logs, and we keep them apart.
Conflating an activity feed with a tamper-evident record is how a compliance claim quietly becomes untrue. Noots has both and describes each as what it is.
The activity log — a record
Who did what, and when, across roughly a hundred and forty write paths — including every administrative change: single sign-on configuration, provisioning tokens created and revoked, residency changes. Visible in Org settings and included in the export. It is an ordinary table, and we will not call it immutable.
The compliance log — append-only, by the database
Workspaces that install the Compliance Audit Logger get a second, stricter record: the database itself raises an error on any attempt to update or delete a row, for every role including an owner. Export it as CSV or JSON at any time — and the export writes its own entry before it streams.
- A retention window per workspace decides how long deleted items stay recoverable before the purge job removes them for good.
- Meeting recordings, transcripts and analyses belong to the workspace and are removed with it.
- A data-residency preference is recorded per workspace and written to the audit log.
- Moving data already at rest to another region is a migration our team schedules with you — it is not a switch.
That last pair is stated the same way inside the product, on the screen where the preference is set. A control described differently in two places is a control nobody can rely on.
What we don't claim.
Every item here is something a competitor's security page would leave out. They are on ours because the controls above are only worth reading if this list exists.
What we don't claim
- No SOC 2, ISO 27001, HIPAA or FedRAMP attestation. We hold none of them and we will not imply one anywhere on this site. The controls above are real and you are welcome to assess them; the certificate is not something we can hand you.
- No published uptime SLA.
- Encryption of the database volumes themselves is our hosting provider's, and we have no attestation to give you for it. What we can point at in our own code is the AES-256-GCM envelope around every third-party credential we store, and TLS on every connection.
- Recording a meeting sends its audio to a third-party speech provider. That is what recording means here — there is no second consent step in front of it, so the decision is the one you make before you record.
- The AI that reads your mail is off until you switch it on, and so are live call notes; both are enforced on the server rather than by hiding a button. Not every AI feature has its own switch — summarising a meeting you chose to record does not.
- Two-factor codes are checked at password sign-in. Noots does not enforce two-factor across an organisation — require it at your identity provider, which is also what covers Google and Microsoft sign-in.
- The IP allowlist protects the application. API tokens are authenticated by the token itself and are not restricted by it.
- Data residency is a recorded policy, not regional storage. Nothing in the product routes your data to a region based on that setting.
- Three data permissions — product improvement, personalisation and partner sharing — are on by default and cover activity and diagnostic data, never the private content of your meetings or workspace. Each can be switched off individually, and on a paid plan an admin can switch them off for everyone.
- We are a young product and we would rather tell you that than let a page imply otherwise. If an item on this list is a blocker for you, say so and we will tell you honestly whether it is on the roadmap.