Workflows
Blocks
Actions
Guardrails

Guardrails

The Guardrails block checks text against safety and policy rules before your workflow acts on it. Use it to filter incoming user messages, or to check AI responses before they are sent out.

It is a branching block with two outputs:

  • Pass — every enabled check passed. Continue the normal flow.
  • Fail — at least one check failed. Route to a fallback (e.g. a polite refusal message or human review).

Two positions: Put a Guardrails block right after a trigger to screen user messages, or right after an AI block to screen AI responses before delivery.

Key Features

  • Pass / Fail Branching: Connect each outcome to its own flow
  • Input and Output Modes: Choose whether you are checking user messages or AI responses
  • Built-in Checks: Toggle ready-made guardrails — no prompts to write
  • Custom Guardrails: Add your own rules in plain English
  • Result Variables: Save the overall result and per-check details into variables

Configuration

ParameterTypeRequiredDescription
Response typeDropdownYesUser Messages (input) or AI Responses (output)
Text to checkTextYesThe text to evaluate, e.g. {{user_message}} or {{ai_response}}
Default guardrailsTogglesNoThe built-in checks listed below
Custom guardrailsListNoYour own plain-English rules
Response mappingListNoSave results into workflow variables

Default guardrails — User Messages (input)

ToggleWhat it doesExtra settings
Block API keys & passwordsBlocks messages containing secrets like API keys or passwords—
Block prompt injectionDetects attempts to override your bot's instructions—
Block jailbreak attemptsDetects jailbreak-style promptsDetection threshold (0–1)
Block prompt leakingBlocks attempts to make the bot reveal its system prompt—
Block offensive languageFilters toxic or abusive messages—
Stay on topicOnly allows messages about your listed topicsAllowed topics
Language filterOnly allows messages in the languages you listLanguages
Block spam & gibberishFilters random characters and incoherent messagesDetection threshold (0–1)
Limit message lengthBlocks messages over a token limit (protects against context-stuffing; ~4 characters per token)Max tokens (min 100)

Default guardrails — AI Responses (output)

ToggleWhat it doesExtra settings
Prevent hallucinationsChecks the response against a trusted document for factual accuracyReference document
Block harmful responsesFilters toxic, hateful, or harmful content before users see it—
Enforce response formatFails responses that are not in the expected formatExpected format: JSON, Markdown, Plain Text, or Custom (with your own format description)
Brand voice checkChecks the response against your tone and style rulesBrand voice guidelines
Block competitor mentionsFails responses that mention listed competitorsCompetitor names
Enforce company policiesChecks the response against your written policiesYour policy rules
Require minimum confidenceFails when the AI's confidence in its own response is below the thresholdMinimum confidence score (0–1)

Custom guardrails

Click Add guardrail to write your own rule. No coding needed — each rule has:

FieldDescription
Guardrail nameShort label, e.g. No Discount Over 20%
RuleThe rule in plain English, e.g. "Never suggest a competitor product"

Setting up the block

  1. Add the Guardrails block where you want the check (after the trigger for input, after the AI block for output).
  2. Set Response type to User Messages or AI Responses.
  3. Set Text to check to the variable holding the text.
  4. Toggle the default guardrails you need and fill in their extra settings.
  5. Add any custom guardrails.
  6. Connect the Pass output to the normal flow and the Fail output to your fallback flow.

Example: Safe support bot

Trigger → Guardrails (User Messages: Block prompt injection + Block offensive language + Stay on topic: "product support") → LLM Agent → Guardrails (AI Responses: Block harmful responses + Block competitor mentions) → Send reply.

If either check fails, the Fail branch sends "Sorry, I can't help with that" instead.


Save answer

Use Response mapping to store results in variables:

ValueDescription
Overall result (true/false)true when every enabled check passed
All check results (JSON)The result of every check that ran
Failed checks only (JSON)Only the checks that failed, with reasons
Indite Documentation v1.7.1
PrivacyTermsSupport