The pattern across this series is one that recurs throughout the Luminity corpus. A new attack class is documented. Security teams reach for familiar defenses — content filtering, input sanitization, anomaly detection. The research shows those defenses do not reach the threat. The reason, consistently, is that the defenses operate at the wrong layer: they address the channel the content arrives through, not the mechanism by which it influences behavior.
Memory security is the clearest instance of this pattern in the current agentic AI security landscape. The three threats documented in Posts 1 and 2 — Memory Control Flow Attacks operating through semantic retrieval, GraphRAG topology corruption through LogicPoison, and memory propagation amplification in multi-agent architectures — each bypass content filtering by design. Not because the filtering is poorly implemented, but because the attacks do not present malicious content at the point the filtering operates.
MCFA payloads pass write-time content filters because the text is grammatically normal and topically relevant at write time. LogicPoison passes text-level detection entirely because the corruption lives in graph topology, not text. Memory propagation is not an attack on content — it is a property of the architecture. Filtering addresses none of these at the layer where they execute.
The structural controls that follow do not ask the model to detect malicious content. They constrain what memory can reach, what it can do, and what it can influence — regardless of what it says.
The Three Threat Classes and Their Structural Controls
Memory Control Flow Attacks
Payload written through authorized interaction. Executes via semantic retrieval across future sessions. Content filtering passes it at write time.
Structural control: Memory isolation by architecture. Scope memory retrieval to the user context and task type in which it was written. A memory entry written in a customer service session cannot be retrieved in a billing query session. A memory entry written by user A cannot be retrieved in user B’s session.
Memory IsolationGraphRAG Topology Attacks
Type-preserving entity swapping corrupts relational structure. Text is clean — no filtering signal. Reasoning chains are redirected without any anomalous content present.
Structural control: Relational integrity verification. Schema validation on entity relationships at retrieval time — not only at write time. Type-compatible substitutions must be validated against the expected relational schema before the graph node’s connections are used in reasoning.
Relational IntegrityMulti-Agent Propagation
Shared memory across agent boundaries means a single poisoned entry propagates to every downstream agent that retrieves from the shared store. Blast radius is unbounded by the originating agent.
Structural control: Explicit propagation boundaries. Memory sharing across agent boundaries must be explicit, scoped, and subject to re-verification at the boundary crossing. Implicit full-sharing is the default state and the vulnerability.
Propagation BoundariesWhy Filtering Fails Each Threat Class
The consistent failure mode of content filtering against memory-resident attacks is worth making precise, because the same argument will be made for each filtering approach that enterprise teams reach for first.
What Teams Reach for First
Write-time content filtering. Scan memory entries for anomalous instructions, injection patterns, or unusual phrasing before they are written to the store. Fails against MCFA because the payload presents as normal text — topically relevant, grammatically correct, no detectable injection signature.
Semantic similarity anomaly detection. Flag memory entries whose embeddings are statistical outliers relative to the corpus. Fails against semantically optimized payloads that are specifically crafted to be proximate to legitimate memory patterns, not distant from them.
Text-level graph validation. Review knowledge graph nodes for suspicious content. Fails against LogicPoison entirely — the text is clean. The corruption is relational, not textual.
Output monitoring. Detect anomalous agent behavior after the fact. Catches some downstream effects but does not prevent the attack and provides no coverage against slow-burn payloads that redirect behavior subtly across many sessions before the deviation is detectable.
Necessary · Not SufficientWhat Actually Holds
Memory isolation by scope. Structural constraint on what memory can be retrieved and in what context. Does not depend on detecting malicious content — constrains the retrieval path regardless of what the memory entry says. A payload that cannot be retrieved in the target context cannot execute there.
Cryptographic provenance. Every memory entry carries a cryptographically verifiable record of who wrote it, in what session context, at what time. Does not prevent a malicious write through authorized interaction — but it makes every write attributable and creates the audit trail necessary for forensic response and scope assessment.
Relational schema enforcement. Validation of entity relationships against the expected knowledge graph schema at retrieval time. Detects type-preserving substitutions that text-level review cannot see because the violation is structural, not textual.
Explicit propagation boundaries. Memory shared across agent boundaries is re-verified at each boundary crossing. Scoped sharing rather than full sharing as the default — blast radius is architecturally bounded by what is explicitly permitted to cross.
Structural · EnforceableThe Enterprise Implementation Sequence
The three structural controls are not equally urgent for every deployment. The right starting point depends on the memory architecture already in use and the deployment model in production. The sequence below is ordered by the combination of vulnerability severity and implementation accessibility — starting with what is most immediately actionable and protecting against the broadest attack surface.
First: Establish memory isolation boundaries
For any enterprise agent with persistent memory serving multiple users or multiple task types, memory isolation is the highest-priority structural control. The attack surface is immediate — any authorized user can write to the shared memory store through normal interaction — and the defense is architecturally clean. Scope memory retrieval to the user context and task type in which it was written. Enforce this at the retrieval layer, not through post-retrieval filtering. Most production memory frameworks — LangChain, LlamaIndex, and their enterprise derivatives — support scoped retrieval through namespace configuration or collection-level access controls. This is not a new capability that requires significant engineering; it is a configuration discipline that most deployments have not enforced.
Audit your current memory namespace configuration. If all users and all task types retrieve from the same memory store without scope enforcement, you have a shared write surface open to every authorized user. Namespace separation is the first architectural control — it is available today in production frameworks and requires no new infrastructure. Do this before any other memory security work.
Second: Implement cryptographic provenance for long-term memory
Cryptographic integrity checks for persistent memory entries address two overlapping requirements. They close the modification-in-transit attack surface — ensuring that memory entries cannot be silently altered between write and retrieval. And they create the attribution record that forensic response requires when a memory-resident compromise is identified. Every memory entry should carry a verifiable record of its origin: who wrote it, in what session context, and when. This does not prevent a malicious user from writing a payload through legitimate interaction — it makes every write attributable, which enables scope assessment when a compromise is identified and creates accountability that deters insider threat scenarios.
The OWASP AI Agent Security Cheat Sheet explicitly recommends cryptographic integrity checks for long-term memory. This is the most direct translation of an established security principle — integrity verification for stored data — into the agent memory context.
Third: Enforce relational schema validation for GraphRAG deployments
For deployments using GraphRAG over structured knowledge bases, relational integrity verification is the control that addresses the attack surface text-level defenses cannot reach. The implementation requires defining the expected relational schema — which entity types can connect to which other entity types, through which relationship types — and validating graph nodes against that schema at retrieval time. Any entity relationship that violates the schema is flagged before the node is used in reasoning.
GraphRAG Schema Enforcement in Practice
Schema enforcement is most tractable in domains with well-defined ontologies — legal and compliance document stores, technical specification corpora, organizational role hierarchies. It is harder in domains where the knowledge graph is built from unstructured text and relationship types are inferred rather than specified. For the latter, a combination of relationship type constraints and statistical outlier detection on entity degree distribution provides partial coverage. Full relational integrity verification requires a defined schema — which is itself a deployment discipline worth enforcing for knowledge graph security independent of the attack surface it closes.
Fourth: Define explicit propagation boundaries for multi-agent architectures
For multi-agent deployments with shared memory, the default configuration — full sharing across all agents — should be treated as a security vulnerability, not an operational convenience. Explicit propagation boundaries define which memory types cross which agent boundaries, through what verification requirements, and with what scope constraints on the receiving side. The implementation involves three decisions: what memory is shared (semantic, episodic, operational — not all memory has equal sharing risk), how it is shared (with re-verification at each boundary crossing), and what scope constraints apply on the receiving agent’s side.
Torra and Bras-Amorós recommend treating the memory reuse chain as an untrusted channel — the same structural posture that zero-trust architectures apply to network traffic. Any memory crossing an agent boundary is treated as potentially compromised and subjected to the same verification requirements as incoming content from an external source. This is operationally more demanding than implicit full sharing, and it delivers the architectural guarantee that implicit sharing cannot: a bounded blast radius regardless of what a memory entry contains.
The fix is not better filtering. It is constraining what memory can reach, what it can influence, and what it can cross — structurally, at the architecture layer, independently of what the memory says.
— Luminity Digital synthesis from arXiv:2603.15125, arXiv:2604.02954, arXiv:2603.20357Memory Security and the Broader Structural Defense Argument
The three structural controls documented here belong to the same family of architectural enforcement that runs through the Luminity corpus from Series 2 forward. Series 2 established that deterministic architectural enforcement — controls that hold regardless of model inference — is more reliable than probabilistic behavioral guardrails. Series 3 established that indirect prompt injection is structurally difficult to defend against at the model layer. Series 5 established that the policy layer addresses application-layer enforcement with genuine rigor while leaving protocol-level gaps open.
Memory security adds a third dimension to that argument. The attack surface is not the session, and it is not the protocol. It is the accumulated context that the agent treats as established prior knowledge — the memory store that makes agents useful and that, without structural controls, makes them persistently vulnerable in ways that no session-level defense addresses.
Persistent memory is a write surface, not just a read surface. Every deployment that makes agents more useful through memory also expands the attack surface unless three structural controls are in place: memory isolation by scope, cryptographic provenance for long-term entries, and explicit propagation boundaries in multi-agent architectures. These controls do not ask the model to detect malicious content. They constrain what memory can reach and what it can influence — structurally, at the architecture layer, regardless of what the content says.
If your enterprise agentic deployment uses persistent memory — customer service agents, internal copilots, research synthesis agents, CRM-connected agents — the attack surface documented in this series applies to your architecture today. The three structural controls are implementable with current production frameworks. The gap is configuration discipline and architectural commitment, not new infrastructure.
Series 8 — The Supply Chain Beneath the Stack — examines implicit payload execution in agent skill ecosystems, the SC-Inject-Bench findings across 10,000+ malicious MCP tools, and the provenance verification architecture that closes the supply chain gap. Coming next.
