Skip to content

Zero egress

Flow’s headline security property is that all AI inference runs locally in the user’s host process, with no network access for AI models. No inference data leaves the workstation. This holds by construction, not by configuration: each model runs in a restricted worker with no network, no file system, no credential access, and no child processes, so zero egress is an inherent property of the runtime rather than a setting you switch on. It is one of the three properties of Flow’s architecture, Reasoning-Augmented Orchestration. See what is Flow.

Customers operate under data-residency, sovereignty, and audit constraints. Those constraints make cloud inference operationally expensive, because they require DPAs, third-party processor reviews, and data-flow audits. In some cases they disallow cloud inference outright. Two alternatives were rejected:

  1. Cloud inference. This option has a lower model-management cost, but it requires data egress, a cloud DPA per customer, and third-party inference audits. It also disqualifies the platform from regulated deployments.
  2. Hybrid (local for sensitive nodes, cloud for general assistance). This option multiplies the configuration surface and creates a “did this leak?” audit question for every node. It is operationally worse than either pure option.

The default posture:

  • Models execute on-device via a managed llama-server subprocess on a loopback API.
  • The Reasoning Domain has no network paths, no filesystem access, no environment-variable exposure, no credential access, and no child-process spawning capability.
  • Models are distributed via the Model Hub and downloaded on first use.
  • Telemetry and feedback are local by default. Export is opt-in and contains anonymized signal only. It never includes spool content or prompt text.

These trade-offs are accepted by design:

  • A hardware floor. Models must fit in user-machine memory within latency budgets. Graceful degradation mitigates this, because low-spec hardware skips AI nodes rather than blocking execution.
  • Update cadence. Model improvements ship through the application update channel rather than instantly through a service. This is acceptable with semver discipline and shadow-mode validation.
  • No cross-user learning. The platform does not learn from one user’s data on behalf of another.

“Zero-egress by default” has exactly two deliberate, opt-in exceptions. Both are off by default, both are gated by settings, and both are keyring-credentialed:

  1. Cloud AI providers. See cloud providers. The same PII sanitizer runs before every cloud call, and persisted output is metadata-only by default.
  2. Service-node APIs. These are external REST integrations described by catalog data. They are audited and gated by connection presence.

Enterprise deployments that mandate strict zero egress disable the settings by policy. The cloud surface then does not exist for those users.

Every planned shared service handles metadata only. The Model Hub distributes artifacts and metadata. The Governance Service processes flow-graph permissions. The Template Registry stores graph structure. None of them process inference data or spool content. Audit forwarding to a SIEM transmits execution metadata only.