Executive summary
AI agent memory poisoning is the deliberate corruption of the persistent state an AI agent stores and reuses, so that attacker-influenced content shapes the agent's future decisions long after the original interaction ends. It is not another name for prompt injection. Prompt injection is how malicious instructions enter an agent through the data it reads; memory poisoning is what happens when those instructions become durable state that the agent trusts, retrieves, and acts on across later sessions, tasks, and sometimes other users.
This shift matters because memory changes the blast radius of a single compromise. A prompt injection that is caught and cleared affects one conversation. The same injection, once written into long-term memory, becomes a delayed and reusable implant. Security researcher Johann Rehberger demonstrated exactly this against Google Gemini in February 2025, using a poisoned document to trick the assistant into writing false information into a user's long-term memory that then persisted into future conversations. SafeBreach Labs later showed the same class of attack driven from notifications, and Google confirmed mitigations for that research in November 2025.
For security leaders the takeaway is direct. Agents remember, and attackers can influence what they remember. Memory is a persistence layer with trust boundaries, provenance problems, and a lifecycle that most security programs do not yet monitor. This article defines the runtime memory attack surface, introduces the CSPI Memory Trust Lifecycle model for locating controls, sets out a validated attack taxonomy, maps the risk to recognized frameworks, and gives red teams, SOC teams, and architects a concrete way to test for, detect, and contain it.
Why agent memory changes the security model
Traditional application security assumes state is written by trusted code paths and read back with known provenance. Agent memory breaks that assumption. An autonomous agent decides for itself what is worth remembering, writes that content into a store, and later retrieves it as if it were reliable context. When any part of that content originated from untrusted input, the agent has effectively authored its own persistent instruction that no human reviewed.
Memory creates persistence, and persistence is what turns a transient failure into a standing liability. A stateless model that misbehaves under a malicious prompt returns to baseline on the next call. A stateful agent that has been convinced to store a false fact, a hidden instruction, or a corrupted preference carries that corruption forward. The compromise outlives the session that created it.
Persistence also changes who is affected. In single-user assistants, poisoned memory follows the user across every future task. In shared or multi-tenant deployments, a poisoned entry in a common store can reach users who never encountered the original malicious input. In multi-agent systems, one agent's memory can be inherited or read by others, so the corruption propagates along trust relationships the designers assumed were internal and safe. One successful write can survive sessions and, in the worst designs, cross users.
The security model therefore has to expand from "was this input handled safely" to "what did the agent choose to remember, on whose authority, and what will it do the next time it reads that memory back." Existing controls rarely answer that.
What AI agent memory poisoning is
AI agent memory poisoning, sometimes written as an AI memory poisoning attack, is any attack that causes an agent to persist attacker-influenced content and later act on it as trusted state. The essential ingredients are a write path that untrusted content can reach, a store that retains it, and a retrieval path that feeds it back into the agent's reasoning without re-establishing its provenance.
Agents hold several kinds of memory, and the attack surface differs for each. Short-term or working memory is the in-context history of the current session. It is volatile and clears when the session ends, so corrupting it is closer to conventional prompt injection with a short lifespan. Long-term memory is the persistent store that survives sessions, and it is the primary target of memory poisoning because writes there endure. User-profile memory holds personalization data such as stated preferences, roles, and facts about the user; poisoning it lets an attacker rewrite the agent's model of who the user is and what they are allowed to do. Vector-database-backed and knowledge-base memory holds embedded documents and past interactions retrieved by similarity; poisoning it means planting content that will be recalled whenever a future query is close enough in embedding space.
Not every kind of memory carries the same risk, and not every store is labeled "memory." Chat history, saved preferences, retrieval corpora, cached tool results, and scratchpad notes can all act as persistent state that influences later behavior. If an agent can write to it and later read it back as context, it is part of the memory attack surface, whatever the vendor calls it.
The agent memory trust lifecycle
The clearest way to reason about memory poisoning is to follow a single piece of content through the agent's memory lifecycle and ask, at each step, whether trust is being established or merely assumed. CSPI models this as the Memory Trust Lifecycle, a six-stage chain with a memory trust boundary at every transition.
External input. Content arrives from a document, a web page, a tool result, a message, or another agent. The trust boundary here is the oldest one in security: data from outside is untrusted until proven otherwise. The control is to classify input by source and attach provenance so its origin is known downstream. Most agents skip this, treating retrieved content as neutral information.
Agent decision. The agent decides whether the content is worth remembering. This is a trust boundary that traditional systems do not have, because the decision to persist is being made by a model that can be manipulated by the very content it is judging. The control is to treat the decision to write as a privileged action governed by policy, not a free choice the model makes based on untrusted text.
Memory write. The agent invokes a memory or storage tool. This is where poisoning is committed. The control is write authorization: the write path should enforce who and what may persist content, and untrusted input should not be able to trigger a sensitive write on its own. The Gemini attacks are precisely a failure at this boundary, where a poisoned document convinced the agent to call the memory tool.
Memory storage. The content sits in the store, now indistinguishable from legitimately learned facts unless provenance was recorded. The controls are integrity, provenance metadata, isolation between users and tenants, and retention or expiry policies so that stale or unverified entries do not live forever.
Future retrieval. In a later session, the agent retrieves the entry as context. This is the boundary most systems ignore entirely. Content that was untrusted at write time is now read back as trusted context, its origin forgotten. The control is to re-evaluate trust at retrieval, carrying provenance forward so the agent knows a memory came from untrusted input rather than a verified source.
Agent action. The agent acts on the retrieved memory, which may mean answering, calling a tool, moving money, or instructing another agent. The controls are least privilege and human approval for consequential actions, so that even a trusted-looking but poisoned memory cannot translate directly into high-impact action.
The lifecycle makes the core failure pattern visible: memory poisoning succeeds when provenance is lost between write and retrieval, so that untrusted content is silently promoted to trusted state.
Memory poisoning attack taxonomy
Memory poisoning is a family of techniques, not a single attack. The following classes are distinct in mechanism and in the defenses they require. Each assumes the attacker can influence content that reaches a write path; how that content arrives, whether by injection, a malicious document, a poisoned corpus, or a compromised tool, is the entry vector and is covered by the prompt injection and MCP articles referenced later.
Persistent prompt injection through memory. A prompt injection is used not for immediate effect but to get a malicious instruction stored, so it re-executes whenever the memory is recalled. This is the persistence outcome of injection and the reason memory poisoning is more dangerous than a one-shot prompt: the injection is decoupled in time from its execution. The Gemini and ChatGPT memory attacks fall in this class.
Memory write poisoning. The attacker targets the write path itself, causing the agent to persist attacker-chosen content. The distinguishing feature is control over what gets written rather than merely what gets read. Weak or absent write authorization is the root cause.
Cross-session memory contamination. Poisoned content written in one session influences behavior in later, unrelated sessions. This is the defining persistence property of the whole family and the reason detection is hard: the malicious action and its consequence can be days or weeks apart.
User-profile memory abuse. The attacker corrupts personalization or profile memory, for example by planting a false role, entitlement, or preference. The agent then treats the user, or the attacker, as something they are not, which can unlock behavior the real authorization model would deny.
Shared or multi-tenant memory poisoning. In deployments where a memory store is shared across users or tenants, a poisoned entry can reach victims who never interacted with the attacker. This converts a single write into a broadcast and is one of the highest-impact designs to get wrong.
Multi-agent memory inheritance. In agentic systems where agents read each other's memory or pass state along a chain, a poisoned memory in one agent propagates to others that inherit or query it. The corruption travels along internal trust relationships that were never designed as security boundaries.
Memory laundering. This is the provenance-stripping effect that makes the family work. A malicious instruction that would be rejected as untrusted input gains trust simply by being stored and later recalled as "memory." The store launders the content's origin: what enters as attacker-controlled text leaves as trusted agent knowledge. Every class above ultimately depends on this loss of provenance.
Privilege escalation through trusted memory. Because agents tend to treat their own memory as authoritative, poisoned memory can act as a confused-deputy lever. An instruction the agent would refuse from untrusted input is followed when it appears to come from its own trusted state, letting the attacker reach actions and data that direct requests would not.
These are attacks: they require an adversary and produce adversary-chosen outcomes. They should be kept separate from reliability problems that resemble them but have no attacker. Stale memory, where a once-correct entry is now outdated, incorrect memory, where the agent stored a genuine mistake, and accidental retention, where sensitive data lingers longer than intended, are integrity and lifecycle issues. They matter, they belong in the same governance program, and some of the same controls help, but classifying every memory defect as an attack inflates the threat model and dilutes the response. The security thesis is specific: an adversary influencing what an agent persists and later trusts.
Memory poisoning versus related AI security risks
Memory poisoning sits alongside several other AI risks, and the boundaries matter for both defense and diagnosis. The table below separates them by the surface they attack, the trust boundary they break, how long their effect persists, and the defense that matters most.
| Attack surface | Trust boundary broken | Persistence model | Primary defense |
|---|---|---|---|
| Prompt injection | Untrusted input treated as instruction | Session-scoped unless persisted | Input isolation, instruction and data separation |
| Memory poisoning (this article) | Untrusted content promoted to trusted state | Cross-session and durable | Provenance at retrieval, write authorization |
| MCP tool poisoning | Untrusted tool definition trusted by the agent | Persists while the tool is connected | Tool provenance, pinning, and review |
| AI supply chain attacks | Untrusted build-time model or package artifact | Persists in the deployed artifact | Signing, provenance, build-time verification |
| RAG poisoning | Untrusted document trusted as retrieved knowledge | Persists in the corpus until removed | Corpus curation, retrieval provenance |
Two boundaries deserve emphasis. Prompt injection is the entry vector; memory poisoning is what makes its effect durable, so the two are complementary rather than duplicative. RAG poisoning overlaps with memory poisoning where a retrieval corpus is also the agent's memory, so the intersection, a poisoned document that becomes recalled agent memory, belongs here, while the broader work of hardening a retrieval pipeline is its own topic. MCP tool poisoning and AI supply chain attacks are different layers entirely: the tool trust layer and the build-time artifact layer respectively, in contrast to the runtime state layer this article owns.
A realistic enterprise scenario
The following scenario is a composite constructed from documented attack mechanics. It describes no real client and exists to show how the pieces combine in a plausible enterprise setting.
A mid-size firm deploys an internal operations agent with long-term memory so it can remember process details, team preferences, and prior decisions across sessions. Staff routinely ask it to summarize documents. An attacker sends a business-looking document containing an embedded instruction that, on a later turn, asks the agent to save a small set of "standing preferences" into its long-term memory. An employee summarizes the document, answers a follow-up question with "yes," and the agent writes the attacker's content into memory. Nothing visibly wrong happens.
The business impact arrives later and elsewhere. Days afterward, unrelated employees ask the agent routine questions. Because the poisoned entry is retrieved as trusted context, the agent now quietly applies the attacker's standing preference, for example routing certain approvals differently or treating a specified external address as an authorized contact. The malicious write and the harmful action are separated in time and, if the store is shared, in person, so no single interaction looks like an attack.
Traditional controls miss this for structural reasons. Input filtering examined the document at ingestion and found ordinary text; the malicious effect required a later user turn to trigger the write, so real-time injection defenses that avoid sensitive tools on untrusted data can still be bypassed by delayed invocation. Logging captured a normal memory write among thousands. Endpoint and network monitoring saw an approved agent behaving within policy. The gap is that no control tracked the provenance of the memory from untrusted input through to the action it later drove. That provenance gap, not a single exploited bug, is what memory poisoning depends on.
Framework mapping
Memory poisoning maps to recognized frameworks, though the coverage is uneven and some identifiers are newer than others. The mappings below are drawn from the frameworks themselves; where a framework does not publish a specific identifier, this article says so rather than inventing one.
| Framework | Identifier | Coverage |
|---|---|---|
| OWASP Agentic AI: Threats and Mitigations v1.0 (Feb 2025) | T1 Memory Poisoning | The first named threat in the taxonomy; exploiting short and long-term memory to inject false or malicious data that alters later decisions |
| OWASP Top 10 for Agentic Applications | ASI06: Memory & Context Poisoning | Persistent memory, retrieval, or context shaped to mislead future steps; OWASP cites the Gemini memory attack as the reference incident |
| OWASP Top 10 for LLM Applications 2025 | LLM04 Data and Model Poisoning | The memory or knowledge store as a poisoned data source |
| OWASP Top 10 for LLM Applications 2025 | LLM01 Prompt Injection; LLM06 Excessive Agency | The injection that seeds memory, and the autonomy that turns a poisoned memory into action |
| NIST AI 100-2e2025 | Data poisoning; indirect prompt injection (NISTAML.015) | Names poisoning and indirect injection; the specific memory-persistence framing is analyst-assigned, not a distinct NIST identifier |
| NIST AI 600-1 (Generative AI Profile) | Information Security (Section 2.9) | Treats injection and poisoning as generative-AI information-security risks |
| MITRE ATLAS | No dedicated memory-poisoning technique | ATLAS does not currently publish a memory-specific technique; the write vector aligns with AML.T0051.001 Indirect Prompt Injection, and downstream actions are analyst-assigned per engagement rather than a fixed mapping |
The strongest single hook is OWASP, where memory poisoning is T1 and ASI06. The honest gap is MITRE ATLAS, which has no memory-specific technique today, so teams should map the injection write path to indirect prompt injection and treat any downstream ATT&CK crosswalk as analyst judgment, not a published mapping.
How to Test AI Agent Memory Poisoning
Testing memory poisoning means treating memory as both a write target and a read target, and proving whether a poisoned write survives to influence a later action. CSPI runs it as a repeatable four-phase sequence rather than a single payload, as part of a broader agentic AI red teaming engagement. Each phase has one security objective, and a finding only counts when it connects a write path to a persistent, consequential action.
Phase 1: Memory Architecture Discovery
The first phase maps what the agent can remember and where that memory lives, because you cannot test a trust boundary you have not located. Testers establish what information is allowed to become agent memory, and where each store is held: long-term memory, user profiles, vector stores, retrieval corpora, cached tool outputs, and conversation history. They record whether a given store is user-specific, shared across users, or organizational, since a shared or organizational store multiplies the blast radius of a single poisoned entry. They map which systems and code paths can write to memory, the retention lifecycle of each store, and what deletion and recovery controls exist. Testers also account for implicit memory that forms without an explicit write, such as conversation summaries, learned user preferences, and embeddings generated from ingested content, because these derived stores are easy to overlook and just as capable of carrying a poisoned instruction forward. Each store is classified by sensitivity, so a finding in an organizational store that feeds financial or access decisions is weighted above one in a disposable cache. Anything writable and later readable is in scope.
Security objective: determine the memory trust boundary, the line between information the agent treats as its own established knowledge and information that merely arrived from outside.
Phase 2: Memory Trust Assessment
The second phase tests whether the agent can tell trusted memory from untrusted information that has been laundered into a store. Testers probe whether untrusted data can become persistent memory at all, whether provenance is tracked from the point of capture, and whether any validation runs before a memory write commits. They look for cross-user memory contamination, where content from one user's session can shape state that another user later retrieves, and for unauthorized modification paths that let content reach a store without passing an approval step. Locating the six transitions of the Memory Trust Lifecycle in the real system shows where provenance is established, carried, or lost, and lost provenance between write and retrieval is the primary finding to hunt for.
Security objective: determine whether the agent can distinguish trusted memory from untrusted information.
Phase 3: Persistence and Impact Validation
The third phase proves consequence, not just the existence of a weak write path. Testers plant a benign but distinctive marker through a write path, then confirm whether it survives beyond the session that created it, whether a fresh conversation retrieves the poisoned state, and whether that state actually changes a later decision rather than sitting inert. In agentic systems they confirm whether a marker written to one agent's memory is inherited or read by other agents and automated workflows downstream, since propagation turns a single poisoned entry into a systemic one. Every confirmed path is tied to a concrete business impact: the specific unauthorized action, disclosure, or decision that persistent manipulation can drive, and the number of sessions it remains live. Testers favor a harmless canary fact that is trivial to detect on retrieval yet plausible enough to be stored, which lets them measure dwell time and confirm the result reproduces across attempts rather than firing once by chance.
Security objective: measure the real-world impact, not only the existence of a weakness.
Phase 4: Defensive Control Validation
The final phase verifies that the controls meant to contain memory poisoning actually work under test, rather than only on paper. Testers exercise memory approval workflows, provenance tracking, and memory access controls, then confirm that the write, the retrieval, and the resulting action are logged with enough detail for defenders to reconstruct the full chain. They validate that the organization can review and delete an individual memory entry on demand, and that sensitive or high-privilege writes require human approval rather than completing silently. If the blue team cannot trace a memory entry from its source through retrieval to the action it caused, that gap is itself a reportable finding, because undetectable persistence is the condition that makes memory poisoning dangerous. They also confirm that recovery works in practice, that a poisoned entry can be identified, rolled back, and verified gone without disturbing legitimate memory, and that approval and review steps are enforced by the system rather than left to operator discipline.
Security objective: confirm remediation effectiveness.
The five areas below summarize what each part of a memory security assessment is trying to answer.
| Testing Area | Security Question |
|---|---|
| Memory Discovery | What can become persistent state? |
| Trust Assessment | Who can influence memory? |
| Persistence Testing | Does manipulation survive sessions? |
| Impact Validation | What decisions can affected memory influence? |
| Control Testing | Can the organization detect and remove poisoned memory? |
The output is not "the agent can be prompt injected," which is assumed, but "a poisoned write persisted for N sessions and caused a specific unauthorized action, and here is where provenance was lost."
Detection methodology for SOC teams
Detecting memory poisoning requires visibility into memory as a first-class asset, because the malicious write and the harmful action are separated in time and the action itself often looks legitimate. The following controls give a SOC a chance to catch it.
Memory provenance. Record where each memory entry came from: source, input classification, the session and user that created it, and whether the originating content was trusted. Provenance is the single most valuable signal, because it is what lets an analyst tell learned facts from laundered instructions.
Memory change monitoring. Treat writes to long-term memory as security-relevant events. Monitor for unexpected writes, writes triggered while processing untrusted content, and writes that follow a delayed-confirmation pattern.
Unexpected behavioral changes. Watch for agents whose behavior shifts without a corresponding code, prompt, or policy change. A behavior change with no legitimate cause is a strong indicator that state was altered.
Agent action correlation. Correlate consequential actions back to the memory entries that informed them, so a suspicious action can be traced to the write that seeded it and, ideally, to the untrusted input behind that write.
User and session attribution. Attribute both writes and retrievals to specific users and sessions. In shared stores this is what surfaces cross-tenant contamination, where an entry created by one identity influences another.
Memory review workflows. Establish scheduled human or automated review of persistent memory for anomalous, unverified, or high-privilege entries, and a defined path to quarantine or revoke them. Memory that is never reviewed can be poisoned indefinitely.
Defensive architecture
No single control stops memory poisoning; the defense is layered along the lifecycle so that a failure at one boundary is caught at the next, placing controls where the trust transitions actually occur.
Memory isolation. Separate memory by user and by tenant so a poisoned entry cannot cross identities. Shared stores should be the deliberate exception, not the default.
Write authorization. Govern the write path so untrusted input cannot trigger a persistent, sensitive write on its own. Sensitive writes should require an authenticated, policy-checked path rather than the model's unaided judgment on untrusted text.
Provenance tracking. Tag every memory entry with its origin and trust level at write time and carry that metadata through to retrieval, so the agent knows whether a memory came from a verified source or from untrusted input. This is the control that defeats memory laundering.
Expiration policies. Give memory a lifecycle. Time-bound or review-bound entries so unverified content does not persist indefinitely, which limits both poisoning and stale-memory risk.
Human approval for sensitive memory writes. For memory that can influence high-impact behavior, insert a human checkpoint at write time, so the most dangerous entries are not created silently by untrusted content.
Least privilege. Bound what any acted-on memory can cause. If a poisoned memory cannot reach money movement, data exfiltration, or privileged tools without additional authorization, its impact is capped even when a write slips through.
Memory monitoring. Instrument writes, retrievals, and actions with enough provenance for detection and response, feeding the SOC signals described above.
The organizing principle is that provenance must survive the whole lifecycle and consequential action must require more than a trusted-looking memory.
Governance recommendations
Memory poisoning is ultimately a governance problem as much as a technical one, because it asks who owns the agent's persistent state and who is accountable when that state goes wrong. Organizations that treat agent memory as an ungoverned convenience will not detect poisoning until it causes harm.
Three commitments matter. First, assign ownership of the memory lifecycle. Someone must be accountable for what agents may persist, for how long, with what provenance, and with what review, in the same way data stores have owners. Second, extend AI governance to cover memory explicitly, including retention, isolation, and the classification of what content is allowed to become durable state. Third, govern agent memory as part of the broader enterprise knowledge and AI-readiness program, because an agent's memory is enterprise data with the added risk that the agent can write to it autonomously. Getting the knowledge and governance foundation right before scaling agents is what keeps memory a managed asset rather than an unmonitored attack surface. Organizations that want this tested rather than assumed can engage our AI Red Teaming practice to assess the memory attack surface end to end.
The AI Agent Memory Poisoning Maturity Model
Organizations rarely jump from no controls to continuous validation. The following model gives security teams a way to place themselves and a direction to move, mirroring the staged approach CSPI uses for prompt injection.
| Level | Name | Capability |
|---|---|---|
| 0 | No memory governance | Memory is used for capability with no security consideration; no provenance, isolation, or review |
| 1 | Basic cleanup and filtering | Some input filtering and occasional memory clearing, but no provenance and no cross-session testing |
| 2 | Memory boundaries and review | Per-user and per-tenant isolation and periodic human review of persistent memory |
| 3 | Controlled writes and provenance | Write authorization and provenance metadata carried from write through retrieval; expiration policies in place |
| 4 | Detection and response | Memory writes, retrievals, and actions are monitored and correlated, with a defined path to quarantine poisoned entries |
| 5 | Continuous red-team validation | Memory poisoning is tested continuously, including cross-session and multi-agent propagation, with findings driving control changes |
The levels are cumulative: provenance at Level 3 is what makes Level 4 detection meaningful, and detection is what makes Level 5 validation actionable. Most enterprises deploying agents today sit at Level 0 or Level 1, which is why memory poisoning research keeps succeeding.
Frequently Asked Questions
What is AI agent memory poisoning?
AI agent memory poisoning is an attack that causes an AI agent to store attacker-influenced content in its persistent memory and later act on it as trusted state. Unlike a one-time prompt injection, the poisoned entry survives across sessions and can shape the agent's decisions days or weeks later, which makes the compromise durable and harder to detect.
Is memory poisoning the same as prompt injection?
No. Prompt injection is the entry vector, the way malicious instructions reach an agent through data it reads. Memory poisoning is what happens after that content becomes persistent state the agent trusts and retrieves later. A prompt injection that is cleared affects one session; the same injection written into long-term memory becomes a reusable, time-delayed implant. They are complementary risks, not synonyms.
Can AI agents be compromised through memory?
Yes, and it has been demonstrated publicly. In 2025 a security researcher used a poisoned document to make Google Gemini save false information into a user's long-term memory that persisted into later conversations, and SafeBreach Labs showed a related attack driven from notifications. Any agent that can write untrusted-influenced content to a store and read it back as context is exposed.
How do attackers poison AI memory?
Attackers get untrusted content onto a write path the agent uses to persist state, often through an injected instruction, a malicious document, or a poisoned retrieval corpus, sometimes using a delayed, user-confirmed step to bypass real-time defenses. The store then loses the content's origin, so it is recalled later as trusted memory rather than untrusted input. This provenance loss is the core mechanism.
How do you test agent memory security?
Professional testing identifies every memory store and write path, plants a distinctive benign marker through a write path, and then proves whether it persists and is retrieved in a fresh session to influence a later action. It also checks multi-agent propagation, whether poisoned memory can drive privileged actions, and whether the write, retrieval, and action were logged with enough provenance for defenders to trace them.
How can organizations prevent memory poisoning?
Prevention is layered along the memory lifecycle: isolate memory by user and tenant, authorize sensitive writes so untrusted input cannot trigger them, tag every entry with provenance and carry it through to retrieval, expire unverified entries, require human approval for high-impact memory writes, and apply least privilege so a poisoned memory cannot reach critical actions. Monitoring writes and retrievals gives the SOC the signal to detect what slips through.
What kinds of memory are most at risk?
Long-term memory is the primary target because writes there endure, followed by user-profile memory, whose corruption changes the agent's model of who a user is, and vector or knowledge-base memory, where poisoned entries are recalled by similarity to future queries. Short-term session memory is lower risk because it clears when the session ends, behaving more like conventional prompt injection.
Is every memory error an attack?
No. Stale memory, honest mistakes stored as facts, and sensitive data retained too long are integrity and lifecycle problems, not attacks, because they lack an adversary and adversary-chosen outcomes. They belong in the same governance program and share some controls, but treating every memory defect as an attack inflates the threat model. Memory poisoning specifically requires an attacker influencing what the agent persists and later trusts.
How is memory poisoning classified in security frameworks?
It is the first named threat, T1 Memory Poisoning, in the OWASP Agentic AI Threats and Mitigations taxonomy, and ASI06 Memory & Context Poisoning in the OWASP Top 10 for Agentic Applications. It also relates to LLM04 Data and Model Poisoning and, through its entry vector, LLM01 Prompt Injection. MITRE ATLAS has no dedicated memory technique today, so the write path is mapped to indirect prompt injection and downstream actions are treated as analyst-assigned.