Langflow

Started the way the README says (`langflow run`), default authentication is not locked down. Every flow, agent and custom component runs inside the server process with that process's full authority, including the database and the key that decrypts every user's stored credentials. The HTTP API checks that a user owns a flow, but the role-based authorization layer is off by default and needs a plugin.

The Agent component has a per-tool human approval step: a reviewer can approve, edit or reject a pending tool call from the UI, and an authenticated flow-execute permission check guards the resume endpoint. It is off by default: a tool is gated only if the flow author picks approval actions for it, and none are picked by default. Nothing gates components that run directly in a flow, and nothing gates the built-in Assistant, which runs model-generated component code in-process to validate it. Assistant edits to a flow get a restore point, but external actions have no undo.

The built-in network and file components are well validated. URL, API Request and Web Search block internal and cloud-metadata addresses, pin DNS, and re-validate each redirect. File components resolve paths and keep them inside the user's storage directory. Both protections are on by default. But the toolbox also has general-purpose tools, such as the Python Interpreter, raw HTTP to any public host, custom component code and whole MCP servers, and there is no central policy layer that every tool inherits.

By default, model-written Python (the Python Interpreter tool, Smart Transform) runs inside the Langflow server process. The only protection is restricted builtins and AST checks, which the maintainers describe as best-effort and not a guaranteed sandbox. Custom component code, and the Assistant's validation of model-generated components, also run in-process, and MCP stdio servers start on the host. An escape lands in the process that holds the database, the secret key and every stored credential. An optional QEMU microVM backend (exec-sandbox) with no network and fail-closed behaviour exists, but it is off by default and covers only the Python Interpreter and REPL components.

Nothing structural limits what a hijacked agent can do. Web pages, files, search results and MCP tool output come back as ordinary tool messages. The only defence is a line in the default system prompt telling the model to treat tool output as untrusted. One agent can read attacker-controlled content, hold stored credentials, and send data to any public host or take irreversible actions, all without a human.

Agent chat history is stored per session and fed back as conversation (up to 100 messages by default) with no validation, so injected text persists for as long as a session id is reused. Queries scope history by session, flow and user. The Assistant also saves model-generated component code to disk after scanning it, and later turns import and execute that code. Vector stores and knowledge bases written by flows have no provenance tagging.

On startup, Langflow adds an MCP server entry for each user's starter project. The entry runs `uvx mcp-proxy` with no version pin, so whatever release PyPI serves is downloaded and run when the server is checked or used. Users can add more stdio servers through npx/uvx/docker. A command allowlist, a shell-metacharacter policy and an environment-variable denylist apply, but versions are not pinned and nothing checks integrity. The package allowlist and the interpreter and Docker hardening are opt-in. Stdio servers start with a scrubbed environment (PATH plus their own config), but they run as the same OS user.

Credential-type variables are Fernet-encrypted in the database. The key sits in a permission-restricted file in the same config directory, so anyone who can read that directory can decrypt them. Settings use SecretStr. Transaction logs mask values under sensitive key names, and telemetry sends only allowlisted input fields. Usage telemetry to Scarf is on by default and includes error messages. Nothing redacts secrets before model-bound messages. Provider keys are long-lived, and in-process code can reach them.

Every component run is written to a transactions table with inputs, outputs, status and timestamp. Agent tool calls are kept in stored messages as tool-use content blocks with name, input and output. Records lack an actor or approver field, and the authorization audit log is off by default. Writes go through a best-effort background writer that drops rows on a hard crash. Retention keeps only the newest 3,000 transactions, and the server process, where flows and code run, can alter the records.

The Agent is capped at 15 model calls by default, enforced by middleware. MCP tool calls time out after 180 seconds, and synchronous v2 workflow runs after 300. There is no token or cost budget. Background jobs have no timeout by default. Sub-flows and agents used as tools start with their own fresh limits. Cancelling a build cancels the asyncio task, but in-process code already running is not interrupted.