Flowise
AI · AI
Chatflows, assistants, tools, and document stores in the account they connected.
Connecting Flowise in practice
A Flowise flow is public by default: "anyone that has access to the Chatflow ID is able to run prediction through Embed or API" until you attach an API key to that specific flow. Because Flowise is the thing you run, there is no vendor rate limit either — throttling is a configuration option you set, not a ceiling you discover.
Scopes that draw scrutiny
DefaultKeyCreated automatically in the API Keys section. It is a bearer credential with no route or flow restrictions of its own, and it is the key most instances are still shipping with.
Worth knowing
- Chatflow-level access control is opt-in per flow. Assigning a key to one chatflow does nothing for the others, so a partly secured instance is the normal failure mode.
- App-level access control (who can reach the Flowise UI) and chatflow-level access control (who can call a flow) are separate settings; securing the dashboard does not secure the prediction endpoint.
- Once a key is attached, requests must carry Authorization: Bearer <api-key> and unauthenticated calls are rejected — including any embed you had already published.
- Rate limiting is a per-instance configuration page rather than a platform guarantee, so a self-hosted Flowise will happily forward an agent’s retry storm to the underlying model provider.
Checked against Authorization (2026-09-29), Chatflow-level access control (2026-09-29), Rate limit configuration (2026-09-29)
What an agent can do
Each action is granted on its own. An agent allowed to read is not thereby allowed to write, and the scope beside each row is what the acting user must have connected for it to run at all.
Often connected alongside
Put Flowise behind one governed endpoint.
Same permissions, same audit trail, whatever else you connect next.