[Track A] Feedback: Persistent Memory Poisoning

[rocklambros]

Sprint 2 Feedback — Persistent Memory Poisoning

This issue collects qualitative feedback on the Persistent Memory Poisoning new candidate entry. Submit your Importance, Clarity, and Distinctness scores via the Sprint 2 Google Form (single ballot covering both tracks).

• Vote: https://docs.google.com/forms/d/e/1FAIpQLSebmFQyJPOMuw1IorHCJ2FdW98ZT2oLNBuVgYqpPoayW9v6ww/viewform — page through to the Track A section, then to Persistent Memory Poisoning
• Read the draft: https://github.com/GenAI-Security-Project/GenAI-LLM-Top10/blob/main/2026/new_entry_candidates/persistent-memory-poisoning.md
• Voting closes: May 18, 2026 at 23:59 UTC
• Code of Conduct: https://owasp.org/www-policy/operational/code-of-conduct

Scoring rubric

• Importance (1–5): How critical is this risk to LLM application security in 2026?
• Clarity (1–5): How clearly does the candidate describe the risk and mitigations?
• Distinctness (1–5): Is this materially different from existing entries (LLM01–LLM10), or could it be merged into one of them?

Why Distinctness matters

Sprint 3 cuts 8 candidates down to 5. A high-Importance candidate that overlaps heavily with an existing entry is a merge target, not a standalone winner. Distinctness scores let the working group make defensible cut, keep, or merge calls.

How to comment

Reply to this issue with feedback specific to Persistent Memory Poisoning. Use one comment per topic so the working group can triage cleanly. Format we like:

Section: <which section of the candidate>
Issue: <what is wrong, missing, unclear, or duplicative>
Proposed change: <your suggested fix, addition, or merge target>
Overlaps with: <existing entry LLM01–LLM10 if applicable>
Evidence: <CVE, paper, incident, or research note ID if applicable>

Out of scope here

• Cross-cutting comments → use Discussions
• Comments on existing entries (LLM01–LLM10) → comment on the relevant Track B issue
• Process or governance questions → comment in Discussions

Triage

Working group entry leads classify each comment within 48 hours as:

• actionable — feeds Sprint 3 revision or merge decision
• clarification — requires reply, not action
• out-of-scope — closed with redirect

Sprint 3 begins May 18 with this issue's triage as input.

[nagasatish007]

Section: Prevention and Mitigation Strategies — "Treat memory writes as
privileged state transitions"

Issue: The mitigation correctly identifies memory writes as privileged operations,
but the implementation guidance could be more specific about provenance classification.
The entry says "tag every candidate memory entry with its source class" but doesn't
define what the source classes should be or how they map to trust decisions.

Proposed change: Define a concrete provenance taxonomy for memory writes:

• direct_user: explicitly stated by the user in their own words
• model_inference: generated/summarized by the model from conversation
• tool_output: returned from a tool invocation
• untrusted_document: derived from external content (web, email, uploaded file,
  RAG retrieval from external sources)

Default policy: block or require explicit confirmation for any write whose
lineage includes untrusted_document or tool_output. Allow direct_user writes
with standard content sanitization. Treat model_inference as medium-trust
(sanitize but don't block by default).

This taxonomy makes the mitigation implementable rather than aspirational.

Evidence: The SpAIware attack (Scenario #1) and the MINJA pattern (Scenario #3)
both succeed because the memory system treats model-mediated summaries of
untrusted web content with the same trust as direct user statements. A provenance
tag would have blocked both at the write step.

[emmanuelgjr]

Accepting — the proposal is the right shape and the original wording was under-specified.
One refinement before merging: the trust class needs to propagate transitively along the full lineage. SpAIware and MINJA are both model_inference derived from untrusted_document — without transitive propagation, the candidate presents as medium-trust at the write site and both PoCs still succeed. Rule: the candidate's trust level is the minimum across all sources that contributed to it.
Two small adds: split tool_output into _internal (vetted schema) vs _external (MCP, web-fetch, agent-to-agent — treated as untrusted_document), and cap agent self-reflection trust at the trajectory it reflects over.
Proposed replacement for mitigation #2:

2. Enforce a concrete provenance taxonomy on every memory write. Tag each candidate with one of the following source classes and propagate transitively. The candidate's trust level is the minimum across all sources in its lineage:

• direct_user — explicitly stated by the user in their own words.
• model_inference — generated, summarized, or paraphrased by the model. Reflective/self-summarizing outputs are capped at the trust of the trajectory they reflect over.
• tool_output_internal — first-party tool, vetted schema, no third-party passthrough.
• tool_output_external — third-party MCP, web-fetching, agent-to-agent. Treated as untrusted_document.
• untrusted_document — external content (web, email, uploaded files, RAG from external corpora, agent observations).

Default policy:

• direct_user → allow with sanitization.
• model_inference / tool_output_internal → sanitize, strip imperatives and conditional triggers; downgraded to lowest-trust ancestor.
• tool_output_external / untrusted_document → block, or require out-of-band user confirmation with a diff.

Under this policy both cited PoCs block at the write step — SpAIware inherits untrusted_document from the summarized page, MINJA from the attacker-seeded query content.
Will push as a follow-up PR.

Thanks @nagasatish007