Using Guardrails in n8n
Introduction
The Guardrails node is n8n's native safety and content-policy node. It lets you validate text — user input on its way into an AI model, or a model's response on its way out — against a configurable set of checks, without writing custom validation code or wiring up an external moderation service.
Within your GLBNXT-hosted n8n environment, the Guardrails node is a good fit anywhere your workflows expose an LLM to end users: support bots, internal AI agents, form-to-AI pipelines, and anything that forwards free-text input to a model you're paying for by the token.
Why use Guardrails?
Sending unvalidated text straight into an AI model — or straight back out to a user — exposes your workflow to a few recurring failure modes. The Guardrails node addresses these directly:
Prompt injection & jailbreaks: Users (or documents fed into RAG pipelines) can try to override your system prompt. The Jailbreak guardrail uses an LLM to catch intent, not just keywords.
PII and secret leakage: Support tickets, chat messages, and scraped documents regularly contain data you don't want logged, embedded, or forwarded — emails, phone numbers, credit card numbers, or API keys. The PII and Secret Keys guardrails catch this before it propagates.
Off-topic or NSFW output: Public-facing agents can be steered off-brief. Topical Alignment and NSFW keep responses inside the scope you define.
Uncontrolled outbound links: AI-generated text can contain fabricated or malicious URLs. The URLs guardrail lets you allow-list only the domains you trust.
Because the node is native to n8n, it runs as part of your existing workflow — no extra API calls to a third-party moderation service, and no additional data leaving your GLBNXT environment for pattern-based checks.
❗ Note: Guardrails add processing time per item, and LLM-based checks (Jailbreak, NSFW, Topical Alignment, Custom) each make a call to your connected chat model. This node is designed for validating individual messages or documents in real time — not for bulk-cleaning large datasets. If you're processing more than a handful of items per execution, validate with a Code node or a dedicated data-quality tool instead.
Prerequisites
Before adding the Guardrails node to your workflow, make sure you have:
n8n Environment: An active instance of n8n running within your secure GLBNXT workspace.
A Chat Model node: Required only if you plan to use LLM-based guardrails (Jailbreak, NSFW, Topical Alignment, or Custom). Connect any chat model available in your GLBNXT stack to the node's Model input.
n8n version 1.113.3 or later: The Guardrails node ships as a core node from this version onward. If it doesn't appear in your nodes panel, check your instance version in the GLBNXT platform and update if needed.
Installation
Step 1: Add a Guardrails Node
Create a new workflow or open an existing one.
Open the nodes panel by selecting + or pressing N.
Search for Guardrails and add it to your workflow, typically between the node producing the text (a form trigger, chat trigger, or AI Agent) and the node that consumes it.
Step 2: Connect a Chat Model (if using LLM-based checks)
If you plan to use Jailbreak, NSFW, Topical Alignment, or a Custom guardrail, connect a Chat Model node to the Guardrails node's Model input, the same way you would for an AI Agent node. Pattern-based guardrails (Keywords, PII, Secret Keys, URLs, Custom Regex) don't require this connection.
Step 3: Configure the Node
Set Operation:
* Check Text for Violations — runs the full set of guardrails and routes items to a Pass or Fail output.
* Sanitize Text — runs a subset of guardrails (URLs, Custom Regex, Secret Keys, PII) and replaces detected violations with placeholders instead of blocking the item.
Set Text To Check — typically an expression pointing at the incoming user message or the AI model's response, e.g.
{{ $json.chatInput }}.Under Guardrails, add one or more checks from the list and configure each (see Configuration below).
Wire the Pass output to the rest of your workflow (the AI Agent call, or returning the response to the user), and the Fail output to whatever handling you want — logging, a static rejection message, or an alert to your team.
Configuration
This section covers all guardrails available in the node. Combine several to cover the input and output risks relevant to your workflow.
1. Pattern-Based Guardrails
These run locally against the text and don't require a connected chat model.
Keywords
Type:
string(comma-separated list)Default: Empty
Description: Blocks the input if any of the listed words appear.
Useful Scenario: Block mentions of competitor names in a customer-facing sales assistant, or filter out a known list of profanity.
PII
Type:
Selection(AllorSelected)Default:
AllDescription: Detects personally identifiable information such as emails, phone numbers, credit card numbers, and social security numbers. When set to
Selected, choose specific entity types (for example,EMAIL_ADDRESS,CREDIT_CARD,PHONE_NUMBER,US_SSN).Useful Scenario: Prevent customers from accidentally pasting a credit card number into a support chatbot, or strip PII from tickets before they're summarized and stored.
Secret Keys
Type:
Selection(Strict,Permissive,Balanced)Default:
BalancedDescription: Detects patterns that look like API keys or credentials in the text.
Useful Scenario: Catch a developer accidentally pasting an API key into an internal AI assistant before it's logged or sent to an external model.
URLs
Type: Configuration group
Default: All URLs blocked unless allow-listed
Description: Flags URLs in the text as violations unless they appear in Block All URLs Except. Also lets you restrict allowed Schemes (
https,http,ftp,mailto), block URLs containing embedded credentials (Block userinfo), and automatically trust subdomains of an allowed domain (Allow subdomain).Useful Scenario: Ensure an AI agent only ever surfaces links to your own domain (e.g.
glbnxt.com) rather than fabricated or unverified URLs.
Custom Regex
Type:
string(regex pattern) +NameDefault: Empty
Description: Define your own pattern for anything the built-in checks don't cover. The Name is used as the placeholder text when running in Sanitize Text mode.
Useful Scenario: Match an internal ticket-ID format or account-number pattern specific to your business.
2. LLM-Based Guardrails
These require a Chat Model connected to the node's Model input.
Jailbreak
Type:
booleantoggle +Threshold(0.0–1.0)Default Threshold: Model-dependent; start around
0.7Description: Detects attempts to bypass the AI's safety instructions or manipulate it into ignoring its system prompt. Customize Prompt lets you edit the underlying detection prompt.
Useful Scenario: Protect a public-facing support agent from users trying to extract your system prompt or get the model to act outside its intended role.
NSFW
Type:
booleantoggle +Threshold(0.0–1.0)Default Threshold: Model-dependent; start around
0.7Description: Detects attempts to generate Not Safe For Work content. Customize Prompt lets you edit the underlying detection prompt.
Useful Scenario: Keep a customer-facing chatbot's output appropriate regardless of what a user tries to prompt it with.
Topical Alignment
Type:
Prompt(defines allowed scope) +Threshold(0.0–1.0)Default: Empty prompt (must be configured)
Description: Confirms the text stays within a business scope you define. A higher threshold flags more aggressively as off-topic.
Useful Scenario: Keep a product-support assistant from answering unrelated general-knowledge questions, keeping usage (and token spend) on-brief.
Custom
Type:
Name+Prompt+Threshold(0.0–1.0)Default: Empty
Description: Define your own LLM-evaluated check — anything you can describe in a prompt.
Useful Scenario: Flag overly aggressive tone in incoming support messages before they reach a human agent, or check that generated marketing copy doesn't make unverifiable claims.
3. Global Behavior
Customize System Message
Type:
booleantoggleDefault:
false(uses n8n's default system message)Description: Exposes the system message the node uses internally to enforce thresholds and structure the model's JSON output. Edit it to fine-tune behavior across all LLM-based guardrails at once.
Useful Scenario: Adjust how strictly the model interprets thresholds across your whole guardrail set, rather than tuning each check individually.
Troubleshooting
Issue: LLM-based guardrails aren't evaluating / node throws a connection error
Cause: No Chat Model node is connected to the Guardrails node's Model input.
Solution: Connect a Chat Model node the same way you would for an AI Agent node. Pattern-based guardrails (Keywords, PII, Secret Keys, URLs, Custom Regex) will still run without it.
Issue: Legitimate messages are being blocked (false positives)
Cause: Thresholds on Jailbreak, NSFW, Topical Alignment, or Custom guardrails are set too low (more sensitive), or a Keywords/Regex list is too broad.
Solution: Raise the relevant threshold incrementally and re-test with real examples from your domain rather than synthetic ones. Log Fail-branch items during testing so you can review what's being caught.
Issue: Workflow is noticeably slower after adding Guardrails
Cause: Each LLM-based guardrail makes a separate call to your connected chat model, and the node evaluates every item individually.
Solution: Limit LLM-based checks to what you actually need, and avoid running the Guardrails node over batches of more than a handful of items per execution. For bulk validation, move the logic to a Code node or a dedicated data-quality tool instead.
Issue: Sanitize Text isn't replacing everything you expect
Cause: Sanitize Text only supports a subset of guardrails — URLs, Custom Regex, Secret Keys, and PII. Jailbreak, NSFW, Topical Alignment, and Custom guardrails are only available under Check Text for Violations.
Solution: Use Check Text for Violations upstream if you also need to catch jailbreak or off-topic attempts, and route failed items to a Fail branch rather than expecting them to be sanitized.
Need help? Contact the GLBNXT support team or ask a GLBNXT agent to walk you through the setup.
Last updated
Was this helpful?