# Agent memory and RAG: prevent retrieved text from becoming persistent policy Canonical: https://www.web3sec.news/blog/agent-memory-retrieval-poisoning Author: Raiders (https://www.web3sec.news/about) Format: guide Topic: Memory & retrieval Published: 2026-11-08 Updated: 2026-11-08 Track source provenance, enforce current retrieval permissions and test whether poisoned content survives into later tasks. ## The short answer Treat retrieved documents and saved memories as evidence with provenance, not trusted operating policy. Restrict who can ingest or modify content, enforce current user and tenant permissions during retrieval, and review persistent memory writes. Test poisoned documents across later sessions, then verify removal from source stores, indexes, caches and saved summaries. ### Diagram: Content is evidence. Approval is authority. Keep source material separate from the authority to act. ![Sources enter a working context and produce a proposal. A separate approval gate checks scope before a tool action. Untrusted content cannot authorize execution.](https://www.web3sec.news/diagrams/trust-boundary.svg) [Full-size SVG](https://www.web3sec.news/diagrams/trust-boundary.svg) · [PNG download](https://www.web3sec.news/diagrams/trust-boundary.png) Original explanatory control model; not a reconstruction of private incident evidence. ## Separate source data, memory and operating instructions Assign an owner to the ingestion pipeline and another accountable owner to the application’s persistent memory behavior. Inventory source repositories, document connectors, vector indexes, caches and summaries. Record which identities may write to each store. A trustworthy application can retrieve an untrustworthy comment, and a correct summary can preserve a malicious instruction from that comment if its origin is lost during compression. Store provenance with the retrieved unit: source identity, document version, ingestion time, author or connector, access classification and any expiration. Distinguish a user-approved preference from a claim made in a third-party document. Our operating recommendation is to keep permission changes and execution policy in a separate trusted configuration path, so high retrieval relevance cannot promote source text into administrative authority. ## Enforce boundaries at ingestion and retrieval OWASP’s RAG guidance addresses access metadata, retrieval-time enforcement, tenant isolation and index integrity. Review the entire path from connector authorization to returned chunks. Scope ingestion identities, validate source changes and ensure the query context comes from verified application state. A user-supplied tenant identifier or document filter must not be sufficient to select another customer’s material. Treat memory writes as changes worth authorizing and recording. Anthropic’s memory-tool documentation makes file-operation safeguards the application’s responsibility, including path confinement and handling sensitive information. Apply the equivalent controls to the storage implementation you use. Limit size and lifetime, reject writes outside the intended namespace and avoid saving raw credentials or unrelated private evidence as a convenient future reminder. ## Test persistent poisoning across sessions Create a synthetic document containing a clearly marked instruction to send a dummy record to an unauthorized destination or treat a new contact as an administrator. In an isolated test corpus, trigger normal retrieval, summarization and a proposed memory write. Verify that the content remains attributed data and cannot modify permissions or bypass independent approvals. Keep real private documents out of the experiment. Record whether poisoning enters through document ingestion, a user-editable annotation or the memory-writing component itself. Start a later session with a different task and inspect whether the injected instruction reappears through saved notes, summaries or semantic retrieval. Also revoke a test user’s document access and repeat the query. Check returned chunks and downstream tool actions, not only the answer text. Record the lineage of every derived object so a failed test identifies where the content crossed a trust boundary. ## Recover the content path and the resulting actions When poisoning is suspected, suspend affected ingestion or memory writes, preserve version history and identify the identities that changed the source or index. Quarantine the source and invalidate affected chunks, caches and summaries through a controlled process. Inspect persistent memories and task outputs for copied instructions. Removing the visible source without tracing its derivatives can leave the same behavior active in future sessions. Review completed external actions separately and revoke any authority exposed or created through them. Rebuild the affected index from verified sources where needed, then rerun the synthetic poisoning and access-revocation tests. Resume with explicit content lineage, a reviewed write boundary and a documented retention process. The goal is a demonstrable separation between remembered information and the rules governing what the agent may do. ## Controls to take away - Retrieval relevance does not confer trust or authority. - Persistent summaries can preserve instructions after their source is removed. - Current access controls must follow content through retrieval and memory. ## Work through the boundary Local planning worksheets; they do not inspect or change accounts or environments. - [Build a permission review plan](https://www.web3sec.news/tools/agent-permissions): Select the capabilities you are considering and review approvals, revocation and evidence before connecting an agent. ## Working checklist Assign owners and record supporting evidence in your team's system. - [ ] Inventory source, index, cache, summary and memory stores. - [ ] Preserve provenance and current access metadata with retrieved chunks. - [ ] Authorize and log persistent memory writes. - [ ] Test injection persistence and revoked-access retrieval using synthetic content. - [ ] Trace and invalidate derived copies during recovery. ## Common questions ### Does a relevant search result make a document trustworthy? No. Similarity ranking concerns relevance, not authority, factual accuracy or permission to act. Preserve the source and trust level, and keep retrieved instructions from altering tool permissions or approval requirements. ### Why check permissions again during retrieval? Access may have changed since ingestion. A document that was permitted when indexed can later become restricted or deleted. The query path must enforce current access to the chunks it returns. ### Is deleting a poisoned source document enough? Not necessarily. Its content may remain in indexes, caches, summaries, exported results or persistent memory. Identify those derived copies, remove or invalidate them and rerun a controlled retrieval test. ## Sources & further reading - [OWASP: RAG security and retrieval isolation](https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html) - [Anthropic: memory-tool security considerations](https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool) Incident facts are attributed to the linked reports. Recommendations are Web3Sec's analysis. [Research methodology](https://www.web3sec.news/methodology) · [Editorial policy](https://www.web3sec.news/editorial-policy) · [Send a correction](https://www.web3sec.news/contact)