AI is known to be at risk from prompt injection, but the threat exists only while a session is active. Researchers are now warning about a technique called memory poisoning, which takes this one step further, allowing attackers to inject misleading or malicious memory items into an assistant's persistent memory layer.

The aim of memory poisoning attacks, according to the recent warning by Forcepoint, is to dupe AI agents into producing false information.

At a time when AI is increasingly integrated into business processes, who is at risk and how should firms respond to the threat?

Memory poisoning risks

David Kasabji, head of threat intelligence at Conscia, explains the difference between prompt injection and memory poisoning. “Prompt injection is tricking an AI assistant during a conversation, and the effect typically disappears when it ends,” he tells IT Pro.

Memory poisoning “goes after what the assistant is allowed to remember afterwards”, according to Kasabji.

“So, a false fact or instruction gets planted once and may be recalled and acted on weeks later, in a conversation the attacker has nothing to do with.”

By injecting malicious or misleading information into an AI’s long-term memory store, an attacker “effectively corrupts the agent’s logic”, says Matt Cooke, cybersecurity strategist at Proofpoint.

This turns the AI into “a persistent risk that can repeatedly output flawed information, compromise workflows, or expose data across future sessions long after the initial breach”, he warns.

Attacks can be easy to perform. Firms could be compromised via ordinary content the assistant was asked to read, such as a webpage or an email. “There may be no malware, stolen credentials or compromised account for traditional security controls to find,” says Kasabji.

Part of the threat model

Any organization deploying AI agents with persistent memory, retrieval-augmented generation architectures, self-learning capabilities or long-running autonomous workflows should “consider memory poisoning as part of its threat model”, according to Rob O’Connor, EMEA CISO at Insight.

Businesses using an AI system that processes external data such as emails, documents, web pages, or support tickets could be a target, says Ray Canzanese, director of Netskope Threat Labs.

Automated agents such as customer service agents or AI assistants that process high volumes of external data are “especially vulnerable”, he adds.

The risk is greatest when an AI assistant “remembers things and is allowed to do things”, particularly when it consumes content from outside the organization, or from sources that many people can modify, says Kasabji.

The threat is compounded by the fact that the impact of memory poisoning may not become visible until weeks or months later. This means compromised memories can influence procurement recommendations, risk assessments or financial workflows “long after the original interaction has been forgotten”, O’Connor warns.

Preparation window

Memory poisoning might sound scary, but it’s not being broadly used by attackers just yet. The technique is primarily being demonstrated by security researchers, which gives organizations a window to prepare, says Kasabji.

He believes the likely evolution is towards attackers using poisoned memory as “a quiet form of persistence”.

“There is no malicious process that needs to keep running, and the poisoned information may remain dormant until a later conversation causes the agent to retrieve it,” Kasabji explains.

As agents increasingly work with one another, firms should expect poisoned context to “spread between systems”, he predicts.

“That matters commercially because testing an assistant once, in one sitting, tells you very little about how it may behave after weeks of accumulated memory."

As enterprise AI shifts from passive chatbots to active, multi-agent workflows with direct access to internal systems, the attack surface expands, adds Cooke. "As these agents gain broader privileges, like querying databases, managing schedules, or executing API calls, memory poisoning will become more sophisticated. We expect attackers to rely heavily on indirect vector injections, hiding poisoned payloads inside third-party data feeds, emails, or shared collaboration platforms.”

Going forward, rather than attempting obvious manipulation, attackers are likely to focus on gradually influencing an agent's understanding over time, O’Connor suggests. This may involve dormant or "sleeper" memories, subtle shifts in recommendations, or poisoning attempts “distributed across multiple interactions to avoid detection”, he predicts.

Identify retained information

It’s a future threat, but right now, there are several steps IT and security leaders can take to prevent memory poisoning from becoming a problem.

Start by identifying where AI systems are retaining information between sessions and what these are subsequently allowed to do, advises Kasabji. “Anything an assistant remembers should carry provenance, including where it came from and when it was created, while unverified or low-trust memories should be subject to review and expiry.”

Kasabji also suggests keeping a person in front of irreversible actions such as payments, contracts and significant system changes, “so that no single poisoned memory can be acted on unchecked”.

Memory poisoning generally requires an attacker to gain access to, or influence over, a data source or connection that an AI agent trusts. Traditional security controls therefore remain “highly relevant”, according to Richard Werner, cybersecurity platform lead, Europe at TrendAI.

He advocates strong access controls, multi-factor authentication (MFA), zero trust principles, least-privilege access, and appropriate network protections to reduce the likelihood that an attacker can manipulate an agent's trusted resources. “Change-control mechanisms, data-integrity monitoring, and data-protection solutions can also help identify unauthorized modifications,” Werner adds.

IT and security teams should focus on building mechanisms to continuously inspect data entering persistent memory layers, with the ability to “flush context if anomalies are detected”, says Cooke.

Cooke advises treating AI agents as “distinct identities, strictly limiting their write permissions and data access”.

At the same time, Cooke advocates establishing clear policies on what data employees feed into AI systems to prevent accidental exposure or corrupt inputs at the source. He suggests evolving defence strategies “to protect the intersection of people data and AI, ensuring complete visibility across automated workflows”.