Flowise Security: A Deployment Acceptance Test for Production

Flowise documents two authentication levels: application and chatflow. Its rate-limit guide also states that a publicly shared chatflow without API authorization can be reached by anybody through the API or embedded chat. Production approval should test those boundaries independently. The same record must prove the public-flow decision and the client IP seen through every proxy. It must also prove the identity carried into policy and the route used for outbound model calls. A green login test covers only the first slice.

TL;DR

• Test application authentication and chatflow authentication as separate controls, with separate denial evidence.
• Treat every flow as public until the deployed API and embed routes prove the intended access decision.
• Verify IP-based limits through the real load balancer and proxy chain, including the returned client IP.
• Trace caller identity and the outbound model destination. DeepInspect applies only when that model leg is routed separately through its HTTP proxy.

Flowise security has two authentication boundaries

The Flowise authorization documentation divides authentication into application-level and chatflow-level methods. That split should appear unchanged in the acceptance record. Application authentication controls access to the Flowise instance and its management surface. Chatflow authentication controls invocation of a particular flow. Passing one test says nothing about the other route.

Use two named fixtures for this check. The first attempts to reach the application as an unauthenticated browser session and as an authenticated operator. The second invokes a selected chatflow through every supported public path, including the API and embedded chat where deployed. Capture the status and response body for each attempt. Record the timestamp and flow identifier. Retain the edge request identifier.

I would reject a production ticket whose evidence is a screenshot of the login page. A login form proves pixels rendered. It does not prove that an unauthenticated request failed at the management API or that a prediction route enforced the chatflow decision.

The per-role AI policies guide covers the next boundary, where a known caller's role becomes an input to an LLM policy decision.

Public flow exposure needs an explicit decision

Flowise's rate-limit documentation says that anybody can access a chatflow shared publicly without API authorization through the API or embedded chat. Rate limiting is presented as a spam control for that public condition. The acceptance test should therefore record one deliberate posture for every flow. The available postures include private invocation and controlled public invocation. Prohibited public exposure is the remaining posture.

For a private flow, send requests without the expected chatflow credential through the API and embed path. The pass condition is denial before workflow execution and before any model charge. For a controlled public flow, prove that the published path is the only intended route, then test input limits and output handling. Test abuse controls and downstream spend caps separately. A prohibited-public fixture should fail deployment review if either path returns a prediction.

Put the flow ID and its expected posture on a card beside the terminal. That small physical detail catches a common review error: an engineer tests the right command against yesterday's flow identifier.

Rate limits depend on the observed client IP

The Flowise rate-limit page describes the message limit per duration and the duration in seconds. It also defines the response returned after the limit is exceeded. Its example allows 20 messages in 60 seconds. The page says tracking uses the IP address and directs cloud deployments behind a proxy or load balancer to configure NUMBER_OF_PROXIES. It also provides /api/v1/ip as the verification route.

Run the test through the production hostname. Record the IP returned by /api/v1/ip and compare it with the test client's expected public address. Then send the configured allowance plus one request inside one duration. The first set should follow the expected path. Confirm that the next request receives the configured limit response. Repeat through each ingress route and with a second client address.

A mistaken proxy count can collapse many users onto one observed address or accept an untrusted forwarded address. The test evidence needs the deployed proxy chain and configured value. Retain the returned IP and counter window. Record the response and timestamp. The AI gateway rate-limiting guide explains why application abuse limits and model-route quotas should remain separate controls.

Identity propagation needs a named contract

Authentication establishes access at a boundary. The workflow still needs a documented identity contract if downstream policy or audit records depend on the caller. Define the exact Flowise-side subject used for an application operator and the exact credential or principal used for a chatflow invocation. Then define which identity and tenant attributes may cross into the model-request path. Document the permitted role and flow attributes as well.

Use fixtures for an ordinary user and a privileged operator. Add an invalid or expired credential as a separate fixture. Record the subject observed at the application boundary and the flow identifier. Retain the downstream identity claims and final policy action. The invalid fixture should terminate before model invocation. A privileged application role should not silently become a privileged model caller unless the architecture defines and approves that mapping.

Avoid putting long-lived secrets or raw credentials into trace fields. Preserve a stable subject identifier and credential class. Record the authentication result and request correlation ID. The identity-aware AI gateway guide describes the difference between authenticating a connection and authorizing a specific model request for a specific caller.

The outbound model route needs its own trace

A Flowise workflow can reach a model provider after the application and chatflow checks pass. Production acceptance should identify the exact egress hostname and model. Record the credential owner and network path. Document the timeout and retry behavior. Retain the correlation field for that call. Capture one allowed request and one denied request. The denied fixture should show zero provider invocation when the decision occurs before egress.

Trace the route with a harmless marker such as a request ID, never a customer secret. The retained record should join the Flowise flow ID with the caller subject. Add the model destination and policy version. Retain the action and provider request identifier where available. Retry tests matter because one user action can create more than one outbound call. Spend controls and evidence counts should reflect that behavior.

Flowise owns workflow construction and execution. The deployment owns host hardening, secrets, ingress, and storage. A separately routed enforcement proxy can govern the HTTP model leg. Local tool execution, credential stores, non-model HTTP calls, and the Flowise management surface remain outside that proxy boundary.

A five-part acceptance record makes failures reproducible

Keep one record per release and environment. Name the Flowise version and deployment region. Record the ingress hostname and proxy chain. Add the tested flow IDs and model destinations. Retain the technical owner and test time. The release record then needs five result blocks.

• Application authentication: Capture the unauthenticated management request and authenticated operator request. Record the denial point and session or subject evidence. State the pass condition.
• Chatflow authentication: Capture API and embed requests for each selected flow. Record the credential state and execution evidence. State the denial point and pass condition.
• Public exposure: Record the declared posture per flow and external reachability result. Identify the allowed path and blocked path. Retain the owner approval.
• Rate limiting: Record the message allowance and duration. Capture the limit response and NUMBER_OF_PROXIES. Retain the /api/v1/ip result and results from two client addresses. Record the boundary request.
• Identity and model route: Record the caller subject. Retain tenant and role claims where used. Add the flow ID and egress destination. Record the policy version and final action. Retain the correlated provider event.

A failed block should identify the component and rerun owner. Keep the raw HTTP capture with secrets redacted. A five-line dashboard summary is useful for status, but the capture is what lets an engineer reproduce the denial at 02:10 during an incident.

DeepInspect

DeepInspect can evaluate a Flowise outbound model request when the deployment deliberately routes that authenticated HTTP leg through its stateless proxy. The policy can use the caller identity and role supplied by the application. It can also use the tenant and flow identifier. The data class and model destination provide further inputs. It then records the action independently of the Flowise workflow's own write path.

Flowise application and chatflow authentication need their own controls and acceptance evidence, including public-exposure and IP-rate-limit tests. Host security, secret storage, and local tool execution remain separate. Book a demo today.