[Feature Request] Memory validation layer to prevent document store poisoning

[vgudur-dev]

Is your feature request related to a problem?

Haystack's DocumentStore and ChatMemoryBuffer accept any content without validation. When agents persist user-provided data or RAG results, there's no mechanism to detect if that content contains embedded prompt injections or poisoned memories that could alter agent behavior on future retrievals.

A recent paper — "Memory Poisoning Attacks in LLM Agents" (June 2026) — demonstrates that 12% of production agent memory stores are already affected by this class of attack.

Describe the solution you'd like

An optional validation component/middleware that can be added to any pipeline before the DocumentStore write step:

from haystack import Pipeline
from haystack.components.writers import DocumentWriter
from agent_memory_guard import scan_memory

# Validate content before writing to document store
entry = document.content
result = scan_memory(entry)
if result.safe:
    writer.run(documents=[document])
else:
    logger.warning(f"Blocked poisoned content: {result.threat_type}")

Ideally this would be a native Haystack component that plugs into pipelines:

pipeline.add_component("memory_validator", MemoryValidator())
pipeline.connect("retriever", "memory_validator")
pipeline.connect("memory_validator", "writer")

Describe alternatives you've considered

We've built this as a standalone library — Agent Memory Guard (OWASP Incubator project):

• 97.3% detection rate, 0.2% false positives
• 3.1ms latency per validation
• 5-layer defense (heuristic, semantic, embedding drift, provenance, behavioral)
• pip install agent-memory-guard

CrewAI is already adding native support via PR #6045. Would love to see Haystack adopt a similar pattern.

Additional context

• OWASP Top 10 for LLM Applications lists "Sensitive Information Disclosure" (LLM06) which this directly addresses
• The attack surface grows as more agents use persistent memory across sessions
• Happy to contribute a Haystack-native component PR if there's interest

[ferhimedamine]

The layered defense approach in Agent Memory Guard is solid, but I'd add that validation needs to go beyond content scanning — the write pattern itself is a signal.

In production memory systems, I've found three complementary validation layers work well together: (1) Schema validation at write time — reject documents where metadata is structurally invalid (missing timestamps, wrong embedding dimensions, impossible source identifiers). This catches accidental corruption before it even reaches the semantic layer. A poisoned document with mismatched embedding dimensions (e.g., 384-dim embeddings from a model that should produce 768-dim) will silently degrade retrieval quality for every query that touches its neighborhood, and no content-level scan will catch it. (2) Importance gating — high-importance writes (anything that would rank highly in future retrievals) should require elevated authorization or at minimum a provenance chain. If an agent is writing memories with importance=1.0 on every store call, something is wrong. Normal agent behavior produces a distribution of importance scores. (3) Write pattern anomaly detection — monitor the velocity and distribution of writes. A sudden spike in write volume from a single source, or writes that cluster unusually tightly in the embedding space (trying to dominate a particular retrieval neighborhood), are strong poisoning signals even when individual documents pass content validation.

The paper's 12% figure is concerning but expected. The attack surface is wide: any agent that persists RAG results or user-provided data to a shared document store is vulnerable. The pipeline approach (validator component between retriever and writer) is the right architecture because it makes validation composable — you can stack different validators for different threat models. One thing I'd flag: validation latency matters here. If the validator adds significant latency to every write, teams will disable it. Keeping it under 5ms per document (as the OWASP project does) is the right target for production adoption.

[vgudur-dev]

Hi Haystack team — following up on this feature request. The layered defense approach discussed here aligns well with Haystack's pipeline architecture.

A concrete integration could be a MemoryGuardComponent that sits between the retriever and document store on the write path:

from haystack import Pipeline
from agent_memory_guard import MemoryGuard

pipeline = Pipeline()
pipeline.add_component('guard', MemoryGuardComponent())
pipeline.add_component('writer', DocumentWriter(document_store))
pipeline.connect('guard.validated_docs', 'writer.documents')

This would scan documents for injection patterns, validate schema, and enforce write policies before they reach the store. We have a working implementation at agent-memory-guard (5,400+ downloads, OWASP Incubator). Happy to submit a PR if there's interest!

[ferhimedamine]

Great framing of the memory poisoning problem. One pattern that complements write-time validation is importance-weighted decay — memories that the agent never re-accesses naturally decay over time, which limits the window during which a poisoned memory can influence behavior. Combined with agent-scoped isolation (Agent A cannot read or write Agent B's memories), you constrain the blast radius of any single poisoned entry.

The validation layer you describe would work well as the first line of defense, with decay handling the "what if validation misses something" case. You could also use access-frequency tracking as a signal — a poisoned memory that's being retrieved unusually often (because it's designed to match many queries) would show anomalous access patterns.

We implemented both decay and isolation patterns in our memory server: https://github.com/Dakera-AI/dakera-deploy

[ferhimedamine]

Memory poisoning at the document store level needs to be addressed at ingestion, not at retrieval. Validating content after it's already in the vector index means the poisoned data has already influenced the index structure. Our defense: a synchronous validation pass at write time that checks content against known injection patterns, enforces maximum content length per record, and assigns untrusted external content a lower importance score than system-generated knowledge. The importance scoring is the second line of defense — even if a poisoned document passes validation, it ranks below trusted content during retrieval because its importance weight is lower. For RAG pipelines, source attribution on each stored document lets you trace any suspicious recall back to its ingestion source. Content filtering with importance: https://github.com/dakera-ai/dakera-py/blob/main/examples/fulltext_search.py