Every practitioner who has worked with databases has an intuitive model of what a log is. Records are written in sequence. They are read in sequence, or filtered by timestamp, or queried by a structured key. The log is passive — it stores what was given to it, in the order it was given, and returns it faithfully when asked. The log does not interpret. It does not prioritize. It does not decide that one record is more relevant to a current task than another.
That model is the one most organizations carry into agentic AI deployments when they think about agent memory. The agent accumulates a record of prior interactions. When it needs context, it reads the record. The record is there, sequentially, faithfully. Nothing in the record takes initiative. Nothing in the record redirects behavior on its own.
Production agent memory does not work this way. It has not worked this way since the earliest LangChain memory implementations. And the gap between the log model practitioners carry and the retrieval model agents actually use is precisely the architectural space where memory poisoning operates.
How Production Memory Retrieval Actually Works
In a production agentic system, memory is not read sequentially. It is retrieved semantically. When an agent begins a new task, it converts the task description into a vector embedding and queries its memory store for entries whose embeddings are most similar. The entries with the highest cosine similarity scores are retrieved and inserted into the context window alongside the current task. The agent uses them as prior-session knowledge to inform its approach.
Semantic Retrieval — The Mechanism
Vector embedding converts text into a high-dimensional numerical representation that captures semantic meaning. Memory entries stored as embeddings are retrieved by similarity search: the current task query is embedded, and the memory store returns the entries whose embeddings are closest in vector space. This means retrieved memory is determined not by recency or sequence but by semantic proximity to the current task — a memory entry written months ago will be retrieved ahead of a recent one if it is more semantically similar to the query.
The implications for security are direct. An attacker who can write a memory entry crafted to be semantically similar to a broad class of future task queries can ensure that entry is consistently retrieved — and consistently present in the context window — without any access to the future sessions themselves. The attacker writes once. The retrieval mechanism delivers the payload automatically, across as many future sessions as trigger the relevant query pattern.
This is why the log model fails as a security mental model. In a log, the only way to influence what is returned to a query is to modify the log’s contents directly — an action that is auditable and detectable. In a semantic retrieval system, an attacker can influence what is consistently returned to a query by writing a new entry optimized for retrieval proximity, without touching any existing entry and without requiring access to the future sessions that will retrieve it.
The attacker does not need to modify the memory store after the initial write. They write a semantically targeted entry once, through authorized user interaction, and the retrieval mechanism does the rest — delivering the payload to relevant future tasks automatically, at retrieval time, from inside the trust boundary.
LogicPoison: When the Attack Goes Deeper Than Text
The semantic retrieval vulnerability operates at the text embedding layer — an attacker crafts a memory entry that is semantically proximate to target query patterns. Xiao et al.’s LogicPoison (arXiv:2604.02954, April 2026) establishes that the attack surface extends further than that, into the relational structure of knowledge graphs used in GraphRAG deployments — and that the relational attack is invisible to every text-level defense.
Detection rate by text-level defenses against LogicPoison topology attacks on GraphRAG systems. Type-preserving entity swapping corrupts the logical connections between knowledge graph nodes — rerouting valid reasoning chains into dead ends — without altering a single word of surface-level text. Standard content filtering, semantic similarity checks, and input sanitization all pass the attack because there is nothing anomalous in the text to detect.
GraphRAG is increasingly the architecture of choice for enterprise agents operating over large, structured knowledge bases — legal and compliance document stores, technical documentation corpora, organizational knowledge graphs. It improves over flat vector retrieval by preserving relational structure: entities and their relationships are modeled explicitly, and retrieval follows the graph topology rather than raw embedding similarity alone. This makes it more accurate for complex multi-hop queries. It also creates a new attack surface that flat vector retrieval does not have.
LogicPoison exploits this surface through type-preserving entity swapping: replacing entities in the knowledge graph with other entities of the same type, preserving the surface-level text’s plausibility while corrupting the logical relationships that reasoning chains depend on. A query that should reach conclusion A, following a valid reasoning path through the graph, instead follows a path that terminates in a dead end, returns an incorrect conclusion, or loops without resolving — because the entities it traverses have been silently substituted for structurally plausible but factually wrong alternatives.
Why Text-Level Defenses Are Structurally Blind
Every text-level defense operates on the content of memory entries — checking for anomalous instructions, injection patterns, unusual phrasing, or semantic similarity to known attack strings. LogicPoison generates attack entries that contain none of these signals. The text is grammatically correct, topically relevant, factually plausible at the surface level, and semantically appropriate for the target domain. The attack lives in the graph topology — in what an entity connects to — not in what the entity says. A defense that cannot inspect and verify relational integrity cannot detect this attack class.
For enterprise GraphRAG deployments, the practical implication is significant. An attacker with write access to the knowledge base — or, in agentic deployments, an attacker who can cause the agent to write to the knowledge base through authorized interaction — can corrupt the reasoning chains the agent relies on for complex multi-hop queries, without leaving any detectable trace in the text content that compliance teams review or security tools scan.
The Sequential vs. Semantic Architecture Gap
Both the MCFA findings from Post 1 and the LogicPoison findings establish the same underlying architectural problem from different angles. The problem is that memory systems used in production agentic deployments operate on a fundamentally different retrieval model than the mental model most security programs are built around.
Sequential, Passive, Auditable
Memory entries are written in sequence and read in sequence or by structured key. What is retrieved is determined by recency or explicit query parameters. No entry takes initiative to insert itself into a future context.
Security model: monitor what is written. An anomalous entry is detectable at write time. Removing it from the log removes it from future retrieval. Access control on write operations is the primary defense.
Content filtering at write time catches malicious payloads. A clean write log means clean future retrieval. The threat model is bounded by what enters the log.
Write-Time Defense · AuditableSemantic, Active, Query-Driven
Memory entries are retrieved by semantic similarity to future task queries. What is retrieved is determined by embedding proximity — not by recency, sequence, or structured parameters. An entry written months ago outcompetes a recent entry if it is more semantically aligned to the current task.
Security model: monitoring write time is necessary but insufficient. A semantically optimized payload passes content filtering at write time because it contains no anomalous text. It executes at retrieval time — inside the trust boundary, indistinguishable from legitimate prior-session context.
For GraphRAG: content filtering cannot detect topology-level corruption. The text is clean. The relational structure is not.
Retrieval-Time Threat · Structurally HarderThe right column describes the system that enterprise agents actually run on. It also describes a system for which the security program most organizations have inherited from their logging and audit infrastructure provides no meaningful coverage. Write-time access controls are necessary — but an attacker who operates through authorized interaction passes them. Content filtering at write time is necessary — but a semantically optimized or topology-level payload passes it. The threat does not live at write time. It executes at retrieval time, from inside the trust boundary, looking exactly like legitimate prior-session knowledge.
Multi-Agent Memory Propagation: The Amplification Problem
Torra and Bras-Amorós (arXiv:2603.20357) extend the memory security analysis to multi-agent architectures and document an amplification dynamic that flat single-agent deployments do not face. In multi-agent systems, memory is frequently shared or propagated across agent boundaries — an orchestrator agent’s memory informs sub-agent behavior, a research agent’s findings are written to a shared knowledge base accessible to downstream processing agents, a customer service agent’s interaction history informs a billing agent’s context.
In multi-agent architectures with shared or propagated memory, a single poisoned memory entry can propagate across agent boundaries — influencing every downstream agent that retrieves from the shared store. Any defective component in the memory reuse chain can compromise the whole system. The blast radius of a single successful memory write is bounded only by the number of agents that retrieve from the same memory surface.
The propagation dynamic means that the blast radius of a single successful memory write in a multi-agent architecture is not bounded by the agent that received the original injection. It is bounded by the scope of memory sharing across the system — which, in enterprise multi-agent deployments, frequently spans the entire agent network. A payload written to the orchestrator agent’s memory propagates to every sub-agent that retrieves shared context. A payload written to a shared knowledge base propagates to every agent that queries it.
Torra and Bras-Amorós establish that the memory types most vulnerable to propagation — semantic memory (domain knowledge) and episodic memory (interaction history) — are also the memory types most valuable for enterprise use cases, and therefore the types organizations are most motivated to share across agent boundaries. The deployment pattern that maximizes enterprise value from multi-agent architectures is the same pattern that maximizes the propagation surface for memory-resident payloads.
Three Architectural Requirements That Follow
The companion post and Post 1 of this series converge on three architectural requirements that cannot be addressed at the application layer through content filtering or write-time monitoring alone.
Retrieval-time integrity verification. Because the threat executes at retrieval time — not write time — security controls must operate at the point of retrieval. This means verifying, at the moment a memory entry is inserted into the context window, that its provenance is attributable, that its content has not been modified since write, and that its scope is appropriate for the current task context. Cryptographic integrity checks for long-term memory, as recommended by the OWASP AI Agent Security Cheat Sheet, address provenance and modification integrity. Task-scoped retrieval filters address scope appropriateness.
Relational integrity verification for GraphRAG. For knowledge graph deployments, text-level integrity is necessary but insufficient. A verified, unmodified graph node can still carry a topology-level attack if its relationships have been corrupted through type-preserving entity swapping. Relational integrity verification — checking that entity relationships conform to the expected schema and that type-preserving substitutions have not been introduced — is a structural requirement that has no equivalent in flat vector retrieval security.
Memory propagation boundaries in multi-agent architectures. Shared memory across agent boundaries must be treated as an untrusted channel, subject to the same structural controls as any other channel capable of influencing agent behavior. This means explicit propagation boundaries — a defined scope for which memory is shared, how, and with what re-verification requirements — rather than the implicit full sharing that most current multi-agent deployments implement for operational convenience.
The attack does not arrive in the session. It arrives through the retrieval mechanism — semantically optimized to be present exactly when the agent needs context, indistinguishable from the prior-session knowledge the agent was built to use.
— Luminity Digital synthesis from arXiv:2603.15125, arXiv:2604.02954, arXiv:2603.20357The log model and the retrieval model are not different implementations of the same security requirement — they are different threat surfaces requiring different defenses. An organization that has addressed write-time security for its agent memory has addressed a necessary precondition. It has not addressed the retrieval-time threat, the relational integrity threat in GraphRAG deployments, or the propagation amplification threat in multi-agent architectures. Post 3 of this series maps the architectural controls that address each threat class structurally.
