AgentShield

Best AI Agent Security Software for Self-Hosted Flowise

AgentShield Security Team·Sep 21, 2026·8 min read

Try it live

Watch AgentShield block an attack in real time.

Pick a scenario and drive the inspection lane yourself. No signup needed.

Threat Console
Interactive demo · 0 blocked in this session

Run a request

Runs the live engine on your text. Nothing is stored, no account needed.

Inspection lane

INSPECTING
untrusted input

Policy trace

High-risk action held for approval

Audit trail

There is no security product that makes an archived application supported, so start from the honest version: the best thing you can do for a self-hosted Flowise instance is get off it. What you actually need to buy, if anything, is coverage for the three to six months that migration takes, and the answer depends almost entirely on what credentials the instance holds and whether code execution is enabled. If it holds nothing and executes nothing, network isolation is enough and you should spend zero dollars.

Flowise froze development on July 29, 2026 with version 3.1.4 as the final release, and the repository was archived on GitHub on August 13. The sunset notice is direct about it: "Active feature development ceases immediately. We will no longer be reviewing or accepting new Pull Requests." Official core team presence in Discord and GitHub concluded on August 31. Advisories published after the freeze name 3.1.4 as affected and carry no patched version, because there is no longer anyone upstream to publish one.

That is an unusual situation and most security advice does not apply to it. The normal end-of-life playbook assumes you can still pull a critical patch. Here you cannot, which changes which controls are worth paying for.

First, work out how exposed you actually are

Teams jump to tool selection before answering this, and it wastes money in both directions. Three questions decide it.

What credentials does the instance hold? This is the one that matters most. A visual builder exists so that non-engineers can connect systems without writing code, which means it accumulates long-lived tokens for the CRM, the data warehouse and the ticketing system. Open the credentials store and read the list. Most teams find at least one token with far more scope than any chatflow uses.

Is code execution enabled? Chatflows can run generated code, and published advisories describe both a prompt injection reaching an unsandboxed Python path and a sandbox escape in the JavaScript path that reaches the host. If those node types are unused, disabling them removes a large share of the risk for free.

Is it reachable, and by whom? An instance on an internal subnet behind SSO is a different problem from one exposed to the internet with its own login. One advisory describes an authentication bypass requiring no login at all, so "we have accounts on it" is not the protection it sounds like.

If the answers are no credentials, no code execution and no exposure, you are done. Wall it off, finish the migration, buy nothing.

Six options, compared on what they actually buy you

Two of these cost nothing and one of them is the right answer for a good share of readers.

OptionWhat it coversWhere it falls shortCost
Harden and isolate in placeRemoves network exposure, puts the instance behind existing SSO, disables unused node types, forces the MCP transport to SSE rather than stdioDoes nothing about a valid credential being used by whoever holds it. The application code stays unpatchedNothing but engineering time. Do this regardless of what else you pick
Re-scope every credentialRotate each stored token and re-issue it scoped to the single chatflow that needs it, so a compromise reaches lessTedious, and the granularity available depends on what each upstream system supports. Some systems only offer broad scopesNothing but engineering time. The highest-value free action on this list
Fork and self-maintainLets you patch the Apache 2.0 majority of the codebase on your own scheduleThe license carves out packages/server/src/enterprise and files such as IdentityManager.ts under a Commercial License, and that is the authentication, SSO and access-control layer where the post-freeze advisories cluster. Check your rights before planning to patch itOngoing engineering headcount, indefinitely
Migrate to another visual builderGets you back onto maintained software with a similar building experienceNot automatically a security upgrade. The main open-source alternatives have their own critical remote code execution history, so check current advisory status and maintenance health rather than trusting recency. Custom nodes need a manual portA quarter or more of project time, plus the new platform's licensing
Rebuild on a maintained frameworkMoves the logic into code, where permissions and approvals become explicit and reviewableNeeds real engineering capacity and removes the non-engineer self-service that made Flowise attractive in the first placeThe largest project on this list, and often the right one anyway
External policy point (this is us)Constrains what the instance can reach regardless of whether the app can be patched: per-agent tool and data scopes, approval gates on irreversible actions, an audit trail held outside the boxDoes not patch Flowise, does not make archived software supported, and is overkill for an instance with no credentialsA subscription, and it carries across to whatever you migrate to

Read that table as a sequence rather than a menu. The first two rows are not competing with the last one, they come before it. If a vendor tells you to skip them and buy the product instead, that is a reason to distrust the vendor.

Why the migration window is the part people underestimate

Everyone agrees the destination is "off Flowise". The plans we see go wrong on timing. A single demo chatflow moves in an afternoon. An estate of thirty flows built by six different people over eighteen months, several with custom nodes and none with documentation, does not. Porting custom nodes in particular is a code migration rather than a configuration exercise, and it is the kind of mechanical refactor where handing the first pass to an autonomous coding agent that plans the change before executing it saves more time than it costs to review.

Plan for a quarter and you will usually be right. During that quarter the instance is still serving the business, still holding credentials, and still running a version that several open advisories name as affected with no patch available. That window is the entire commercial case for buying anything here, and it is a genuinely time-boxed one. We would rather say that plainly than pretend this is a permanent purchase.

The useful test when comparing products for that window: does the control sit inside the application or outside it? Anything that runs inside a Flowise instance inherits that instance's compromise. A policy point between Flowise and the systems it reaches does not, which is why the credential and approval controls belong there rather than in a plugin.

What to check before you buy anything

Four questions, in the order they matter.

Does it enforce, or only report? A dashboard telling you that a compromised instance called your production database at 3am is not a control. The distinction is the one we set out on AI runtime security, and it separates most of this market.

Can it scope permissions per chatflow, not per instance? One credential shared across every flow means one compromise reaches everything. Per-agent tool and data permissions only help if the granularity matches how the work is actually split.

Can an irreversible action wait for a person? Deletes, refunds and outbound sends are where the money is. If the product cannot hold one for a named approver, it cannot help with the failure mode you are most worried about. That is what human approval gates for AI agents are for.

Does the record survive the instance? If your only log of what the agent did lives inside the compromised box, you have no incident evidence. An immutable audit trail stored outside the application is the difference between reconstructing an incident and guessing at it.

Common questions

Is Flowise still safe to use? It depends on what the instance can reach. Advisories published after the July 2026 code freeze name version 3.1.4 as affected and list no patched version, and 3.1.4 is the final release. A networked instance holding OAuth credentials with code execution enabled is carrying meaningful risk. An isolated instance with neither is a small problem. Inventory before you judge.

Can I just fork Flowise? Partly, and the limit is specific. The sunset notice says the Apache 2.0 licensed code is yours to keep building on, but the license file places packages/server/src/enterprise and files such as IdentityManager.ts under a Commercial License. That is the identity and access-control layer, which is exactly where you would need to fix an authentication bypass.

What is the cheapest thing that meaningfully reduces risk? Rotating and re-scoping every stored credential, then disabling unused node types. Both cost engineering time only, and together they shrink the blast radius more than any purchase does. Do them this week whatever else you decide.

Do I still need this after I migrate? That is the honest question to ask us. If the destination is a maintained platform with good native controls and one team owns every agent, probably not. If you end up running agents across several frameworks, or an auditor needs one record of what each was permitted to do, the control plane keeps earning its place. Full detail on the Flowise case sits on our Flowise security page.

See the firewall block an attack live.

Drive the Threat Console and watch a real prompt injection get stopped, then put AgentShield in front of your own agents.

Open the console