# Security model flowifai is an approval layer for cooperative MCP tool paths. It keeps downstream service credentials local while the backend handles policy, approval, audit, and registered tool metadata. This page states the threat model plainly: what is enforced, where, and where the limits are. ## The adversary is the agent The threat flowifai is built for is the agent itself — prompt injection, confused deputies, and plain mistakes — not a hostile human operator with root on the box. The design goal is that an injected or misbehaving agent cannot execute a gated action without a human decision, cannot approve its own calls, and cannot erase the record of what it did. ## Credential boundary Credentials configured in your local MCP server — API keys, service tokens — stay in the local tools sandbox with that server. The flowifai enrollment credential is separate: the broker uses it to authenticate outbound calls to the backend. | Local tools host | flowifai cloud | | --- | --- | | MCP server credentials, real tool execution, broker service, wrapper-facing broker endpoint, local flowifai config | Policy, approval tickets, audit records, registered tool metadata, setup lifecycle events, billing/auth state | The backend's store has no downstream credential columns by construction — the cloud is an approval authority, never a credential holder. ## What the backend can receive The backend may receive and store registered tool names, descriptions, input schemas, arguments needed for policy and approval, approval decisions, audit metadata, lifecycle events, and execution results. Any value included in tool arguments or execution results — including accidental secrets — may therefore be sent to and stored by the backend. Treat arguments and results as sensitive data. ## Broker and wrapper The broker is the local trust anchor. It owns the enrollment credential, launches the real MCP server, and never trusts client-asserted approval — it resolves every ticket against the backend over its authenticated server-to-server channel. The wrapper is an untrusted stdio shim for the agent and owns no flowifai credential. Bypassing the wrapper just reaches the broker, which still gates. The broker's wrapper-facing endpoints are not authenticated, so same-host setups should keep the broker on loopback (the default is `127.0.0.1:8090`) and split-host setups should use an SSH or equivalent authenticated encrypted loopback tunnel. ### Setup-managed profile processes The setup wizard gives each distinct protected MCP launch a private profile, credential, loopback endpoint, and broker process. A wrapper names its profile, reads that profile's current runtime identity, and reconnects if the broker restarts. The broker checks that the profile is active on each tool call. The real MCP process receives the environment frozen for that profile during setup, not the broker's current ambient environment. flowifai control variables and setup, enrollment, broker, and server-to-server secret names are removed, and the broker's per-profile credential is never passed to the child MCP process. These boundaries reduce accidental cross-profile sharing. They are process and configuration isolation only — not container, VM, filesystem, or network isolation. The wrapper-facing loopback endpoint uses profile runtime identity for routing and restart detection; it is not authentication against a hostile same-host caller. ## Pull-only cloud model The backend never initiates a connection into your machine. The broker asks the backend for policy and approval decisions through outbound requests, and the local broker performs the actual tool execution through the MCP server you configured. There is no daemon the cloud can push into. ## Approval integrity Approving or denying requires a human user identity distinct from the broker's machine identity — an agent holding the broker's credential cannot self-approve. Policies can require n-of-m approvals across approver groups with cross-group separation of duty; one eligible deny vetoes. Policy authorship is a separate capability from approval eligibility, so a lone approver cannot rewrite policy to bypass the gate. Approved actions execute exactly once per ticket via a two-phase claim/complete protocol; a broker crash mid-execution resolves to `execution_failed` and a fresh human approval, never a silent re-run. The [protocol-native approval delivery](/docs/protocol-native-approvals/) in MCP clients is delivery only: no client response can authorize execution — the decision is always server-side, policy-checked, and audited. ## Fail closed everywhere Policy is default-deny: no matching rule means deny, unparseable arguments mean deny, and a predicate evaluation error denies the whole call. An unregistered or schema-drifted server refuses all calls. Approved-but-unexecuted tickets expire. Execution failures are terminal and never auto re-arm. ## Audit and non-repudiation Adjudications, approvals, denials, execution outcomes, drift events, auth failures, policy changes, and lifecycle transitions are written to an append-only audit log — updates and deletes are rejected at the database level. Security-critical transitions (approve, deny, execution complete, execution fail) write their audit row in the same transaction as the state change, so a committed execution can never lack its audit record. Correlation IDs are broker-minted, so audit attribution is not agent-forgeable. ## What flowifai is not flowifai is a **cooperative gate, not a sandbox**. It is not a VM sandbox, EDR product, network firewall, or guarantee that a compromised agent cannot act through some other path. It gates the MCP path you route through the wrapper and broker. If an agent also has direct API keys, shell access, or another ungated tool path, those paths remain outside flowifai control. Keeping the agent away from credentials and ungated paths is a *deployment* property: run the agent and the tools in separate sandboxes, do not co-mount secrets into the agent's environment, and treat the broker as the tools sandbox's only ingress. flowifai supports and documents this topology but cannot enforce it from code. ## Retention and deletion posture Audit and approval records exist so operators can review what happened. Public launch plans keep pricing and billing simple while retention controls mature; if your evaluation needs a specific deletion or retention commitment, [contact the team](/contact/) before routing sensitive production workflows.