Security Checklist for Self-Hosted Visual Workflow Builders

Why self-hosted workflow builders have a different threat model

When you self-host a visual workflow builder — Flowise, Langflow, n8n, or similar — you are running a web application on your infrastructure that can execute arbitrary LLM calls, tool calls, and in some cases subprocess commands. The attack surface is different from a typical web app.

The 2025 Flowise RCE vulnerability (CVE-2025-59528) is a useful reference. An unauthenticated POST to `/api/v1/prediction/:id` could execute arbitrary JavaScript in the server process, giving attackers access to any credentials loaded in the server's environment. This wasn't a subtle bug — it was the product of running user-submitted prompt content through an eval-adjacent path without isolation.

Here is the production checklist we use when evaluating whether a self-hosted workflow tool is safe to deploy with real credentials and real data.

Network layer

**No public ingress.** The workflow builder should not be reachable from the public internet. Put it behind a VPN or private subnet. Legitimate users authenticate to the VPN first.
**No wildcard CORS.** `Access-Control-Allow-Origin: *` allows any origin to make authenticated requests. Scope CORS to your internal domain.
**TLS termination.** All traffic, including internal, must be encrypted. Use cert-manager on Kubernetes or ACM on AWS.
**Egress filtering.** Define which external domains the tool is allowed to call. Block all others at the network layer. This prevents exfiltration via LLM-injected tool calls.

Secret handling

**No credentials in the UI.** Workflow builders that store API keys in their own database are a single SQL injection from a full credential leak. Use a secret vault reference instead.
**Runtime secret injection.** Mount secrets from AWS Secrets Manager, HashiCorp Vault, or Kubernetes Secrets at pod startup. Never put credentials in environment variable values that are logged.
**Secret rotation.** API keys should have a rotation schedule. Workflow tools that hardcode keys in workflow definitions make rotation painful — design your secret reference pattern before you build workflows.
**Audit who accessed what key.** Your vault should log every key access. When an incident happens, you need to know which workflows touched which credentials.

Execution isolation

**No subprocess execution without an allow-list.** If the tool can run shell commands or Python code, that execution must be sandboxed (Docker container, gVisor, or at minimum a process with no network access and no write permissions outside /tmp).
**Tool call authorization.** Agent tool calls should go through an authorization layer. Not every agent should be able to call every tool. Especially not delete, write, or network calls.
**Output sanitization.** LLM output that flows into tool inputs must be sanitized. Prompt injection via tool results is a real attack vector.

Audit and compliance

**Immutable execution log.** Every workflow execution — including failures, retries, and tool calls — must be logged to an append-only store. If your tool doesn't provide this, build a proxy layer that does.
**Log forwarding.** Execution logs should ship to your SIEM (Splunk, Datadog, CloudWatch Logs) in real time. Don't rely on local disk logs that get rotated away.
**No PHI in tool call arguments.** If your workflows process regulated data, validate that PHI doesn't appear in tool call arguments before they're sent to external APIs.

Patching

**Weekly dependency review.** Run `npm audit` or `pip-audit` as part of your CI. Workflow builders often have large dependency trees with frequent CVEs.
**Pin image versions.** Use digest-pinned Docker images, not `latest`. This gives you reproducible builds and auditable change history.
**Renovate or Dependabot.** Automate dependency PRs. Manual review of every package update doesn't scale.

The MeshFlow alternative

These controls are necessary regardless of which tool you use. MeshFlow builds them into the framework rather than requiring a checklist:

Execution is isolated — `StepRuntime` enforces policy gates before every tool call
Secrets are managed via `VaultProvider` (AWS, HashiCorp, or env) — not stored in workflow definitions
Every execution writes a SHA-256 tamper-evident StepRecord
PIIBlocker runs before every LLM call — not just the ones you remember to add it to

If you're evaluating self-hosted workflow builders, use this checklist. If you're building regulated workflows, consider whether you want to implement each of these controls yourself or start from a framework that has them.

Why self-hosted workflow builders have a different threat model

Here is the production checklist we use when evaluating whether a self-hosted workflow tool is safe to deploy with real credentials and real data.

Network layer

**No public ingress.** The workflow builder should not be reachable from the public internet. Put it behind a VPN or private subnet. Legitimate users authenticate to the VPN first.

**No wildcard CORS.** `Access-Control-Allow-Origin: *` allows any origin to make authenticated requests. Scope CORS to your internal domain.

**TLS termination.** All traffic, including internal, must be encrypted. Use cert-manager on Kubernetes or ACM on AWS.

**Egress filtering.** Define which external domains the tool is allowed to call. Block all others at the network layer. This prevents exfiltration via LLM-injected tool calls.

Secret handling

**No credentials in the UI.** Workflow builders that store API keys in their own database are a single SQL injection from a full credential leak. Use a secret vault reference instead.

**Runtime secret injection.** Mount secrets from AWS Secrets Manager, HashiCorp Vault, or Kubernetes Secrets at pod startup. Never put credentials in environment variable values that are logged.

**Secret rotation.** API keys should have a rotation schedule. Workflow tools that hardcode keys in workflow definitions make rotation painful — design your secret reference pattern before you build workflows.

**Audit who accessed what key.** Your vault should log every key access. When an incident happens, you need to know which workflows touched which credentials.

Execution isolation

**No subprocess execution without an allow-list.** If the tool can run shell commands or Python code, that execution must be sandboxed (Docker container, gVisor, or at minimum a process with no network access and no write permissions outside /tmp).

**Tool call authorization.** Agent tool calls should go through an authorization layer. Not every agent should be able to call every tool. Especially not delete, write, or network calls.

**Output sanitization.** LLM output that flows into tool inputs must be sanitized. Prompt injection via tool results is a real attack vector.

Audit and compliance

**Immutable execution log.** Every workflow execution — including failures, retries, and tool calls — must be logged to an append-only store. If your tool doesn't provide this, build a proxy layer that does.

**Log forwarding.** Execution logs should ship to your SIEM (Splunk, Datadog, CloudWatch Logs) in real time. Don't rely on local disk logs that get rotated away.

**No PHI in tool call arguments.** If your workflows process regulated data, validate that PHI doesn't appear in tool call arguments before they're sent to external APIs.

Patching

**Weekly dependency review.** Run `npm audit` or `pip-audit` as part of your CI. Workflow builders often have large dependency trees with frequent CVEs.

**Pin image versions.** Use digest-pinned Docker images, not `latest`. This gives you reproducible builds and auditable change history.

**Renovate or Dependabot.** Automate dependency PRs. Manual review of every package update doesn't scale.

The MeshFlow alternative

These controls are necessary regardless of which tool you use. MeshFlow builds them into the framework rather than requiring a checklist:

Execution is isolated — `StepRuntime` enforces policy gates before every tool call

Secrets are managed via `VaultProvider` (AWS, HashiCorp, or env) — not stored in workflow definitions

Every execution writes a SHA-256 tamper-evident StepRecord

PIIBlocker runs before every LLM call — not just the ones you remember to add it to