Security

Last updated 21 August 2026

The one thing that matters most

Flowtiq is multi-tenant: your workspace and someone else's live in the same database. The question that matters more than any other is whether one can ever read the other, and the answer has to be structural rather than careful.

So isolation is not enforced by our application code remembering to filter by workspace. Every table carries a workspace id and Postgres row-level security policies enforce it inside the database. A query that forgets its filter returns nothing rather than returning someone else's rows. The mistake that leaks data in most multi-tenant applications, a missing WHERE clause, cannot leak data here.

We test this the awkward way. A rig replays every database migration into a throwaway Postgres, seeds two separate tenants, and then systematically tries to reach one tenant's data from the other, table by table. It also tries to escalate a member into an owner, and it runs a positive control so that a suite which passes because nothing is being tested gets caught. That suite runs against the real migration set, not against a description of it. Changes to isolation rules, sign-up, or invitations do not ship until it is clean.

Your connected accounts

Connecting Gmail or a social account hands us a credential that can act as you, so these get the most care.

  • Access and refresh tokens are encrypted with AES-256-GCM before they reach the database. The key lives only in server-side configuration, never in the browser bundle and never in the repository. Keys are versioned, so we can rotate the key without asking you to reconnect anything.
  • We ask for the narrowest scope that makes the feature work. Flowtiq reads and sends Gmail, but it does not take the broader modify permission, which is why marking a message read inside Flowtiq does not write that back to Gmail. That limitation is a deliberate trade for a smaller permission.
  • Starting a connection sets a short-lived, JavaScript-unreadable cookie that binds the attempt to your browser. Without it, someone could start a connection on their own account and send you the genuine provider consent link, so that your mailbox ended up attached to their workspace. Proving the callback came back to the same browser that began it is what closes that.
  • Disconnecting an account deletes the stored credential rather than merely hiding it.

Inside a workspace

Roles are enforced on the server, not in the interface. Hiding a button is a courtesy; the check that matters runs before the write.

  • Nobody can read a colleague's connected mailbox. Mail is scoped to the person whose account it came from.
  • The AI assistant only ever sees your own calendar, never a colleague's, and it withholds invoices from members who are not owners or admins. It would have been easier to let the assistant read everything; that would have made it a way around the permissions.
  • Security-relevant events are written to an append-only audit trail: who did what, to whom, and whether it worked. It cannot be edited or deleted from the application, because an audit log an attacker can edit is worse than none. Where an event involves email we record the recipient's domain only, never the address and never the message.

The application itself

  • Everything is served over HTTPS, with strict transport security, content-type sniffing disabled, framing denied, a restrictive referrer policy, and camera, microphone, geolocation and payment interfaces switched off at the browser level.
  • Passwords are hashed by Supabase Auth. We never see them and cannot recover them.
  • Privileged database credentials exist only in server-side code running in our Cloudflare worker. The browser holds nothing beyond your own session.
  • Brand analysis fetches a website you name, which is a request we make on your behalf, so it resolves the address first and refuses private and internal network ranges. Without that, the feature would be a way to make our servers probe networks they should not reach.
  • Data sent to the AI models is wrapped so that content out of your workspace is treated as data rather than as instructions, which limits what a malicious email or note can talk the assistant into doing.
  • When we log an AI request for debugging we record its shape and any error, never the content sent or returned.

What we do not claim

This section exists because a security page without one is marketing. None of the following are true yet, and we would rather you knew.

  • We are not SOC 2 certified, and we are not ISO 27001 certified. No audit is underway. If you need a certified vendor today, we are not one.
  • No independent penetration test has been carried out. The isolation testing described above is our own, and it is thorough about the thing it covers rather than a substitute for an outside look.
  • There is no bug bounty programme. Reports are very welcome anyway, and we will credit you if you would like.
  • Flowtiq is in beta and carries no uptime commitment. Google's production verification for Gmail access is still in progress.
  • There is no single-sign-on, and no enforced two-factor authentication for workspace members yet.

Reporting something

If you have found a vulnerability, email hello@flowtiq.ai with enough detail to reproduce it. We will confirm we have it within two business days and tell you what we are doing. Please do not test against a workspace that is not yours, and give us a reasonable chance to fix things before publishing.

Related documents

What we collect and who processes it is in the Privacy Policy. The terms on which we handle the personal data you import are in the Data Processing Agreement.