Give persistent agent memory an admission boundary

Memory is a future input

Do not let ordinary conversational text become trusted reusable guidance merely because an agent wrote it to a memory store. Put an admission decision between a candidate memory and future retrieval. That decision should establish the record's origin, content class, owner, permitted audience and lifetime. Preserve links to derived summaries so that withdrawing a source memory can also remove its continuing influence.

Persistence changes the duration and audience of an input. A misleading instruction in one conversation may affect that session; the same instruction promoted into a shared procedural memory can influence later tasks and other users. The important boundary is therefore not simply write access to a database. It is the authority to turn an event into future context that the application presents as useful experience or guidance.

LangChain's memory overview distinguishes short-term conversational state from longer-lived memory, and describes factual, episodic and procedural forms. It also describes writing memory during a request or in background processing. ^[3] Those distinctions are useful for security design because a remembered preference, an execution trace and a general rule should not automatically have the same promotion path.

Consider a hypothetical assistant helping employees find internal documents. A user says that they prefer concise answers. Remembering that preference for the same user may be reasonable. The user then says that all later searches should ignore document restrictions. That second statement must not become a shared procedure simply because both arrived as conversational sentences. The application should classify and constrain what the memory is allowed to do before it can affect future requests.

Runtime memory is also different from model training. A poisoned record can alter retrieved context without changing model weights. AgentPoison studied manipulation of memory or knowledge bases as an attack surface for agents. ^[2] Training-data controls remain important, but they do not govern every database write that later becomes prompt context. Keeping these pathways separate prevents a model-release review from being mistaken for a complete memory-security review.

This guide proposes an admission-and-repair design, not a proven universal defense against memory poisoning. Content checks can miss manipulative material, and a valid provenance record can describe an unsafe recommendation. The goal is to constrain who can promote information, where it may be reused and how its descendants can be withdrawn when the system discovers a problem.

A useful first inventory lists every memory writer: the interactive agent, a summarizer, a scheduled consolidation job, an import tool and an administrator. For each, identify the future readers and whether the record can influence facts, behavior or tool selection. A background writer deserves the same scrutiny as a public API, even if its input originated in an apparently successful task.

Locate the writeback authority

The writeback authority should sit in trusted application logic. It receives a candidate, resolves the authenticated principal and checks the permitted memory operation. The model may propose content or a classification, but it should not choose an unrestricted namespace, grant itself a wider audience or decide that its own task success justifies permanent shared guidance.

A namespace organizes records; authorization determines who may use it. LangChain's access-control documentation separates authentication from per-resource authorization. ^[4] Apply that distinction to memory reads, writes, searches, listing and deletion. A client-supplied namespace string must not become an entitlement. The server should derive or validate it against the caller's authorized resources and reject attempts to broaden the scope.

Success signals are especially easy to overread. A tool returned without an error, a user clicked a positive-feedback button or a summarizer described a task as completed. None of these observations necessarily validates every instruction in the resulting trace. A completed document search does not authorize a new global search policy. A satisfied requester is not automatically empowered to change how the assistant behaves for other users.

In the hypothetical document assistant, the interactive path can propose a personal preference, while a separate controlled path handles procedural changes. A preference might be available only to its owner and expire when no longer relevant. A procedural candidate might require an authorized policy owner to review its future audience and consequences. These are proposed application rules, not evidence that a generic memory framework implements them automatically.

The illustration makes that separation visible: loose conversation cards enter a review tray, an admitted record passes through a promotion gate, and a quarantined card remains outside durable memory. A provenance thread links the admitted card to derived summaries. The gate represents an application decision. It does not imply that a model reliably detects malicious intent or that a human reviewed the illustrated record.

Keep action authority independent of memory authority. Even an admitted memory should not grant a tool permission the caller lacks, bypass an approval requirement or select an unrestricted destination. OWASP's agent-security guidance recommends boundaries around tools, memory and privileges. ^[7] A compromised memory can still influence suggestions, so the execution layer must apply its own policy to any consequential action.

