Isolation boundaries

Flow’s security model rests on hard isolation between four domains: User Interface, Host Process (orchestration), Execution (CLI and adapters), and Reasoning (AI). Compromise of any single domain does not grant access to the credentials or execution capability of the others.

The AI model isolation boundary

Local AI models run in a managed llama-server subprocess. Flow reaches it over a loopback OpenAI-compatible API that binds to localhost only, so there is no external egress. Flow does not pass credentials, environment maps, filesystem handles, or child-process handles to the model. It sends only the prompt text needed for inference. The architecture provides local AI models with:

No network paths.
No file-system access.
No environment-variable exposure.
No credential access.
No child-process spawning.

Data processed by local models does not leave the user’s machine.

System boundaries

Subsystem	Responsibility	Credential access?	Network access?
User Interface	Canvas, node palette, property editor	NO	NO
Host Process	Flow coordination, credential management, execution	YES (sole custodian)	YES (for CLI operations)
CLI tools	Job submission, downloads, dataset operations	YES (delegated)	YES (to target systems)
Shell adapter	Curated CLI tool nodes with capability-declarative sandboxing	INHERITED (env scrubbed by default)	Gated per node by `capabilities.net`
Reasoning Domain (local)	Loads models, runs local inference, returns JSON	NO	NO (zero network)
External AI (opt-in)	Cloud-AI calls	API key (keyring, env fallback)	YES (HTTPS to provider)
PII Sanitizer	Redacts patterns before AI model input (local and cloud)	NO	NO

The External AI row is a deliberate carve-out from Flow’s otherwise zero-egress posture, off by default and gated by settings. Cloud calls go through the same PII Sanitizer as local calls. See Cloud providers.

The orchestration engine

The local host process is the sole custodian of all credentials and the sole executor of privileged operations. When an AI model produces a text-based recommendation, the orchestration engine decides whether and how to execute it using the user’s authenticated session. The model does not make that decision. All privileged operations execute strictly in the user’s authenticated context. System authorization is fully respected, and audit trails reflect the actual user.

Privilege segmentation

Flow has four logical domains, and each one has a narrow capability boundary.

Domain	Owns	Cannot
Orchestration	Authenticated profiles via the OS credential store; issues scoped execution tokens	Pass raw credentials to other domains
Execution	Receives scoped tokens; spawns CLI operations	Read or modify stored credentials; talk directly to Reasoning
Reasoning	Runs local AI models via the managed subprocess	Access credentials, tokens, or the execution interface
Authority	Exercised by the user via the canvas approval UI; decisions logged as audit events	Bypass user approval in the human-review band

Compromising the AI runtime grants no credentials or execution capability. Compromising an execution step exposes no stored secrets.

The single trust anchor

If the Host Process is compromised, all three functions are exposed. Until full domain segmentation at the OS-process level, the mitigations are:

The Host Process runs with least-privilege OS permissions. It does not run as root or admin.
Credentials live in the OS-native credential manager (macOS Keychain, Windows Credential Manager, libsecret) and are retrieved at execution time, never cached beyond the active run.
The inference engine has no access to the credential retrieval API. Credential references are never passed on the inference call path.
All dependencies are pinned and audited for CVEs.

These controls reduce the practical attack surface to a level consistent with other developer desktop tooling that operates with user-context credentials.

Zero egress - the compliance argument.
Credentials and PII - the sanitizer in detail.
Sandboxing - the shell adapter’s layered enforcement.