Flow
Trust

Security & Architecture

Last updated: September 30, 2026

Flow is in pre-release. This page describes intended architecture. SSO, the audit log, and Flow-Edge are part of the deployment offer (roadmap) — not capabilities marked live in the product today. For current status in writing: hello@theflow-ai.com.

Flow is built for organizations that cannot send raw sensitive data to a third-party model — legal, healthcare, finance, insurance, and government. This page describes how the system is designed, so your security team can evaluate it without a call.

1. Planned Deployment Models

The most important security decision is where processing happens. Flow is planned for two deployment models, per engagement — not as live product toggles today:

Masked Secure Cloud

Processing is designed for a managed environment, with personally identifiable and confidential fields masked before processing. That is the architecture; deployment status is closed in the project, not a live toggle today.

Flow-Edge (Fully Local) — roadmap

When policy requires that data not leave the network, this is the deployment path designed into the engagement — not a cloud configuration with a flag, and not a live product toggle today.

If your obligations make cloud processing untenable — export-controlled manufacturing data, NERC CIP-scoped operational systems, classified or CUI-adjacent government work — Flow-Edge (roadmap) is the deployment path designed into the engagement, not a configuration flag on a cloud product.

2. Data Masking

In the masked-cloud model, sensitive fields are designed to be identified and replaced with structure-preserving placeholders before processing. The model is designed to operate on the masked representation, with the mapping back to real values staying under your control, so a prompt, a log, or a model provider is not meant to receive the underlying identifier. Deployment status is closed in the engagement — not a live product toggle today.

Masking is a mitigation, not a substitute for architecture. Where the requirement is "this data must not leave the building," the deployment path designed into the engagement is Flow-Edge (roadmap). We will say that directly rather than offer a cloud deployment with extra controls as if it were the same thing.

3. Zero-Retention Processing

Flow is designed so that content processed through the engine is not retained for model training and is not persisted beyond the life of the task that required it. "Zero-retention" is a claim worth verifying with any vendor — including us. We wrote a guide on how to verify a vendor's zero-retention claim, and we expect you to apply it to Flow.

4. Audit Logging & Provenance

Immutable audit trail — roadmap. For regulated deployments, an append-only log is planned: what was observed, what was proposed, who approved it, and what was executed. This is not a live product toggle today; it is closed in the engagement and the deployment. When it ships with a regulated rollout, the purpose is defensibility — when a regulator, auditor, or opposing counsel asks why a system did something eighteen months ago, the answer must be reconstructible from records rather than from memory.

Related reading: Auditability by Design and Tracing a workflow decision back to its source.

5. Human Approval Gates

High-risk actions require explicit human approval before execution. The engine surfaces the proposed action with its supporting context; a person accepts or rejects it. Autonomy is bounded by policy you define, not by the model's confidence in itself.

6. Deterministic Execution

Workflow execution runs under a strict runtime rather than free-form model output. The distinction matters for regulated use: a system that "usually" files the document correctly is not deployable in an environment where the failure mode is a reportable incident.

7. Transport & Application Security

  • Transport. All traffic to theflow-ai.com and to Flow services is served over HTTPS with HSTS enforced.
  • Browser hardening. The site is served with a strict Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, and a restrictive Permissions-Policy.
  • Waitlist data. Signups are confirmed by email double opt-in, so an address cannot be added by someone who does not control it.

8. Threat Model

We treat prompt injection and data exfiltration through model outputs as first-class threats rather than edge cases, because an automation engine with real system access has a materially larger blast radius than a chat interface. Our analysis is public: Prompt Injection and Data Exfiltration: Threat Modeling AI Workflow Automation.

9. Compliance Posture

Flow is currently in pre-release. The architecture above is designed to support deployment under HIPAA, GDPR, SOC 2, and sector-specific frameworks including 21 CFR Part 11, NERC CIP, CJIS, and FedRAMP-aligned government requirements.

If you are running a formal vendor assessment, contact us at hello@theflow-ai.com for the current status of individual certifications and audit reports, along with the deployment model that fits your control environment. We would rather give you an accurate answer in writing than have you infer a certification status from a badge.

10. Reporting a Vulnerability

If you believe you have found a security issue in Flow or in this site, email hello@theflow-ai.com with the subject line "Security vulnerability report". Please include enough detail to reproduce the issue. We will acknowledge your report and will not pursue action against good-faith research that avoids privacy violations, service disruption, and data destruction.

Evaluating Flow for a regulated environment?

Tell us which framework applies to you and we will lead with the relevant architecture detail.

Do It