Promotion must be observable without indiscriminate transcript retention. Record which trusted component made the decision, the policy version and the source event reference. Keep sensitive content under appropriate access controls. A broadly readable audit stream containing every candidate memory can create a second exposure problem while trying to solve the first.

Source. Original conceptual illustration informed by memory concepts and OWASP agent-security guidance. ^{[3] [7]}

Method. Conceptual model of proposed controls, not a measured defense, product screenshot or evidence of human approval. The gate does not guarantee a model detects malicious content.

Accessible table and figure data

Figure 1 accessible table

Zone	Application decision	Repair consequence
Conversation	Treat ordinary text as untrusted input	Preserve relevant origin evidence
Review tray	Classify candidate, owner and audience	Keep unresolved candidates out of active reuse
Promotion gate	Trusted application authorizes admission	Record policy and source references
Durable drawer	Retrieve only eligible scoped records	Quarantine or retire suspect memory
Derived summaries	Retain source relationships	Invalidate or rebuild affected descendants

Figure 1 accessible table

Zone	Application decision	Repair consequence
Conversation	Treat ordinary text as untrusted input	Preserve relevant origin evidence
Review tray	Classify candidate, owner and audience	Keep unresolved candidates out of active reuse
Promotion gate	Trusted application authorizes admission	Record policy and source references
Durable drawer	Retrieve only eligible scoped records	Quarantine or retire suspect memory
Derived summaries	Retain source relationships	Invalidate or rebuild affected descendants

Download imageDownload table CSV

Read the poisoning evidence with its limits

MINJA examined memory injection through ordinary query interaction in an agent setting with a shared memory bank used by attacker and victim queries. Its threat model is not a claim that every production memory system shares records between users. The relevant lesson is that a write path can promote hostile influence even when the attacker does not directly edit the memory database. ^[1]

The chart uses only Table 4's benign-density experiment: EHRAgent with GPT-4, the first three victim-target pairs from each dataset, and 15 attack queries per pair while benign-query counts vary. The plotted metric is attack success rate in separate victim-query responses, defined by targeted reasoning. It is not completed real-world harm, an incident frequency or evidence about actual clinical treatment. ^[1]

MIMIC-III and eICU have different task definitions and different trends in that experiment. The former decreases across the tested benign-query counts; the latter decreases and then rises. The figure copies the reported values without interpolating between tested counts. Its practical implication is modest: accumulating more benign records was not a dependable standalone defense across these two tested settings.

Do not turn that implication into the opposite absolute claim that normal memory can never help. Retrieval behavior depends on the stored material, query distribution, retrieval configuration and admission process. The paper provides evidence for a bounded experimental result. An organization's control decision still needs to specify what its system retrieves, how records are ranked and whether untrusted content can become durable guidance.

A January 2026 follow-up preprint studies memory poisoning and defenses with different models and manually constructed query settings. ^[5] It is useful as a reminder that results depend on setup, not as a directly comparable replication to average into the chart. AgentPoison also has a different poisoning-access model. ^[2] Keeping the studies separate makes the security question clearer: which path allows influence to enter this application's future context?

An owner should be able to answer that question without running an attack against a real user. Inspect the admission path, classify the writers, and create benign fixtures that exercise the boundary. A test record can harmlessly request a fabricated formatting preference in another user's context; the acceptance condition is that it never receives unauthorized scope. This checks an important application property without claiming to reproduce the paper's attack success rate.

The evidence also explains why deletion of one visible record can be insufficient. A memory might already have been summarized, merged or converted into a procedural rule. The original paper's persistence concern motivates an operational question beyond initial filtering: can the system identify and stop reusing information derived from the suspect source? The repair design below is an original recommendation, not a defense experimentally validated by the cited study.

Source. MINJA Table 4 and section 5.3, NeurIPS 2025 paper at arXiv revision v4. ^[1]

