5 Ways to Stop Data from Leaking Out of Your n8n AI Workflows An n8n developer outlines five methods to prevent data leakage from AI workflows, including tokenization via Code nodes and the native Guardrails node (available since v1.113.3). The Guardrails node offers pattern-based PII detection and sanitization without external services, while tokenization requires custom JavaScript but works without installation. Both approaches have tradeoffs: tokenization leaves the PII map in execution logs, and Guardrails redacts data permanently unless additional logic is added. If you're running AI workflows in n8n that touch real customer data — emails, phone numbers, account IDs, health records — that data is almost certainly reaching external LLM APIs in plain text. n8n execution history stores every node's input and output by default, which means anyone with instance access can read raw PII from your logs. This post covers five concrete approaches, from zero-dependency quick fixes to production-grade solutions, with real tools, install instructions, and honest tradeoffs for each. A typical n8n AI workflow looks like this: Webhook → Pull customer record → Build prompt → OpenAI → Send response By the time that prompt hits OpenAI, it might contain: Summarize the support case for john.doe@company.com, SSN 999-88-7777, account 48291, phone 555-304-8821. Issue: {{ $json.description }} Every field there is PII. It's going to OpenAI's infrastructure. It's sitting in your n8n execution logs. And unless you've taken specific steps to prevent it, it will keep doing that silently. What it is: Write JavaScript in an n8n Code node to replace sensitive fields with tokens before the LLM node, then reverse it afterward. Setup: No installation needed. Add a Code node before your LLM node. js // "Tokenize" Code node — Run Once for All Items const map = {}; let counter = 1; function token value, kind { const t = ${kind} ${String counter++ .padStart 3, '0' } ; map t = value; return t; } const input = $input.first .json; return { json: { safe prompt: Summarize the case for ${token input.email, 'EMAIL' }, account ${token input.account id, 'ACCT' }, phone ${token input.phone, 'PHONE' }. Issue: ${input.description} , pii map: map } } ; Then after your LLM node, a second Code node to restore values: js // "Detokenize" Code node let response = $input.first .json.message.content; const map = $ 'Tokenize' .first .json. pii map; for const token, value of Object.entries map { response = response.replaceAll token, value ; } return { json: { response } } ; What it actually covers: What it misses: pii map still appears in execution logs if you're not careful Best for: Prototyping. One-off workflows where you know exactly which 2–3 fields carry PII and you won't forget to update the code when the schema changes. What it is: A native n8n node available since v1.113.3, November 2025 that sits between your data and your LLM node. No external services required for pattern-based checks. Setup: Update n8n to at least v1.113.3. The Guardrails node appears in the node search — no installation needed. The node has two modes: Check Text for Violations — scans text against selected policies and routes to a Fail branch if anything triggers. You then decide what to do: halt the workflow, log the attempt, return a safe fallback. Sanitize Text — redacts detected content in-place and replaces it with placeholders like EMAIL ADDRESS or PHONE NUMBER . The workflow keeps running with the cleaned text. A typical pattern: Webhook → Guardrails Sanitize → OpenAI → Response Available guardrails include: PII detection 20+ entity types: emails, phones, credit cards, SSNs, IBANs, passports, driver's licenses, medical licenses, and country-specific formats , Secret Keys, Keywords, URLs, Custom Regex, Jailbreak detection LLM-based , NSFW detection LLM-based , and Topical Alignment. For PII specifically, the Sanitize mode catches structured entities via pattern matching — no API call required, no latency added. Jailbreak and NSFW detection require a connected LLM node and add one API call per check. What it actually covers: What it misses: EMAIL ADDRESS , not the original. For workflows where you need the real value restored after the LLM call, you'll need additional logic. Best for: Adding a first layer of protection to user-facing chatbots and intake workflows. Excellent for blocking jailbreaks and catching structured PII on input. Not enough on its own if your workflow composes prompts from data pulled across multiple nodes. What it is: An open-source n8n community node GitHub https://github.com/rehydra-ai/n8n-nodes-rehydra , npm https://www.npmjs.com/package/n8n-nodes-rehydra built on the Rehydra SDK. Handles both anonymization and rehydration — meaning it can restore original values after the LLM responds. Setup: Self-hosted n8n → Settings → Community Nodes → Install → enter n8n-nodes-rehydra . Or via CLI: npm install n8n-nodes-rehydra Three nodes in the package: Rehydra: Anonymize — replaces detected PII with XML-style tags: