AI Agent Memory Poisoning: Assess Persistence Across Sessions

Sources checked: 29 October 2026. This article contains FailSafe's analysis and proposed validation workflow; linked sources support the reported facts.

A memory feature changes an assistant’s security boundary because content can affect a task long after the conversation that introduced it. Imagine a sales assistant saving customer preferences and account notes. A low-trust note should not become durable permission to change pricing or disclose another account’s information. Memory poisoning assessment asks who can create persistent content, how it is attributed, and whether later tasks treat it as evidence, preference, or authority.

Define the boundary before testing

Inventory short-term conversation history, long-term memory, summaries, shared workspace notes, and any retrieval store described as memory. Identify write permissions, review rules, expiry, user and tenant isolation, and the mechanism for deleting a record. Use synthetic accounts and harmless markers whose origin is obvious. Agree which kinds of facts may persist and which require confirmation. The assessment should distinguish user-approved preferences from automatically inferred instructions and records written by external tools or delegated agents.

Run a bounded assessment

Run a normal task that saves an allowed preference, then confirm the expected later behavior. Introduce an approved out-of-scope instruction through a lower-trust test note without including any real secret or destructive request. Start a new session and observe whether the stored note changes an unrelated authorized task. Repeat after account switching and memory deletion where supported. Use a mock consequential tool so any attempted operation is observable without creating an external effect. Stop once the persistence and authority boundary is established.

Keep evidence an engineer can use

Keep the memory record identifier, writer identity, source channel, classification, timestamps, and later retrieval event. Record the difference between remembered content appearing in context and an unauthorized operation actually passing policy. A report should explain whether the weakness is unreviewed writing, cross-user reading, misleading provenance, or inappropriate authority assigned at use time. If a system has no visible memory trace, state that limitation. Do not infer that a conversation reset cleared a persistent store merely because the interface looks empty.

Interpret the result and retest

Retest memory writes, later retrieval, and deletion after remediation. Include a legitimate remembered preference so the control does not silently disable the feature’s purpose. Residual risk can remain when a user explicitly requests broad persistence or shares a memory space with others. The OWASP AI agent security reference supplies general background; the workflow here is a proposed test for a particular product design. A passing sample does not establish that every future memory item or model update will preserve the same behavior.

Assessment scope and next steps

This is a proposed defensive assessment workflow, not a finding about a particular product. Use a staging environment, synthetic records, approved test identities, and an agreed stop condition. Record the model, connector, policy, and application versions so a later result can be compared with the same configuration. Unavailable evidence should remain an explicit coverage gap.

Primary reference: OWASP security guidance. The scenarios and acceptance criteria here are editorial recommendations for adapting that background to an authorized assessment.

For a scoped review of these boundaries, explore FailSafe AI security testing and agentic penetration testing. Agree the specific tools, identities, evidence, and exclusions before purchasing an assessment.