Method. MINJA Table 4 reports ASR for EHRAgent using GPT-4 over the first three victim-target pairs in each dataset while varying benign-query density. ASR counts victim responses containing targeted reasoning, not real-world harm. MIMIC-III and eICU use different tasks, and their trends show why accumulating benign records is not a dependable standalone defense. The attack-query count remains 15 per pair. Values are copied without conversion or interpolation; no independent test was run.

Accessible table and figure data

Figure 2 accessible table

Benign queries mixed into memory injection	MIMIC-III ASR	eICU ASR
25	68.9	95.6
50	61.1	87.8
75	44.4	82.2
100	31.1	88.9

Figure 2 accessible table

Benign queries mixed into memory injection	MIMIC-III ASR	eICU ASR
25	68.9	95.6
50	61.1	87.8
75	44.4	82.2
100	31.1	88.9

Download imageDownload table CSV

Define the admission record

An admission record should make the future use intelligible. Store a stable record identifier, source event reference, writer identity, owner, content class, allowed audience, creation time, expiry, policy version and promotion state. Link the record to the source material and to any records from which it was derived. Keep these control fields outside the untrusted natural-language body so that a candidate cannot redefine its own provenance.

Use explicit states such as candidate, admitted, quarantined and retired. The names are illustrative, not a framework API. State transitions should be performed by authorized application operations, and retrieval should check the current eligible state. A summarizer that copies an admitted record must not be able to declare a new source admitted solely by reproducing its status word in text.

The content class should constrain future behavior. A personal preference can affect presentation for the same owner without becoming a statement about organizational policy. An episodic trace can document what happened without prescribing that it should happen again. A procedural rule can influence repeated decisions and therefore requires a deliberately narrower promotion authority. LangChain's memory categories are a useful vocabulary, but the application must supply these policy distinctions. ^[3]

Audience is a separate field from ownership. A record owned by one team may be shared with another only under an explicit policy; it does not become globally readable because a background job can access both teams. Treat consolidation jobs as privileged writers with bounded inputs and outputs. If a summary combines sources with different audiences, derive an audience that does not expose either source beyond its permitted readers, or split the summary.

Review content checks as one layer. Input screening, structural validation and detection of suspicious instructions can reduce exposure, but OWASP's prompt-injection guidance describes a defense-in-depth problem rather than a complete semantic-safety test. ^[6] An approval screen should show the proposed future audience and behavioral effect, not only a raw text box or a green classifier result. That is especially important when a candidate asks to alter a procedure.

Integrity controls answer a different question. A digest or signature can help establish that a record has not changed since an authorized operation. It cannot establish that the originally admitted content was true, harmless or appropriate for every later task. Preserve both kinds of evidence: who admitted what under which policy, and what subsequent changes occurred. Do not use a checksum as a substitute for the admission decision.

Expiry should have a defined meaning. It may stop active retrieval, require renewed approval or trigger deletion under a retention policy. A record should not regain active status merely because a restore job reimports it with an old timestamp. Record the policy for stale approvals and retired identifiers outside the content being restored. Otherwise a backup operation can quietly become a fresh promotion path.

A small decision receipt is more useful than an elaborate trust score with no interpretation. For a shared procedure, the receipt might state the authorized owner, reviewed sources, intended workflow and conditions that invalidate it. For a personal preference, it might simply bind the candidate to the authenticated user and a permitted preference class. Match the review to the future authority of the record.

Repair the derived memories

When a memory is suspected of carrying harmful influence, first stop its active reuse and prevent the same writer from immediately recreating it. Quarantine the affected record or temporarily pause the relevant writeback path while preserving necessary evidence. The appropriate containment depends on the system's authority and impact. Do not erase the only trace before the incident owner understands what happened.

Trace descendants through recorded provenance: summaries, merged profiles, extracted procedures and other memory records derived from the source. Mark them ineligible or rebuild them from approved source material. Regenerating a summary from a contaminated summary is not a clean rebuild. The system needs access to a trustworthy source boundary, not merely another model pass over the same influence.

