FlowDSL Node Catalog

LLM Guard

Classify a message with a safety model (Qwen3Guard, Llama-Guard). Routes to Allow / Flag / Block based on the verdict.

Overview

PropertyValue
Node IDredelay/llm-guard
Kindrouter
Modulellm-flowdsl
Repogo-ai

Inputs

  • Message — Candidate message. If content is empty, the node reads the last message from the messages array (handy when chaining after llm-chat).

Outputs

  • Allow — Guard verdict is Safe — forward the original packet downstream.
  • Flag — Guard verdict is Controversial — record but don't block.
  • Block — Guard verdict is Unsafe — short-circuit with a rejection reason.

Settings

PropertyTypeRequiredDefaultUI GroupDescription
guardIDstring ()———Registered guard backend ID. Enum is populated at runtime from the live guard registry. Required when no profile is selected.
onErrorstring (allow|block)—allow—What to do when the guard model itself fails. allow keeps the flow open (fail-open); block short-circuits to the Block branch.
profilestring ()———OPTIONAL — pick a named LLM Guard profile (backend + upstream provider + credentials + model). Lets you run multiple guard configs side-by-side: fast vs accurate, different OVH accounts, OVH vs local Ollama, etc. Leave blank to configure each knob directly below. role (user / assistant) and onError (fail-open / fail-closed) stay per-node — the same profile typically drives guard-in with role=user and guard-out with role=assistant. Manage profiles at /profiles — duplicate an existing guard profile to spin a variant (e.g. swap Qwen3Guard-Gen-8B for Qwen3Guard-Gen-0.6B for a faster-but-less-accurate mode).
rolestring (user|assistant)—user—Whose message is being checked. user applies user-policy classifications, assistant applies assistant-policy ones.

Example

yaml
# Use this node in a flow:
nodes:
  - id: my_step
    name: My Step
    kind: router
    action_ref: redelay/llm-guard
    config:
      guardID: "value"
      onError: allow
      profile: ""
      role: user