Authorization

Langflow includes a pluggable authorization layer for role-based access control (RBAC) over flows, projects, deployments, files, variables, and knowledge bases.

The authorization infrastructure is present in all Langflow deployments, but the open-source build registers a pass-through service that always allows every action for every authenticated user.

Setting LANGFLOW_AUTHZ_ENABLED=true without an enforcement plugin does not restrict access. Route guards still run and audit rows can still be written, but no policy is applied.

Per-resource RBAC enforcement requires a registered authorization plugin. Langflow OSS does not include a registered authorization plugin.

Enable RBAC with an enforcement plugin

The following steps apply when you have a registered enforcement plugin.

1. Set LANGFLOW_AUTHZ_AUDIT_ENABLED=true and run Langflow in a staging environment. Review the audit log to understand what decisions would be made before enforcement is on.

2. Install and register the enforcement plugin following its setup guide.

3. Set LANGFLOW_AUTHZ_ENABLED=true. The plugin reads the role and share tables and applies its policy.

4. Use the roles API and role assignments API to assign the built-in viewer, developer, or admin roles to your users, or create custom roles.

5. Use the shares API to grant cross-user access where needed.

Configure authorization environment variables

The default audit producer is intentionally best effort to preserve the OSS request-path behavior: a saturated queue or exhausted database flush can lose a row. Durable mode is explicit and fail-closed. It assigns the event ID and event time before enqueue, applies bounded backpressure, and acknowledges the caller only after the batch commits. Producer health reports only counters and bounded failure class names; database exception text is never exposed.

System roles

Langflow seeds three built-in system roles that an enforcement plugin uses as a starting point for policy sync. These roles cannot be deleted.

You can create additional roles with the roles API. Role assignments take effect only after an enforcement plugin is registered.

Authorization API reference

All authorization endpoints are under /api/v1/authz/. Write operations require superuser privileges.

These endpoints manage the RBAC data model. An enforcement plugin consumes roles, assignments, and shares when evaluating requests. Without a plugin, API responses succeed but access is not restricted.

Shared-flow execution identity

A share delegates an action on a resource; it does not delegate the owner's identity or credentials.

For an authenticated shared-flow run, the authenticated caller is the execution principal. Variables, files, nested flows, messages, jobs, and other dependencies resolve in that caller's namespace. A dependency must therefore be owned by the caller or shared with the caller separately. Langflow never falls back to the flow owner's credentials when a caller-owned or explicitly shared dependency is unavailable.

Only the flow owner can submit graph data or component-parameter tweaks. A non-owner receives the same not-found response as a caller without access so the rejection does not confirm that the flow exists.

Revoking a share prevents new runs and rechecked continuations, including HITL resume. It does not change the principal of work that is already running or terminate that work. Deployments and legacy public entry points are explicit exceptions:

• Public V1/V2 and unauthenticated A2A (auth_type=none) entry points execute with a stable, non-persisted anonymous principal under visitor-isolated session and storage namespaces. They never inherit the published flow owner's credentials, variables, files, or Memory Bases, and public requests cannot submit graph data or tweaks. Protected A2A (apikey or oauth) continues to require and execute as the flow owner.
• Deployment authorization and audit use the requesting actor, while the external deployment data plane continues to use the deployment owner's provider namespace. Provider controls govern already-running work.
• Webhooks, legacy MCP, and project MCP remain owner-scoped admission surfaces in this release; they do not widen execution to shared flows. Webhook request data is the one trusted server-generated tweak and is mapped only to the published Webhook Component.

Owner-only execution retains detailed component errors for debugging. Delegated and public execution returns a stable generic workflow error without a component traceback or provider detail. Server logs and telemetry keep the original exception.

:::important Upgrade note: paused public A2A tasks An A2A HITL resume requires the stored checkpoint's principal to match the principal the current request was admitted under. Checkpoints written before anonymous public execution existed recorded the flow owner, while an auth_type=none folder now admits the anonymous principal, so a public A2A task that is paused across this upgrade cannot be resumed and returns 404. There is no compatibility read for these rows on purpose: accepting an owner-principal checkpoint under an anonymous principal is exactly the protected-to-public transition this check exists to block. Drain or cancel paused public A2A tasks before upgrading, then start them again. Protected (apikey, oauth) A2A tasks are unaffected. :::

The machine-validated endpoint-family contract is maintained in scripts/ci/execution_principal_matrix.json. Changes to a listed runtime surface must update that matrix and its referenced tests.

Effective permissions

POST /api/v1/authz/me/permissions

Returns the allowed actions for a set of resources for the current user, without making individual resource requests that would trigger 403 responses. The frontend uses this to enable or disable UI controls when an enforcement plugin is active.

Request body:

Response:

{
  "resource_type": "flow",
  "permissions": {
    "3fa85f64-5717-4562-b3fc-2c963f66afa6": ["read", "execute"]
  }
}

Shares API

/api/v1/authz/shares

Shares grant access to a resource across user boundaries. The resource owner or a superuser can administer shares for their own resources.

Each share write fires an invalidation call to the authorization plugin so cached policy is refreshed.

Roles API

/api/v1/authz/roles — superuser only for writes

Role assignments API

/api/v1/authz/role-assignments — superuser only for writes

Teams API

/api/v1/authz/teams — superuser only for writes

Audit log API

GET /api/v1/authz/audit — superuser only

Returns a paginated, filterable view of the authorization audit log.

Query parameters:

Page size is capped at 200 rows.

See also

• Authentication and authorization overview
• API keys and authentication
• External authentication
• JWT authentication
• Security