Security and trust

We list these first so nobody adopts flowss for a purpose it cannot carry yet.

• No SOC 2 or ISO 27001. We hold no third-party security certification, and no audit has been started.
• No penetration test yet. No outside firm has tested flowss. Our controls were designed and reviewed in-house and are covered by automated tests. There is no bug bounty.
• No service-level agreement. We make no uptime commitment and offer no service credits.
• No data processing agreement (DPA) on offer. We also make no HIPAA, FERPA or similar commitment. Do not put patient data, student records or anything a data agreement governs into flowss.
• No point-in-time recovery. We have not yet rehearsed restoring from a backup. Keep your own exports of anything you cannot afford to lose.
• No written breach-notification procedure yet. The steps and timings for telling people about a breach are not written down.
• One operator. flowss is run by one person at Voranox Inc. There is no 24-hour on-call cover.
• No claim about how stored data is encrypted. We have not yet checked for ourselves how our hosting providers encrypt the data they store, so we make no claim about it here.
• No single sign-on (SAML), Microsoft sign-in, SCIM provisioning or audit-log export to your own tools yet. There is also no choice of data region.
• Self-service account deletion is paused. You can export your data at any time. To delete your account, contact support.

• Encrypted connections. Every page and API call is served over HTTPS, with a one-year Strict-Transport-Security policy and a content security policy on our pages.
• Sign-in. You sign in with GitHub, Google or an email address and password. Passwords go to our sign-in provider, never to our own servers. Our forms ask for passwords of at least 8 characters, and a password that appears in a known data breach is refused. Sign-in and sign-up forms show a bot check.
• Two-step verification. Any account can turn on codes from an authenticator app. Once it is on, our servers refuse a session that skipped the second step.
• Admin tools require two-step verification. A time-limited emergency override exists, and every use of it is logged.
• Accounts are kept apart. Row-level security is on for every user-facing table, so a key that reaches a browser can read only its own account's rows and those of the projects, teams and classes the account has been added to. Our server code uses a privileged key and limits each query to the caller in code, which we review and test.
• Keys. AI provider keys you choose to save are encrypted with AES-256-GCM under a key held only in our server environment. API keys you create are stored only as SHA-256 hashes, so we cannot read them back.
• Where your data is. Our database and sign-in service run on Supabase in AWS us-west-2 (Oregon, United States). Our servers run on Vercel in the United States, and each request first reaches Vercel's nearest network location, which can be in another country. The other services that receive some of your data are listed on our subprocessors page, with what each one sees.
• Backups. Our database provider takes daily backups.
• Monitoring and limits. A security log records events such as failed sign-ins and refused requests, keeping a keyed hash and a masked form of each IP address, and alerts the operator. Our audit log of account events, such as sign-ins, plan changes and key changes, keeps the IP address of the request. Daily limits apply per network, account and API key.
• Updates and testing. Dependency updates are checked automatically every week, and an automated test suite runs on every proposed change.
• Reporting a vulnerability. Our security.txt file says how to report one: we acknowledge within three working days and assess within fourteen, and we will not take legal action against good-faith research.

• Subprocessors: every outside service that receives some of your data, and what it sees.
• Security overview: how sign-in, sharing and the browser protections work, in plain terms.
• Privacy policy and terms of service.
• Status: the configuration checks of this deployment and the page speed visitors measured.

If your organisation needs a security questionnaire answered, email hello@flowss.ai and we will answer in writing. Our answers to the Cloud Security Alliance questionnaire (CAIQ) are an internal draft, not a listing in the CSA STAR registry.

To report a security problem, email hello@flowss.ai.