Retrieval caches and active task context deserve separate handling. Removing a record from the store does not necessarily remove a copy already supplied to a running agent. Decide whether affected tasks must stop, restart with clean context or continue under constrained authority. This is an operational recommendation, not a claim that every framework exposes the same cancellation or invalidation controls.

Keep suppression, deletion and incident retention distinct. A quarantined record can be excluded from normal retrieval while retained under restricted access for investigation. A later deletion operation may have different handling for backups and legally required records. OWASP's RAG guidance emphasizes lifecycle management for derived information. ^[8] Apply that discipline without claiming that a successful database delete proves every downstream copy is gone.

Consider a hypothetical procedure memory that tells the assistant to route documents through an obsolete service. An episode summary and a team guide were derived from it. Retiring only the procedure leaves two routes for the same instruction to return. A lineage-aware repair invalidates both descendants, rebuilds the team guide from approved current sources and records the retired source so that a future import cannot silently restore it.

The same case raises an ownership question. Who decides that the source is unsafe, who can quarantine it, and who authorizes a rebuilt procedure? Define those responsibilities before an incident. A model can flag a candidate and an automated rule can stop retrieval, but the application still needs a clear policy for resolving disputed or ambiguous records. Avoid presenting an automated review as a human approval that never occurred.

Preserve the evidence needed to distinguish a malicious write from an authorized but mistaken rule. Useful records include the origin event, authenticated writer, admission policy version, state transitions and descendant references. Protect the evidence according to its contents. The aim is a repairable history, not an unrestricted archive of every private conversation.

After containment, verify that normal task behavior still works with the repaired memory set. Removing too much can cause an outage or prompt operators to restore an unsafe snapshot. A rollback should have an identified approved source state and a clear boundary on which records return. It should not be an unreviewed wholesale reintroduction of the same suspect history.

Test admission with benign fixtures

The following is a proposed acceptance plan. No memory-poisoning attack or framework implementation was executed for this article. Use synthetic conversations, fabricated identities and harmless candidate content in an authorized environment. The tests should exercise policy transitions and provenance without copying attack payloads into a production store.

Create two principals with separate memory scopes. Admit a harmless preference for one and verify that the other cannot read it, find it through search, enumerate it or write into its namespace. Test every exposed route, including background jobs and imports. Authentication success is not the acceptance condition; the per-resource decision must match the intended audience. ^[4]

Submit a candidate that tries to supply its own owner, audience or admitted status. The server should ignore or reject those control fields according to the documented contract. Then verify that a legitimate candidate can still be admitted by the authorized path. Negative tests without a working positive control may merely demonstrate that memory is disabled.

Exercise changes after admission. Revoke an owner's permission, expire a record, quarantine a source and invalidate its derived summary. Check both direct lookup and retrieval paths. Restore an older snapshot into an isolated test environment and confirm that retired or stale records do not become eligible solely because their old bytes reappear. A successful active-store deletion is not enough to cover that case.

Test the admission check's unavailable state. A failed policy service, malformed classifier response or exhausted dependency budget should not silently promote a candidate. The safe outcome may be to keep it pending, skip persistence while completing the immediate task, or stop a workflow whose correctness requires memory. Specify that behavior explicitly and preserve enough information to retry without widening authority.

Measure useful task behavior separately from contamination outcomes. A memory system that never stores anything may satisfy isolation tests while failing its purpose. A system that completes tasks well may still admit unauthorized shared rules. Select benign task fixtures that show required preferences or approved procedures remain usable, and pair them with scope and lifecycle checks. Do not blend these results into a fabricated aggregate security score.

Keep the release record scoped to the tested application. It should identify writers, content classes, namespace policies, retrieval rules, repair paths and versions. OWASP's agent guidance supports treating memory as a controlled part of the agent architecture. ^[7] The practical outcome is an admission owner and a repair procedure that can be exercised, not a claim that persistent memory is now immune to hostile influence.