n8n: Part 6 — Guardrails Node: Protecting LLM Workflows

n8n workflows using language models carry two types of risks. On the input side, a user can send personal data, an API key, or an attempt to “jailbreak” the model’s instructions. On the output side the model can produce an inappropriate response, someone else’s link, or leak something that was included in its context. Previously these checks were assembled manually from IF nodes, regular expressions, and additional model calls. The Guardrails node consolidates them in one place.

Two operations

According to n8n documentation the node has two operations:

• Check Text for Violations — checks the text against a selected set of rules. If at least one rule is violated, the item goes to the Fail branch; otherwise — to Pass.
• Sanitize Text — does not block the text, but finds violations and replaces them with placeholders, for example replacing an email address with a label.

Typically the node is placed twice: before calling the model (to check or sanitize input) and after it (to check the response before sending it to the user or another system).

Types of checks

Checks that are performed by the model (Jailbreak, NSFW, Topical Alignment, Custom) require a connected chat-model node and have a threshold from 0.0 to 1.0. The lower the threshold, the stricter the check and the more false positives.

Example: support assistant

Task: customer messages arrive via a webhook, the model prepares a reply, the reply goes to the customer.

1. Webhook receives the message.
2. Guardrails, Sanitize Text with PII and Secret Keys checks — phone numbers, email addresses and accidentally included keys are replaced with placeholders before the text reaches the model and the execution logs.
3. Guardrails, Check Text for Violations with a Jailbreak check — attempts to override instructions go to the Fail branch, where the workflow responds with a standard phrase and logs the event.
4. AI Agent or model node prepares the response.
5. Guardrails, Check Text for Violations on the response: Topical Alignment (“only questions about the product and orders”) and URLs with an allowlist of your domains.
6. The Pass branch sends the reply to the customer; the Fail branch escalates the request to an operator.

What to consider

• Model-based checks cost money and time. Each of them is an additional model call. For a flow handling thousands of messages per day this is a noticeable expense and a response delay. Put cheap checks (Keywords, PII, Secret Keys, URLs, Custom Regex) first.
• Sanitization does not remove legal obligations. If personal data already arrived in the webhook, it passed through your n8n server and may have been saved in the execution history. Retention periods for history are configured separately — see the second part of the series.
• A cloud model means data transmission. For Russian companies, transferring personal data to an overseas model provider is a separate legal issue; sanitization before the call reduces the risk but does not fully resolve it.
• Thresholds are tuned on real data. Run a set of real requests through the workflow and see how many legitimate messages are filtered out.

Common mistakes

• Having only an output check and sending uncleaned input to the model.
• Making the Fail branch a dead end: the user doesn’t receive a reply and the operator is unaware of the request.
• Using the same model and the same prompt for checks as for the reply: the same vulnerability bypasses both.
• Not reviewing the execution history: without it it’s unclear which rules are producing false positives.

Guardrails does not make a language-model workflow safe by itself, but replaces dozens of homemade checks with a single clear node that is easy to maintain.