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.
These local worksheets turn the review questions into a plan. They do not inspect or change the actual account or environment.
Build a permission review plan ↗
Select the capabilities you are considering and review approvals, revocation and evidence before connecting an agent.
Take this to your next review
Working checklist
Use this as a starting point, then assign owners and record evidence in your team's own system. Checks here reset when you leave or reload this note.
0 of 5 reviewed
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
The references below support this note. Adapt the procedures to your systems, access model and recovery requirements.
A correction or a better primary source? Send Raiders the article URL and evidence. Editorial policy.