MnemoverseDocs

Appearance

Edward Izgorodin·Published Jul 13, 2026

Shared Memory Poisoning: One Bad Write, Many Agents ​

TL;DR

  • A shared pool can expose multiple agents to one poisoned memory, but no public study has measured that full N-consumer path end to end.
  • ElizaOS researchers demonstrated a cross-platform, cross-user redirect through common memory on a deployed open-source framework. The confirmed transaction used Sepolia testnet, not real user funds.
  • Writer-trust, space-trust, and operator-trust are separate decisions. A poisoned pool can fail the first while the other two remain intact.
  • Consumers should retrieve provenance, restrict write access, segment spaces, and treat stored memory as untrusted input.

A shared memory pool is a single persistent memory space that more than one agent—often across accounts, vendors, or tasks—writes to and reads from.

Memory poisoning is a persistent injection attack that corrupts an agent's stored memory or context so a later retrieval changes its behavior.

The single-agent attack chain ends with one assistant consuming its own poisoned history. Shared memory changes the exposure model. A single-agent poisoning harms one assistant's future self; a shared pool turns one poisoned write into an exposure for every consumer that drinks from the same well—including consumers that never interacted with the original source.

That possibility is no longer purely hypothetical. Researchers demonstrated the mechanism on ElizaOS, a deployed open-source framework.

Shared memory poisoning in ElizaOS ​

The paper “Real AI Agents with Fake Memories” describes a common-memory path across ElizaOS plugins:

“Because all ElizaOS plugins draw from the same shared memory, due to using a common orchestrator, a malicious entry injected via one platform (e.g., Discord) propagates across the entire ecosystem.”

The demonstration crossed both platform and user boundaries. Section 4.1.1 reports that “a memory injection on Discord can even attack a user on X.” A crafted injection through the Discord client altered the stored context. When a later user on X requested a crypto transfer, the agent redirected the funds to the attacker's wallet.

This was a demonstrated-on-deployed-framework result, not a confirmed in-the-wild breach. The confirmed transaction ran on Sepolia, an Ethereum testnet. The work evaluated 150+ realistic blockchain tasks and 500+ attack test cases. No real user funds were reported lost.

The important boundary is not Discord versus X. It is the common pool between them. The later consumer never received the original malicious message; retrieval carried the state across the boundary.

The shared-pool multiplier, honestly ​

The intuitive claim is simple: if one poisoned memory can affect one consumer, a shared pool may let that memory affect every consumer that retrieves it.

That multiplier is a constructed projection, not a measured end-to-end result. No cited paper measures one poisoned write entering a shared database and then compromising N distinct consumers. Torra and Bras-Amorós state that inter-agent memory-poisoning risks “are not so much studied in the literature and are difficult to formalize and solve.”

Several demonstrated results make the projection credible without proving it.

First, poisoning can work at a low poison rate. AgentPoison reports an average attack success rate higher than 80%, less than 1% impact on benign performance, and a poison rate below 0.1% of the knowledge base. Those results are averages across three RAG or long-term-memory agents: an autonomous-driving agent, a knowledge-intensive question-answering agent, and a healthcare EHRAgent. They do not measure a shared multi-writer pool.

Second, shared communication can expand reach. Prompt Infection found that self-replicating infection had an attack success rate about 20% lower with local messaging than with global messaging. The paper attributes the gap to shared message history: local infection fails if one agent remains uncompromised, while global messaging preserves the infection in common history. This is a success-rate difference, not a timing result.

Third, multi-agent interaction can produce large simulated fan-out. Agent Smith simulated environments containing up to one million LLaVA-1.5 agents. A single adversarial image seeded an infectious jailbreak through randomized pairwise chat. The figure is a simulation ceiling, not a count of real agents. The setting is multimodal, and pairwise chat is not a central shared database. It supplies scale intuition, not evidence for literal database fan-out.

Morris-II adds the adjacent worm framing: a zero-click, self-replicating prompt can cascade indirect prompt injections across an email-assistant ecosystem using RAG-shared context. That environment is related to, but not identical to, a shared memory pool.

There is also a material counterweight. Research on memory-based EHR agents found that “realistic conditions with pre-existing legitimate memories dramatically reduce attack effectiveness.” In that single-agent MIMIC-III setting, malicious entries had to compete with legitimate memories for retrieval. This retrieval dilution made the poisoned demonstration less likely to be retrieved and acted on than in an empty or idealized store. The over-95%-injection and 70%-attack-success figures often cited in this area belong to MINJA—a prior work the EHR study cites that measured them under idealized conditions—not the EHR study's own result.

Dilution does not prove a shared pool is safe. It shows why an empty-store result should not be treated as the expected outcome in a populated system.

