Have a project in mind? Let's talk.
AI agent memory poisoning turns stored context into a lasting source of bad decisions. OWASP describes the risk as an adversary corrupting information an agent retains, retrieves or reuses, including summaries, embeddings and retrieval stores. The result can affect later planning and tool use, even after the original malicious input has left the conversation. Source
That persistence is the important difference from a single misleading answer. If an agent stores a false policy, a fabricated preference or a malicious instruction as trusted memory, the next task can inherit it. This guide uses OWASP and Microsoft's security guidance to explain the controls around memory. The workflow examples and proposed release tests are our synthesis, not claims about a Codesprint deployment. Microsoft memory poisoning
OWASP's ASI06 category includes conversation history, memory tools, summaries, embeddings and RAG stores. It distinguishes persistent corruption of stored or retrievable context from one-time prompts. Uploads, API feeds, user inputs and exchanges with other agents can all become ingestion paths. The security boundary therefore includes the path into storage and the way stored information is later retrieved. Source
Microsoft gives a similarly broad list: long-term context stores, grounding caches, preference memories, vector databases and conversation histories. It explains that malicious content may enter through interactions, indexed documents or shared agent state. The risk is not limited to a database field literally named "memory." A generated summary that guides future actions can carry the same problem. Microsoft memory poisoning
Our review starts with a data-flow map. List every component that can write retained context, every store it can reach and every later workflow that reads the result. Include derived summaries and caches. Then distinguish factual reference material, user preferences, operational state and permission decisions. These categories should not automatically receive the same retention period or influence over actions.
OWASP includes context-window manipulation and gradual long-term drift among its examples. A harmful statement can be summarized, saved and reused after its original context disappears. It also warns about automatically re-ingesting an agent's own output into trusted memory, which can create self-reinforcing contamination. Repetition across derived records is not necessarily independent evidence. Source
Consider our hypothetical support assistant. An uploaded document claims that refunds below a certain amount no longer need approval. The assistant summarizes the document, saves the summary and later retrieves it as a refund rule. Nothing in that chain proves the policy owner approved a change. The mistake is promoting an external claim into operational authority, not merely failing to spot a suspicious phrase.
Our recommendation is to preserve provenance through each transformation. A summary should point back to its source and retain the source's trust status. A second summary of the first should not become a fresh corroborating source. Before a stored statement changes a payment, disclosure or destructive action, validate it against the authorized policy or decision record.
Microsoft recommends treating memory writes as privileged operations, with policy checks governing which data may be persisted. It also recommends source approval, provenance tracking, integrity checks, versioning, review and rollback for context artifacts that can influence behavior. That moves the question from "can the model remember this?" to "which component is allowed to store this kind of record?" Microsoft memory poisoning
Our suggested write gate checks the caller, tenant, source, record type, intended use and retention. A retrieved webpage might be eligible for a low-trust reference note but not for a change to approval rules. A user preference should carry evidence of the user's decision rather than a third-party statement that claims to describe it. Enforce the allowed categories in application code.
Use a review path for consequential changes. Our proposal is to keep newly extracted material separate from reviewed operational policy. The agent can propose a candidate record, but promotion into a high-trust category should require the appropriate authority. This is an access-control decision, not something established by the confidence score of the summarizing model.
OWASP recommends source attribution and detection of suspicious update patterns. Microsoft recommends version history, ownership, timestamps and change reasons so reviewers can compare changes and identify when poisoning began. These fields make investigation possible; a bare paragraph in a vector store does not explain who supplied it or why the application should rely on it. OWASP Agentic Top 10 Microsoft memory poisoning
Our minimum record would include a stable entry ID, source reference, observed author or origin, tenant, purpose, creation time, review state and expiry rule. Keep derived-from links for summaries. Separate an observed source identifier from a claimed human identity. If a document says "the administrator approved this," retain that as a claim unless an authenticated decision record supports it.
Integrity checks have a narrower job. OWASP's agent-security cheat sheet recommends cryptographic integrity checks for long-term memory. Our caution is that an unchanged malicious record is still malicious. A hash or signature can help detect tampering or verify a particular signing source, but it does not independently prove that the content is correct or that its requested action is authorized. Source
OWASP recommends segmenting user sessions and domain contexts, along with per-tenant namespaces in shared vector or memory stores. Microsoft similarly recommends scoping by user, task, tenant, agent and trust domain. Shared storage should not silently turn one user's input into another user's decision context. OWASP Agentic Top 10 Microsoft memory poisoning
Our implementation recommendation is to enforce scope in the retrieval service, not only in a sentence telling the model to ignore other tenants. Test both writes and reads. Confirm that a record cannot be inserted under another tenant and that an intentionally similar query cannot retrieve it across the boundary. Include shared-project access and membership removal if the product supports collaboration.
Do not confuse relevance with permission. Our view is that a semantically close result still needs an access check and source review. Retrieval ranking can help choose relevant material from the permitted set; it should not be the mechanism deciding which private records a caller is entitled to see.
OWASP recommends minimizing retention according to sensitivity, expiring unverified memory and reducing the influence of low-trust entries over time. Its agent-security cheat sheet also calls for expiration, size limits and audits for sensitive content before persistence. Microsoft advises storing confidential information only for a clear business need and considering scoped retrieval, masking or short-lived session context instead. OWASP Agentic Top 10 OWASP agent security Microsoft memory poisoning
Our practical rule is to ask what future task benefits from each retained field. A temporary delivery status, a draft inference and a durable preference have different lifetimes. Expiry should affect retrieval and derived caches, not only hide a record in one administrative screen. Document what happens when an item is corrected, deleted or superseded.
Memory also should not substitute for current external state. Our recommendation is to verify action-driving facts such as account permissions, transaction status and active policy at the relevant system before acting. A remembered fact can locate the right record, but it should not become permanent proof that the record is still current.
Both OWASP and Microsoft recommend validating candidate writes for malicious or sensitive content. Microsoft describes sanitization and structured memory fields; OWASP combines content validation with segmentation, access limits and provenance. That combination matters: a scan is one control in a larger system, not proof that arbitrary text is safe to promote into trusted instructions. OWASP Agentic Top 10 Microsoft memory poisoning
Our recommendation is to use narrow schemas for operational records and keep retrieved reference text explicitly separate. Reject writes that try to change permissions through a free-text note. Review scanner failures and false positives. The remaining action boundary should still be enforced by permissions, destination checks and approval requirements even when a poisoned record reaches the model.
OWASP recommends snapshots, version control, quarantine and rollback for suspected poisoning. Microsoft likewise calls for write logs, diffs and recovery history. A usable recovery process needs to show what changed and which context artifacts were affected, rather than only clearing the current conversation and hoping the problem disappears. OWASP Agentic Top 10 Microsoft memory poisoning
Our incident sequence is to pause affected high-impact actions, quarantine suspect entries, inspect their source and derived records, and restore reviewed state. Check summaries, caches and shared indexes for copies. Then examine actions already taken under the poisoned context. Deleting a memory entry does not undo a disclosure or reverse a completed transaction.
Our proposed test is deliberately multi-session. Seed an untrusted source with a false rule in a contained environment, run the normal extraction process, then start a later task that might retrieve it. Verify that the record cannot acquire policy authority, cross tenant boundaries or trigger an unauthorized action. Repeat after summarization, expiry, deletion and recovery. Keep the expected denial and the final external state in the test evidence.
OWASP recommends adversarial testing before deployment and after material changes to prompts, tools, memory, retrieval, policies or providers. For the wider testing approach, see our AI agent safety testing guide. For the surrounding tool and permission controls, read our AI agent security checklist and AgentOps services. Source
OWASP's memory-poisoning category focuses on persistent corruption of retained or retrievable context that influences later sessions and actions. A one-time malicious prompt does not necessarily create that persistence. OWASP Agentic Top 10
Yes. OWASP includes embeddings and RAG stores among the context sources covered by ASI06. Access control and provenance matter alongside retrieval quality. OWASP Agentic Top 10
No. Our distinction is that integrity checks help detect changes; they do not establish the truth or authority of the original content. Use them with source review and access controls, as part of a layered design. OWASP agent security
Not necessarily. Our recommendation is to apply review according to the record's purpose and risk, with stronger approval for changes that could affect permissions or consequential actions. Low-risk reference notes can have a narrower automated path without becoming operational policy.
Ready to take the first step towards unlocking opportunities, realizing goals, and embracing innovation? We're here and eager to connect.