Security and Trust

An honest account of how FlowState is built and secured, what has been verified, and what has not. Written for clients, their counsel, and anyone evaluating the platform. It does not overclaim.

Our approach

FlowState is built as defensive secure-development work, reviewed against the OWASP Top 10 and the NIST SP 800-218A Secure Software Development Framework, with routine dependency auditing. Security is a standing system, not a one-time pass. Every application is held against a fifteen-layer production-readiness model covering secret handling, API authorization, database row-level security, authentication, hosting separation, dependency supply chain, AI-endpoint cost and abuse control, observability, and recovery. Each audit is recorded with a date, a verdict, and a finding-by-finding trail, so the posture is measurable over time rather than asserted.

What we have verified

• ✓ Access control is enforced at the database, not only in application code. Sensitive tables deny by default, so an application bug does not by itself expose records. Data is isolated per organization where the application serves more than one.
• ✓ Privileged actions verify identity on the server with a signed session. Administrative credentials are required values with no fallback.
• ✓ No API key, database credential, or signing secret ships in the browser. This was verified by scanning the deployed code of the live sites.
• ✓ Endpoints that call paid AI models enforce request limits, usage logging, and a kill switch, so an unauthenticated actor cannot drive unbounded cost.
• ✓ Reflective and assessment tools that serve individuals are anonymous by design at the database layer, with identifying fields optional and any email stored only as a one-way hash.
• ✓ For applications holding family or childcare records, deletion honors the retention obligations that licensing and records law impose.
• ✓ Every fix is recorded with the date and the change and re-verified against the live application.

What we have not done

Stated plainly so no one relies on a protection that does not exist.

• ○ No third-party penetration test. The internal methodology brings an application to a state where such a test has far less to find, but it is not a substitute for one. We commission a penetration test when a client contract or data agreement requires it.
• ○ No SOC 2 or equivalent certification. We make no compliance-certification claim. The tracked audit record is the evidence base if a certification process is later commissioned.
• ○ Privacy, terms, and retention language is prepared from our actual data handling but has not yet been reviewed by qualified counsel. That review is completed before any client contract depends on it.
• ○ A staging-and-preview workflow, so changes are validated before they reach live users, is being installed application by application.

Data handling and subprocessors

FlowState runs on a small, named set of providers: Vercel hosts the deployments, Supabase provides the database, authentication, and file storage, and Anthropic provides the AI models. Where content is sent to an AI model, it is reviewed and personal identifiers are excluded or pseudonymized before the call. For education and childcare applications, the controlling agreement is the district or family relationship, and the application implements the data owner's retention and access rules rather than inventing its own.

In one sentence: FlowState is built and reviewed to a documented secure-development standard, its core controls are verified and recorded, and the points where formal validation has not yet been done are named here rather than implied to exist.

This overview reflects the platform state on the date above and is updated as the security posture changes. The detailed audit record is available under a confidentiality agreement.