They create risk over time because the harmful effect may only appear after multiple retrievals, sessions, or task iterations. That means teams cannot rely on a single review of the original interaction. The relevant control question is whether the agent’s remembered state remains authoritative and attributable as it ages.
Why memory poisoning becomes a governance problem over time
Memory poisoning is not just a bad response in the moment, it is a delayed-control problem. Harm can sit quietly in remembered state until later retrievals, sessions, or task iterations turn it into action. That means governance has to treat memory as mutable operational state, with ownership, retention, and review rules, not as a passive cache of harmless notes.
How poisoned memory changes the control model
Once an agent can retrieve stored memory, the security question shifts from “was the original interaction reviewed?” to “can this remembered state still be trusted now?” The answer depends on whether memory is isolated, whether write permissions are constrained, and whether the system can distinguish durable facts from untrusted or attacker-influenced content. Governance weakens when teams assume the first approval is enough for all later use.
That is why memory poisoning is especially problematic in workflows that reuse context across sessions. A small injected instruction can survive long enough to influence planning, routing, tool use, or escalation decisions later, even when the original prompt looks harmless in isolation. The control failure is cumulative: each retrieval can amplify the effect of a stale or compromised memory item.
What governance teams need to manage instead of one-time review
Governance needs to manage memory like an asset with lifecycle risk. That includes deciding who can write to memory, which memories expire, which memories must be attributable to a source event, and what should be excluded entirely, such as secrets or high-impact instructions. The practical test is whether the remembered state can still be justified after context has aged and the original interaction is no longer in view.
That also changes accountability. If a later action was driven by memory rather than the latest verified input, teams need a way to trace that decision back to the source of the memory, the time it was written, and any intervening modifications. Without that lineage, governance becomes retrospective guesswork instead of controlled operation.
Risk and Threat Considerations
Poisoned memory creates a slow-burn exposure because the harmful content may remain dormant until a later retrieval makes it operational. The longer memory lives, the more chances it has to influence decisions, cross session boundaries, or spread through reused context.
Failure mechanism: An attacker or careless input plants misleading state in memory, then waits for the agent to reuse that state in a later session, where it can alter behaviour without a fresh prompt compromise.
Impact: The result can be repeated bad decisions, hidden policy drift, unauthorized tool use, or persistent cross-session influence that is difficult to attribute to a single event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack surface, NIST AI RMF and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI06 — Memory & Context Poisoning | Memory poisoning is the core failure mode in this question. |
| Recommendation — Constrain memory writes and validate reused context before it drives later actions. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Stale remembered state can outlive its trust window and keep influencing behaviour. |
| NHI-10 — Human Use of NHI | Governance risk grows when humans rely on agent memory without revalidation over time. | |
| Recommendation — Expire or revoke memory entries when their source context is no longer trustworthy. Require human review before memory-derived actions cross material risk thresholds. | ||
| NIST AI RMF | Govern | This is a governance-over-time issue for AI state, accountability, and ongoing oversight. |
| Recommendation — Define ownership, review cadence, and escalation paths for persistent agent memory. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Attribution and review of memory-driven decisions depend on traceable records. |
| Recommendation — Correlate memory writes and later actions in audit logs for investigation and review. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access to memory writes and retrievals must be governed to limit poisoned state. |
| Recommendation — Restrict who can write, modify, and retrieve persistent memory. | ||
Practitioner Guidance
What to verify: Verify that memory entries have a source, an owner, and a purpose, and that the system can show when each item was last reviewed or superseded. If you cannot tell where a memory item came from, treat it as untrusted until proven otherwise.
What good looks like: The safest pattern is narrow memory scope, explicit expiry, and a clear rule for when memory may influence future actions. Memory should support continuity, not become a hidden authority that outranks current input.
Practitioner takeaway: The governance mistake is to review memory once and then trust it indefinitely, when the real control problem is continuous authority over time.
Related resources from NHI Mgmt Group
- Why do virtualisation platforms create governance risk over time?
- Why do collaboration groups create governance risk when they accumulate standing access over time?
- Why do AI agents create new risk in non-human identity management?
- When does just-in-time access reduce risk for agentic AI, and when does it fall short?