Add pipeline flow builder UI for guardrail policies

[ishaan-jaff]

Summary

• Add pipeline column to LiteLLM_PolicyTable Prisma schema for storing guardrail pipeline data
• Add pipeline field to policy CRUD request/response types (create, update, DB response)
• Wire pipeline through all policy registry DB methods (add, update, get, list, sync, resolve) with PrismaJson wrapping
• Add Zapier-style visual flow builder UI component (pipeline_flow_builder.tsx) with trigger card, step cards, connector lines, and insert buttons
• Integrate flow builder into policy form with Simple Mode / Flow Builder mode toggle
• Add pipeline display section in policy info view
• Add POST /policies/test-pipeline endpoint for testing pipelines with sample messages
• Add test panel in flow builder UI with step-by-step results display
• Fix pipeline executor to inject guardrail name into metadata so guardrails actually execute

Test plan

• Unit tests pass (test_resolver_types.py - 6 tests)
• E2E: test-pipeline endpoint verified with OAI-moderation (block on profane, allow on clean)
• E2E: chat completions with pipeline policy blocks profane content through pipeline
• Manual UI: toggle to flow builder mode, add steps, save, verify in policy info view

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
litellm	Error		Feb 14, 2026 4:07am

[greptile-apps]

Greptile Overview

Greptile Summary

This PR adds a pipeline execution system for guardrail policies, allowing ordered, conditional guardrail execution (as opposed to running all guardrails independently). It includes a new PipelineExecutor, Prisma schema changes, type definitions, policy CRUD wiring, a test endpoint, and a full visual flow builder UI.

• Critical bug in pipeline_executor.py: _run_step mutates data["metadata"]["guardrails"] on a shallow-copied dict, corrupting the caller's metadata. After pipeline execution completes, the normal guardrail callback loop in pre_call_hook will see a corrupted guardrails list (containing only the last pipeline step's guardrail name), potentially causing guardrails to not run or run incorrectly.
• Pipeline-managed guardrails are correctly excluded from independent execution via _pipeline_managed_guardrails set tracking in both litellm_pre_call_utils.py and utils.py.
• Backend type system is well-structured with strict Pydantic validation (forbidden extras, action/mode validators).
• Test coverage is solid with mock-only tests covering escalation, early-allow, data forwarding, and error scenarios.
• The test-pipeline endpoint is missing the dependencies=[Depends(user_api_key_auth)] decorator that all other endpoints in the file use.
• UI adds a polished Zapier-style flow builder with mode picker, step cards, connector lines, and a test panel.

Confidence Score: 3/5

• This PR has a metadata mutation bug in the pipeline executor that can corrupt guardrail execution for non-pipeline guardrails; fix before merging.
• The shallow copy bug in pipeline_executor.py is a real logic error that will corrupt data["metadata"]["guardrails"] for the subsequent normal guardrail callback loop. The types, validation, DB wiring, tests, and UI are all well-structured. Score of 3 reflects the one critical bug that needs to be fixed, with the rest of the PR being solid.
• Pay close attention to litellm/proxy/policy_engine/pipeline_executor.py — the shallow copy on line 59 and metadata mutation on lines 150-154 corrupt shared state. Also review litellm/proxy/utils.py for the dead-code HTTPException guard.

Important Files Changed

Filename	Overview
litellm/proxy/policy_engine/pipeline_executor.py	New pipeline executor with a shallow copy bug that corrupts the caller's metadata guardrails list, breaking subsequent guardrail execution in the normal callback loop.
litellm/proxy/utils.py	Integrates pipeline execution into the pre_call_hook flow. Logic is sound for pipeline-managed guardrail skipping, but contains a dead-code branch for HTTPException null check.
litellm/proxy/policy_engine/policy_endpoints.py	Adds test-pipeline endpoint with proper validation. Minor inconsistency: missing dependencies decorator compared to other endpoints.
litellm/proxy/policy_engine/policy_registry.py	Adds pipeline field to all CRUD and sync paths with proper PrismaJson wrapping. Consistent and well-structured changes.
litellm/proxy/policy_engine/policy_resolver.py	Adds pipeline resolution and managed-guardrail tracking. Clean implementation following existing resolver patterns.
litellm/proxy/litellm_pre_call_utils.py	Integrates pipeline resolution into pre-call setup. Correctly excludes pipeline-managed guardrails from the flat guardrail list to prevent double execution.
litellm/types/proxy/policy_engine/pipeline_types.py	Well-defined Pydantic models with proper validation for pipeline steps, actions, and modes. Extra fields are forbidden.
ui/litellm-dashboard/src/components/policies/pipeline_flow_builder.tsx	New 999-line Zapier-style visual flow builder with trigger cards, step cards, connectors, test panel, and full-screen builder page. Well structured with proper validation.
ui/litellm-dashboard/src/components/policies/add_policy_form.tsx	Adds mode picker (Simple vs Flow Builder) and flow builder integration. Logic to redirect to flow builder for pipeline policies is handled correctly.

Sequence Diagram

sequenceDiagram
    participant Client
    participant PreCallUtils as litellm_pre_call_utils
    participant PolicyResolver
    participant PreCallHook as ProxyLogging.pre_call_hook
    participant PipelineExec as PipelineExecutor
    participant Guardrail as CustomGuardrail Callbacks

    Client->>PreCallUtils: add_guardrails_from_policy_engine(data)
    PreCallUtils->>PolicyResolver: resolve_guardrails_for_context(context)
    PolicyResolver-->>PreCallUtils: resolved guardrails list
    PreCallUtils->>PolicyResolver: resolve_pipelines_for_context(context)
    PolicyResolver-->>PreCallUtils: [(policy_name, pipeline)]
    PreCallUtils->>PolicyResolver: get_pipeline_managed_guardrails(pipelines)
    PolicyResolver-->>PreCallUtils: managed guardrail names set
    Note over PreCallUtils: Store pipelines + managed set in metadata<br/>Remove managed guardrails from flat list

    Client->>PreCallHook: pre_call_hook(data)
    PreCallHook->>PipelineExec: _maybe_execute_pipelines(data)
    loop For each pipeline
        loop For each step in pipeline
            PipelineExec->>Guardrail: async_pre_call_hook(data)
            alt Guardrail passes
                Guardrail-->>PipelineExec: pass (optional modified data)
                Note over PipelineExec: Use step.on_pass action
            else Guardrail rejects (HTTPException 400)
                Guardrail-->>PipelineExec: fail
                Note over PipelineExec: Use step.on_fail action
            end
            alt Action = allow/block/modify_response
                PipelineExec-->>PreCallHook: Terminal result
            else Action = next
                Note over PipelineExec: Continue to next step
            end
        end
    end
    PipelineExec-->>PreCallHook: PipelineExecutionResult

    loop Normal callback loop
        Note over PreCallHook: Skip pipeline-managed guardrails
        PreCallHook->>Guardrail: process remaining guardrails
    end
    PreCallHook-->>Client: data (or raise on block)

Loading

_{Last reviewed commit: 7269d9a}

[greptile-apps]

_{26 files reviewed, 5 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Error outcomes use on_fail but "error" is a distinct condition from "fail"

When a guardrail is not found or throws an unexpected exception, _run_step returns "error" as the outcome. But here, any non-"pass" outcome (including "error") uses step.on_fail. This means a misconfigured guardrail name (typo) with on_fail: "next" would silently continue instead of surfacing the configuration error. Consider handling "error" outcomes separately to make misconfiguration more visible.