Assistant Memory Poisoning

The corruption of an AI assistant’s long-term memory with attacker-supplied content or intent. Once stored, the poisoned state can influence future sessions, other devices, or recurring behaviours, turning a temporary compromise into durable operational risk.

Expanded Definition

assistant memory poisoning is a persistence attack against an AI assistant’s long-term memory layer, where attacker-controlled content is written into retained state and later reused as if it were trusted context. Unlike a one-off prompt injection, the harmful instruction or false belief can survive session boundaries and shape future responses, routing, or task execution. In NHI Management Group terms, the risk is not just what the assistant saw in the moment, but what it continues to remember and act on later. The distinction matters because memory can be stored in vector databases, profile stores, task histories, or other retrieval systems, and each mechanism has different trust and retention properties. Industry usage is still evolving, and no single standard governs this yet, so teams should be explicit about whether they mean conversational memory, persistent profile memory, or externally managed agent state. For broader governance of enduring identity risk, the Ultimate Guide to NHIs is a useful baseline, while the OWASP Top 10 for Agentic Applications 2026 frames adjacent risks around agentic persistence and tool use. The most common misapplication is treating memory as harmless convenience data, which occurs when untrusted user input is allowed to persist without review, expiration, or provenance checks.

Examples and Use Cases

Implementing memory rigorously often introduces friction, requiring organisations to balance continuity and personalization against the cost of filtering, review, and expiry controls.

• An internal support assistant stores a fabricated escalation preference that causes future tickets to bypass normal approval steps.
• A sales copilot retains a poisoned customer “profile note” and later recommends an unsafe discounting or contract action based on false context.
• A coding assistant remembers an attacker-supplied repository rule and applies it across later sessions, influencing generated scripts and deployment instructions.
• A workflow agent records a malicious “preferred vendor” or “trusted approver” identity and reuses it when composing procurement tasks.
• A memory store ingests a false remediation lesson after a phishing-like interaction, causing repeated unsafe advice in later sessions.

These scenarios become more serious when memory is synchronized across devices or shared across assistants, because one poisoned write can spread laterally through the environment. The Ultimate Guide to NHIs provides the governance backdrop for persistent identity state, and NIST SP 800-53 Rev 5 Security and Privacy Controls helps teams map the supporting control objectives around access, logging, and system integrity.

Why It Matters in NHI Security

Assistant memory poisoning matters because it turns a transient interaction into durable NHI compromise. Once attacker-supplied state is stored, the assistant may repeat it across future tasks, making the compromise harder to detect than a single bad prompt response. That persistence creates governance problems around provenance, review rights, retention, and revocation, especially when the assistant acts with tool access or delegated authority. NHI Management Group research shows that 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, which is a reminder that durable identity misuse often becomes costly after initial exposure. Memory poisoning is closely related to insecure secret handling, excessive privilege, and weak lifecycle controls, because poisoned context can point an assistant toward sensitive assets or unsafe actions. The OWASP Top 10 for Agentic Applications 2026 is relevant here, as is NIST SP 800-53 Rev 5 Security and Privacy Controls for control mapping around integrity and monitoring. Organisations typically encounter the operational damage only after the assistant has reused poisoned memory in a real workflow, at which point memory hygiene becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Who is accountable when an AI assistant memory poisoning incident affects code or systems?
• What breaks when a browser session can modify an AI assistant’s persistent memory?
• How do security teams detect memory poisoning in AI workflows?
• Memory Poisoning (ASI06)