Integration
Guardrails & checkpoints for n8n AI workflows
n8n made it easy to give an AI agent real tools – a Gmail trigger, an HTTP node, a database write – and it now ships a built-in Guardrails node that checks or sanitizes text at points you place it. Use it; it is a good local filter. What it cannot be is the boundary: it guards the text passing one node, not the actions, budgets, and ordering of the whole run. That is the layer in/guard/out adds.
Side by side
| Capability | n8n Guardrails node | in/guard/out |
|---|---|---|
| Where it guards | One node’s text, where you place it | Every model call, tool call, and gated workflow step – placed once |
| Coverage model | Per-node, per-workflow, by hand | On the wire: covers the nodes nobody remembered to wrap |
| PII handling | Detect, then block or sanitize – one-way | Screen to stable placeholders, restored on response |
| Jailbreak / NSFW / topic checks | Built in – LLM-based, threshold-tuned (bring a chat model) | Pattern layer plus dedicated classifiers, sub-calls metered into run cost |
| Hallucination & numeric grounding | — | Deterministic grounding + fact-check judge on responses |
| Tool-call policy & permission tiers | — | Allow/deny, JSON-schema args, risk tiers, approval gates |
| Non-LLM steps (the bank-API call itself) | — | Checkpoint node asks the policy engine: allow / deny / require-approval |
| Workflow-aware ordering | — | Your workflow export compiles into policy, enforced as a state machine |
| Cross-run budgets & loop detection | — | Per-run cost / step / tool budgets, runaway-loop guard |
| Audit trail | Node execution logs | One reconstructed run graph: model calls, tool calls, checkpoints, cost |
| Cost | Free with n8n (LLM checks spend your model tokens) | Metered per request; every guard sub-call priced and shown |
Why a node inside the workflow isn’t enough
The failure mode n8n agents actually suffer is documented and fraud-shaped: a poisoned email or order note steers the agent, and a workflow node executes the result with production credentials. A text filter at the input helps – n8n’s Guardrails node runs keyword, PII, secret-key, URL, jailbreak, NSFW, and topical checks, and cheap early rejection is worth keeping. But the attack lands at the action: the HTTP call to the bank API, the send to the customer list. Text checks don’t see actions, and a node the flow routes around checks nothing.
The integration meets the workflow where it is, three ways. AI nodes point at the in/guard/out base URL, so every model call runs the pipeline. The Guardrails Checkpoint community node drops in front of consequential steps – the bank-API call, the bulk email – and asks the policy engine “may I proceed?”, honoring allow, deny, or require-approval. And the category-unique piece: upload your workflow export and it compiles into a runtime sequence policy, so the diagram you already drew becomes the ordering rules in/guard/out enforces – payments only after a vendor lookup, sends capped per run.
Setting it up with in/guard/out
1. Repoint the AI nodes
Set the in/guard/out base URL and your gr- key in the AI model credentials. Model traffic – including the agent’s tool_call decisions – now crosses the pipeline.
2. Drop in the Checkpoint node
Install the Guardrails Checkpoint community node and place it before consequential nodes. Deterministic steps that don’t touch an LLM get gated by the same policies.
3. Import the workflow as policy
Export your workflow JSON and upload it in the Keys tab – it compiles into a sequence policy enforced as a state machine over each run’s tool history.
4. Watch the run graph
Each execution appears as one reconstructed run – model calls, tool calls, checkpoints – with violations, tiers, and cost burn-down in one trace.
Frequently asked questions
n8n now has a built-in Guardrails node – why add anything?
Keep it – it is a useful local filter (keywords, PII, secrets, URLs deterministically; jailbreak, NSFW, topic via an LLM you attach). What it structurally can’t do: restore what it redacts, see tool calls or actions, gate the non-LLM node that actually moves money, enforce ordering across the run, or hold a budget. Those need enforcement outside the flow being guarded.
Do I have to redesign my n8n workflow?
No. The base-URL change is a credentials edit; the checkpoint node is an added node in front of steps you already have; the workflow import needs only your existing export file.
What does the workflow import actually produce?
A sequence policy: the allowed orderings and limits implied by your diagram, compiled into rules in/guard/out enforces at runtime – flag in FIX, block in PREVENT. When the agent improvises a path your diagram didn’t draw, that is a violation.
What happens when the checkpoint says require-approval?
The node returns the decision to your workflow, which routes accordingly – park the item, ping Slack, wait for sign-off. The decision and its resolution are recorded in the same run as everything else.
Can it stop the swapped-IBAN invoice attack?
That scenario is the worked example on our fintech page: the injection scan flags the poisoned email, action grounding blocks the IBAN that appears nowhere in the invoice, the sequence policy requires the vendor lookup, and the payment tier parks it on approval. Four independent layers.
Related
Compile your n8n workflow into policy
Point your AI nodes at in/guard/out and drop in the checkpoint node - your workflow export becomes the enforcement. We are running a limited demo - sign up and we will get you in as soon as we can.