The Problem: Memory Poisoning in n8n AI Agent Workflows
n8n’s AI Agent nodes are increasingly used in production workflows where agents read from external sources (web scraping, email parsing, document ingestion) and write results into memory or pass them to downstream nodes.
This creates a critical attack surface known as ASI06 — Memory Poisoning, defined in the OWASP Top 10 for Agentic Applications 2025.
The attack: A malicious payload embedded in an external source (e.g., a webpage, email, or document) is processed by an AI Agent node and written into the workflow’s memory or context. Downstream nodes then execute based on the poisoned memory, leading to data exfiltration, incorrect outputs, or full workflow compromise.
The Request
I’d like to request a built-in memory scan / validation step in n8n’s AI Agent nodes that:
- Scans content before it is written to memory or passed to downstream nodes
- Detects prompt injection patterns, jailbreak attempts, and indirect instruction overrides
- Optionally blocks or flags suspicious content with a configurable policy (block / warn / log)
Reference Implementation
The OWASP Agent Memory Guard project provides a lightweight reference implementation of exactly this scan-before-write pattern. It is already being discussed and adopted by maintainers of LangGraph, LiteLLM, AutoGen, and other major frameworks.
Happy to provide more technical detail or a prototype integration if helpful.
oi @Vaishnavi_Gudur,welcome to the n8n community!
The concern makes sense, especially since n8n already provides AI Agents, memory handling, and orchestration for agentic workflows. It also already offers some building blocks for protection layers, such as Guardrails and human review, although the current documentation does not appear to describe a native “scan-before-write” protection specifically for AI Agent memory persistence.
That said, it is still somewhat debatable whether prompt injection and memory poisoning protections should live in the n8n core itself or be handled at the application/provider layer. The proposal may be stronger if positioned as optional/extensible guardrails or validation hooks rather than a fully automatic protection layer built directly into the runtime.
1 Like
@tamy.santos — thank you, that’s exactly the right reframe. You’re correct that baking this into core is the wrong ask. What I should have proposed is an **optional Memory Guard node** — similar to how n8n already has a Code node or HTTP Request node that you wire in only where you need it.
The workflow pattern would be:
```
External Source → AI Agent Node → [Memory Guard Node] → Memory Store
```
The Memory Guard node would:
- Accept the agent’s output as input
- Run a scan via `agent-memory-guard` (pip-installable, ~50ms per call)
- Return either the original content (if clean) or a flagged/blocked result
- Let the workflow branch on the result: write to memory if clean, route to a human review queue if flagged
A native **Memory Guard node** in n8n’s node library would expose the policy (block/warn/log), detector sensitivity, and OWASP ASI06 threat category as node parameters, with no code required.
Would you happen to know the best person on the n8n team to tag for this? Or is the upvote + forum post the right channel for getting it onto the roadmap?
1 Like
@Vaishnavi_Gudur
To implement this, the safest approach would probably be to start as a Community Node, following the official n8n node creation documentation: Overview | n8n Docs
2 Likes
hi @Vaishnavi_Gudur Welcome to our community!
First off, @tamy.santos is absolutely correct regarding the “LLM Judge Trap” when testing native safety features.
I have built a complete, copy-pasteable JSON example of this exact workflow so you can test it out:
Testing Note (The “LLM Judge” Trap): When testing the Guardrails node, make sure the Language Model connected directly to the Guardrails node is a capable reasoning model (like gpt-4o-mini, claude-3-5-haiku, or at least an 8B/70B local model).
2 Likes