Skip to main content

Guardrails as Tool steps

In addition to being a side-panel setting on agent inputs/outputs and individual step nodes, each guardrail is available as its own Tool step. Drop it into a Tool's step graph as a node and wire it up like anything else.

Why use guardrails as steps​

Use the step form when:

  • You want validation mid-graph — not just on the agent's overall input or final output.
  • You need a guardrail's structured result (pass/fail, modified content, detected entities) as a value flowing into downstream logic.
  • You want guardrails on a Tool that runs outside an Agent — e.g., an API-callable Tool.

The step form gives you a real graph node with inputs, outputs, and execution rules — not just a side-panel toggle.

Adding a guardrail step​

In the Tool builder, open the + User Step picker. Each guardrail (Detect PII, Competitor Check, Toxic Language, Gibberish, Bias Check, Prompt Injection, Logic Check, Reading Level, Reading Time) appears as its own step type.

Pick one and configure it.

Configuration — same fields as agent guardrails, except input/output​

The configuration UI for a guardrail step matches the corresponding agent guardrail. The same parameter fields show up:

  • Detect PII — PII Entities to detect, corrective action.
  • Competitor Check — competitor list, corrective action.
  • Toxic Language Check — threshold, validation method, corrective action.
  • Gibberish Text — threshold, validation method, corrective action.
  • …and the same applies to Bias Check, Prompt Injection, Logic Check, Reading Level, Reading Time.

One difference: in a guardrail step, there is no "Input vs Output" field selection. The step takes whatever value you wire into its input — the field selection is implicit. You decide what to pass in by your wiring.

Step input and output​

  • Input — the value to validate. Wire it from any upstream variable using {{ }} Jinja templating.
  • Output — the guardrail's structured result, available to downstream steps.

The exact shape of the output depends on the guardrail and the corrective action:

  • FIX corrective action — the output includes the modified content (e.g., redacted version of the input).
  • NOOP — the output includes a flag indicating whether the validator triggered + the original content unchanged.
  • Exception — the step throws, halting execution. Downstream steps don't run.

Refer to the step's runtime output in the Tool builder's debug panel for the exact shape.

Patterns​

Validate user input before LLM reasoning​

Place a Prompt Injection step near the Start Point. Wire the latest user message into it. If it triggers (Exception), the rest of the Tool never runs.

Filter LLM output before returning to user​

Place a Toxic Language or Detect PII step right before the Outputs / Final Output node. Wire the LLM's output into it with FIX as corrective action — the cleaned value flows to the user.

Conditional logic on guardrail results​

Use a guardrail step with NOOP corrective action, then read its output's "triggered" flag in a downstream step's Execution Rules condition — branch the graph based on whether the validator fired.

When to use the side-panel form instead​

For the simple "validate the agent's input, then validate the agent's output" pattern, the agent-level guardrails (with project-level named configs — see Project-level policies) are simpler. Reach for the step form when you need mid-graph validation or structured guardrail results.