Flow security

Flows connect agents, APIs and conversations, so output from one step can try to influence the next. These are the boundaries LoCrew enforces, as implemented in the code.

#Output is data, not instructions

• An agent step only receives the outputs you tick, and each is fenced as untrusted data that cannot grant permissions, authorise a command, change its task or decide the next step.
• Messages a flow posts to conversations are shown to agents as LoCrew Flow (automated output, untrusted).

#Routing is decided by the graph

What runs next is decided by the arrows and by condition rules. Conditions use a fixed set of comparisons and never evaluate code or follow instructions found in the output. An agent's reply cannot choose the next step.

#No hand-offs inside a run

Each run has its own private conversation with agent-to-agent hand-offs turned off. If an agent calls send_message during a flow step, its message is recorded but wakes nobody.

#Permissions are unchanged

Flows never change an agent's permissions. An Ask first agent still stops for your approval before writing, and the directory lock still applies. Approving a flow's Human approval step never approves file changes.

#Budgets that fail closed

Before every agent attempt, LoCrew checks that the run has started fewer than 200 agent steps and that its measured spend is under Max spend per chain. If a step's spend could not be measured while the limit is on, the next step is refused rather than allowed.

#Approvals cannot be forged

An approval decision is accepted only for an approval that exists, is still pending, and belongs to a run that is still waiting. Replayed or late decisions are refused.

#/run only comes from you

A /run command is only recognised in messages you send. Messages from agents and posts from flows are never parsed as commands, and flow posts wake nobody.

#HTTP steps

• The scheme and host must be written in the step; values may only go in the path or query.
• Private and local network addresses are refused unless you allow them, and the check happens when the connection is made.
• https:// is required unless you allow http://.
• Redirects are limited to five, and credentials and cookies are dropped when a redirect changes site.
• Responses have size and time limits, and non-idempotent requests are never repeated when their outcome is unknown.

See HTTP requests.

#Secrets

• Saved HTTP keys are encrypted with your operating system's keychain and never stored in the flow.
• Values that look like keys, tokens or passwords are masked before run data is stored or shown. Automatic detection cannot catch every secret.
• Templates cannot carry ids, credentials or permission switches.

#What flows do not protect against

• An agent with Full access can still change anything its CLI can reach as your user account. File access levels are limits, not a sandbox.
• A flow's HTTP step sends whatever you configure to the host you configure.
• Masking is pattern-based. Do not paste secrets into tasks or messages.
• Model and external agents are never priced, so spend limits do not cover them.

#Related

• Permissions and file access
• Local data and privacy