AI agent memory poisoning: secure long-term context
Poisoned memory affects future agent sessions and users. Enforce provenance, tenant isolation, write validation, expiry and reliable deletion.
- AUTHOR
- Karol Rapacz / Penetration Tester (OSCP, PNPT)
- PUBLISHED
- 16 June 2026
- READING TIME
- 10 min read
- TOPIC
- AI Security
AI agent memory poisoning changes behaviour after the attack ends. A malicious preference, false fact or instruction persists into later tasks and possibly other users.
Separate memory types
Distinguish session history, user profile, organisational knowledge and task state. Each needs a different owner, TTL and write policy. One tenant’s records must never enter another tenant’s retrieval context.
Control writes
The model may propose a record, while deterministic middleware validates schema, source, classification and conflicts. Privileged memory requires a human or trusted-system confirmation.
Store provenance, version, author, time and reason. Raw internet content must not become a durable rule automatically.
Retrieval and expiry
Filter tenant, user, objective and trust before vector similarity. Expire old records and revalidate critical facts. Provide inspection, correction and reliable deletion.
Tests
Inject delayed triggers, conflicting preferences, cross-tenant writes and forged administrator instructions. Inspect backups, replicas and logs because removal from the main index may not end retention.
OWASP lists memory poisoning as a core agent risk. Combine memory controls with RAG security and explicit data ownership.
Memory is not one data store
Separate short conversation state, user preferences, business facts, retrieved knowledge and system procedures. Each class has a different owner, retention period and trust level. An operational instruction should not share a collection with an informal user note, and tenants require hard isolation before similarity search.
Store provenance, author, time, tenant, version and justification with each record. Model-generated content carries less trust than an approved policy. A record with unknown origin must not influence a high-risk action.
Write and read controls
The model may propose a memory, but another component validates schema, data classification, duplicates and policy conflicts. Sensitive preferences and persistent instructions require explicit approval. On read, filter tenant, owner and type before vector similarity.
Memory output is context, not authority. Current policy and user consent override historical records before tool execution. Set a TTL and an invalidation mechanism covering the primary index, cache, replicas and pipeline copies.
Responding to poisoning
When poisoning is detected, freeze writes, identify affected records through provenance and rebuild a clean index from trusted material. Determine which sessions read the records and what actions followed. Deleting the visible entry is insufficient if it was already materialised in a summary or cache.
Tests should cover delayed triggers, related records distributed over time, tenant conflicts, reappearance after restore and attempts to promote a note to system policy. Measure blocked writes, invalidation time and downstream actions following a poisoned read.
Conflicts and confidence
When records disagree, do not select the newest or most similar automatically. Compare source, owner, time and approval level. A conflict about payment, identity or procedure may require human confirmation rather than another model summary.
Distinguish verified facts, user declarations, model inferences and external content. Confidence labels do not replace provenance, but help restrict weak data from high-impact decisions.
Audit and user control
Provide a view of records influencing behaviour, plus controlled correction and deletion. Log who changed memory, when, why and which versions remain under retention. Regulated data retention should follow classification rather than product convenience.
Regular audits find ownerless records, unusually frequent instructions, cross-tenant content and entries surviving TTL. These signals may indicate an attack or a pipeline synchronisation defect.
Backup design must verify that restore respects invalidation lists. A technically valid backup can reintroduce deleted poisoned records. Recovery testing therefore covers retention policy, provenance and re-indexing, not only file integrity.
The product owner should periodically approve which decisions may use memory automatically. Increasing a feature’s impact requires a fresh review of data, consent and invalidation paths.
Sources: OWASP AI Agent Security, OWASP Top 10 for Agentic Applications 2026.
