EVIDENCE TRAIL
Memory content validation
Verbatim excerpts from the upstream sources cited on the mitigation page, with what each source does and does not prove. The write-boundary framing ("validate at the write boundary, not the read boundary") is Helmwart's synthesis — upstream sources name the control class but do not consistently distinguish write-time from read-time enforcement.
Last cross-checked against upstream sources: · 8 sources
References
Each entry shows what the source supports and what it does not prove.
OWASP Top 10 for Agentic Applications 2026
§ASI06 Memory & Context Poisoning — Prevention and Mitigation Guidelines, item 2
"Content validation: Scan all new memory writes and model outputs (rules + AI) for malicious or sensitive content before commit."
Supports: Verbatim statement of the write-boundary principle: scan "before commit." Directly names memory writes as the validation surface.
Does not prove: Framed as a scan rule (rules + AI classifier), not a schema-plus-provenance pipeline. Does not specify embedding-distance outlier detection.
OWASP Agentic AI — Threats & Mitigations v1.1
§T1 Memory Poisoning — Mitigation column of the Threats & Mitigations table
"Implement memory content validation, session isolation, robust authentication mechanisms for memory access, anomaly detection systems, and regular memory sanitization routines."
Supports: Names "memory content validation" as the primary mitigation for T1 Memory Poisoning. Confirms the control class and its pairing with anomaly detection.
Does not prove: Does not distinguish write-boundary from read-boundary validation. The phrase "content validation" is left generic.
OWASP Agentic AI Mitigation Playbook P2 (Memory Poisoning & AI Knowledge Corruption)
Playbook 2 — Step 1: Prevent Memory Poisoning (Proactive), first and seventh bullet points
"Enforce memory content validation by implementing automated scanning for anomalies in candidate memory insertions. Restrict memory persistence to trusted sources and apply cryptographic validation for long-term stored data. … Require multi-agent and external validation before committing memory changes that persist across sessions. (Pre-commit validation to prevent self-reinforcing or unverified knowledge from persisting.)"
Supports: "Candidate memory insertions" and "before committing" both name the write boundary explicitly. "Cryptographic validation" matches Helmwart's provenance-attribution layer. "Pre-commit validation" is the exact phrase Helmwart generalises.
Does not prove: The playbook is part of the same OWASP document as the T1 table; it is not an independent source. Embedding-distance outlier detection is not mentioned here.
OWASP LLM Top 10 v2025 — LLM08:2025 Vector and Embedding Weaknesses
§Prevention and Mitigation Strategies — Data Validation & Source Authentication
"Implement robust data validation pipelines for knowledge sources. Regularly audit and validate the integrity of the knowledge base for hidden codes and data poisoning."
Supports: Names "data validation pipelines for knowledge sources" as a canonical defence against vector/embedding weakness. Covers the RAG ingest path that write-boundary validation protects.
Does not prove: Does not specify schema validation or embedding-distance anomaly detection as distinct techniques; the text does not name a write boundary explicitly. This is a pre-cursor reference, not a prescriptive spec.
OWASP LLM Top 10 v2025 — LLM04:2025 Data and Model Poisoning
§Prevention and Mitigation Strategies — Data Provenance Tracking
"Track data origins and transformations using tools like OWASP CycloneDX or ML-BOM."
Supports: Establishes data-provenance tracking as a recommended control for poisoning, aligning with Helmwart's provenance-attribution layer at the write boundary.
Does not prove: The source targets training-data and fine-tuning pipelines, not operational agent memory stores. Does not name a write-boundary gate or pre-commit validation for inference-time memory.
MITRE ATLAS AML.M0031 — Memory Hardening
AML.M0031 description field — ATLAS.yaml dist/ATLAS.yaml
"Memory Hardening involves developing trust boundaries and secure processes for how an AI agent stores and accesses memory and context. This may be implemented using a combination of strategies including restricting an agent's ability to store memories by requiring external authentication and validation for memory updates, performing semantic integrity checks on retrieved memories before agents execute actions, and implementing controls for monitoring of memory and remediation processes for poisoned memory."
Supports: "Validation for memory updates" and "restricting an agent's ability to store memories" both describe the write boundary. "Trust boundaries … for how an AI agent stores … memory" is the architectural framing Helmwart operationalises.
Does not prove: The text does not use the phrase "write-boundary" or "pre-commit." "Validation for memory updates" is ambiguous between write-time and read-time enforcement. The MDX description of AML.M0031 as naming "write-time validation" is a reasonable reading but not a verbatim match.
MITRE ATLAS AML.M0033 — Input and Output Validation for AI Agent Components
AML.M0033 description field — ATLAS.yaml dist/ATLAS.yaml
"Implement validation on inputs and outputs for the tools and data sources used by AI agents. Validation includes enforcing a common data format, schema validation, checks for sensitive or prohibited information leakage, and data sanitization to remove potential injections or unsafe code."
Supports: Names "schema validation" and "enforcing a common data format" explicitly — the first of Helmwart's three write-boundary layers. "Validation should be performed external to the AI agent" matches the architectural requirement for an independent validator.
Does not prove: Covers agent tool inputs and outputs broadly, not memory-write paths specifically. Does not name embedding-distance outlier detection.
NIST AI 600-1 — Generative AI Profile (NIST AI RMF)
MS-2.5-005 — MEASURE 2.5 "AI system to be deployed is demonstrated to be safe" — tagged Information Integrity
"Verify GAI system training data and TEVV data provenance, and that fine-tuning or retrieval-augmented generation data is grounded."
Supports: Requires provenance verification for RAG data at the MEASURE stage, which operationally maps to the write-boundary provenance-attribution check. Tagged Information Integrity in the NIST risk taxonomy.
Does not prove: NIST AI 600-1's Information Integrity risk category (§2.8) describes misinformation/disinformation risk, not data validation pipelines per se. The MDX claim that NIST "lists data validation under both Information Integrity and Information Security risk categories" overstates the category descriptions — what NIST actually does is tag individual MAP/MEASURE/MANAGE actions with those category labels. The risk-category prose itself does not prescribe validation controls.