The defensible conclusion is narrower than “one write compromises everyone.” Shared storage creates a potential fan-out path. Poisoning efficiency, shared-history reach, and simulated propagation support that projection. Retrieval competition and consumer controls constrain it.

Three kinds of agent memory trust ​

A consumer reading shared memory makes three trust decisions that systems often collapse into one. This table is our analytical lens, not an existing taxonomy.

TrustThe question the consumer is really askingWhat fails under a poisoned poolWhat holds it up
Writer-trustDo I trust whoever wrote this specific memory?This trust fails. An untrustworthy, impersonated, or injected source produces a memory that looks ordinary at retrieval time.Provenance on read, writer reputation, and treating cross-account memories as untrusted input
Space-trustDo I trust the space's membership and admission rules?It can remain intact. A poisoned write may enter through a legitimate but compromised member.Validated writes, membership scopes, write restrictions, and segmentation by space
Operator-trustDo I trust the operator or substrate running the store?It can remain intact. An honest operator can preserve an atom that was already poisoned at its source.Tenant isolation, tamper-evidence, and storage-time provenance

The central distinction is easy to miss: a poisoned pool can fail writer-trust while space-trust and operator-trust both hold.

That is why infrastructure integrity alone cannot establish content integrity. The operator may store exactly what it received. The space may admit only authenticated members. Neither fact proves that a specific stored memory is safe to consume.

Identity trust remains a separate concern. Agent-to-agent authentication and delegation ask whether a peer is who it claims to be and what it may do. Shared-memory security asks whether knowledge attributed to that peer should influence a later decision.

The distinction also supplies a concrete threat case for the provenance problem in agent memory interoperability: portable memory needs enough source context for a consumer to make its own trust decision.

Multi-agent memory security controls ​

The OWASP Top 10 for Agentic Applications names ASI06 “Memory & Context Poisoning.” Its mitigation vocabulary fits shared pools directly:

  • gate and validate writes;
  • track provenance and source trust;
  • segment memory by scope;
  • treat stored memory as untrusted input.

The long-term-memory security survey adds a lifecycle view. It names “Share & Propagate” as one of six memory phases and concludes that robust security cannot be added at retrieval or execution alone. It must begin with “storage-time provenance, versioning, and policy-aware retention.”

Storage-time provenance is necessary, but consumers must receive and use it. One implementation example is the Mnemoverse Rooms API: returned items carry domain and authorship provenance, and reads accept authorship filters—author_principal, author_agent, author_client_env, author_is_external—so a consumer can tell who wrote what in a shared space. Membership separates read from read_write: a read-scope member can retrieve everything but change nothing. One instantiation of the pattern, not an endorsement by the survey.

Consumer hygiene checklist ​

Shared-pool defenses should not stop at write admission. Each reader needs a policy for deciding what retrieved memory means.

  1. Retrieve by provenance, not just relevance. Ask for the author and source context with every memory atom. Content without attribution cannot support writer-trust.

  2. Weight by writer-trust. Treat a memory from an unknown or lower-trust writer as a candidate claim, not an established fact.

  3. Treat cross-account memories as untrusted input. Stored memory is input to validate, not an instruction to obey. This applies even when the operator and space remain trusted.

  4. Prefer read scope for consumers. An agent that only consumes shared knowledge should not also have permission to write into the pool.

  5. Segment by space. Keep unrelated trust boundaries in separate pools. Shared storage should not imply universal retrieval.

  6. Gate and validate writes. Check memories before admission because every permitted consumer may later encounter them.

These controls do not assume that every shared memory is malicious. They preserve enough context and separation for each consumer to decide.

Common questions ​

What is shared memory poisoning? ​

Shared memory poisoning is a persistent injection attack in which a corrupted memory can later influence more than one agent reading from the same pool.

Does one poisoned write compromise every agent in a shared pool? ​

Not necessarily. The N-consumer multiplier is a constructed projection, not an end-to-end measured result; retrieval competition, admission controls, segmentation, and consumer validation can limit exposure.

Which trust fails when a shared memory pool is poisoned? ​

In the three-trust lens used here, writer-trust fails while space-trust and operator-trust can remain intact.

Does a populated memory pool make poisoning harder? ​

It can. Research in a single-agent EHR setting found that pre-existing legitimate memories dramatically reduced attack effectiveness through retrieval dilution, but it did not prove that shared pools are safe.

How should agents consume shared memory safely? ​

Retrieve provenance with content, weight memories by writer-trust, treat cross-account memories as untrusted input, restrict consumers to read scope, segment spaces, and validate writes.

By Edward Izgorodin · Published 2026-07-13.