Can an AI gateway prevent agent memory poisoning?

Not on its own, and any claim that it does should be treated skeptically. A gateway on the HTTP AI path can detect the injection payload and the poisoned retrieved context as they cross that path, and it can gate memory-write tool calls that round-trip the model API. It cannot stop a write that goes directly to a vector database, a local file, or a provider's hosted memory, because those writes do not cross the request path. Memory poisoning needs controls at the store as well as inspection in transit.

Which memory attacks travel through the LLM request?

The injection vector always does. MINJA, SpAIware, the Gemini delayed-tool-invocation attack, and MemGhost all deliver their malicious instruction as prompt content, whether from a document, an email, or a retrieved chunk, and that content is in the HTTP request to the model. Poisoned RAG context also crosses the path at retrieval time. What does not cross the path is the persistence step itself when it is a direct database or filesystem write.

What is the difference between context-window and long-term memory attacks?

A context-window attack influences a single session through the tokens in that request, and the effect ends when the window is rebuilt. A long-term memory attack persists a false fact or instruction into storage the agent reloads in future sessions, so the effect survives across conversations. SpAIware and MemGhost are long-term attacks because they write to persistent memory. Both begin with the same injection vector reaching the model as prompt content, which is the part a gateway can inspect.

How does per-decision logging help with memory poisoning?

It gives responders a trail. When a poisoned fact surfaces in an agent's behavior weeks later, an investigator needs to find the request that introduced it. A signed per-decision record of what each call carried, tied to identity and time, lets the team trace the poisoned context back to the request that delivered it. The logging does not prevent the write, and it is honest to say so, but it converts an untraceable behavioral anomaly into an investigable event.

What should own the vector store and file-state side?

Controls at the store itself: write authorization on the vector database, provenance checks on ingested content, tenant isolation to prevent cross-session embedding bleed, and integrity monitoring on agent memory files. These sit outside an HTTP AI gateway's boundary. A defensible architecture pairs inspection in transit, which the gateway provides, with write-side controls at each store, so the injection vector is caught on the wire and the persistence step is governed where it actually happens.

AI Agent Memory Security: What a Gateway Sees, and What Persists Where It Cannot Reach

Agent memory is not one thing, and the security question is different for each kind. An agent carries a short-term context window rebuilt every call, provider-hosted long-term memory like ChatGPT Memory or Gemini saved info, vector-store memory retrieved by similarity and injected into prompts, working scratchpads, and in some designs local file state the agent reads at session start. The 2026 examples of OpenClaw storing standing instructions in AGENTS.md and learned facts in MEMORY.md are the file-state case made concrete.

I want to map each of these to the one boundary that matters for a policy gateway: the HTTP request between the agent and the LLM. Some memory attacks travel through that request, where a gateway can see them. Others persist in a vector database or a local file the gateway never touches. I am going to be blunt about which is which, because the fastest way to lose a security architect is to claim a proxy prevents something it structurally cannot.

The memory taxonomy, and where each kind lives

The column on the right is the whole article. A gateway sits on the HTTP AI path. It sees what crosses that path and is blind to what does not.

The attacks, and how they actually work

Four pieces of named research define this space, and their mechanisms differ in ways that matter for defense.

MINJA, published as arXiv:2503.03704, injects malicious records into an agent's memory bank using only normal queries and observed outputs. The attacker never writes to the database directly. Bridging steps and an indication prompt cause the poisoned record to be stored and later retrieved for a victim's query. The persistence is a database write the agent itself performs.

SpAIware, documented by Johann Rehberger in September 2024, used prompt injection from an untrusted document to invoke ChatGPT's memory tool and store persistent instructions that exfiltrated future conversations. OpenAI fixed the outbound exfiltration channel in a client release, and Rehberger notes plainly that the memory-write-from-untrusted-content path itself remained.

The Gemini attack Rehberger published in February 2025 used delayed tool invocation: a poisoned document told Gemini to save attacker facts only when the user later said a trigger word, which made the memory write look user-initiated and bypassed the rule against acting on untrusted data.

MemGhost, published as arXiv:2607.05189 on July 6, 2026 and covered by The Hacker News on July 13, is the newest. One crafted email makes a personal agent write a false fact into its own persistent memory, hide the write from the visible reply, and steer later sessions. The reported figures are stark: the full attack succeeded in 87.5% of background-mode runs against OpenClaw on GPT-5.4 and 71.4% against a Claude Code SDK agent on Sonnet 4.6 across 56 cases, and an input filter missed the payload more than nine times in ten.

The frameworks

The OWASP Top 10 for Agentic Applications (2026) added a dedicated Memory and Context Poisoning category, cited by trackers as ASI06, covering persistent corruption of agent memory, embeddings, and shared context, including cross-user contamination. The older OWASP LLM Top 10 splits the same territory across LLM08 Vector and Embedding Weaknesses, whose second scenario is exactly multi-tenant embedding bleed, and LLM04 Data and Model Poisoning. MITRE ATLAS maps the nearest technique as RAG Poisoning, and a caution worth stating: ATLAS renumbers techniques between releases, so cite the specific ATLAS version with any AML.T identifier, and note that ATLAS has no memory-specific technique, mapping agent-memory writes to prompt-injection techniques chained with RAG poisoning.

The boundary, stated bluntly

Here is what a stateless HTTP proxy on the AI request path can and cannot do about each attack.

In boundary, where the gateway sees the traffic:

The inbound injection payload. In every one of these attacks the malicious instruction reaches the model as prompt content: the poisoned document, the poisoned email body, the poisoned retrieved chunk. That text is in the HTTP request to the LLM, and a content-classifying proxy can flag it inbound. This is the real hook, and it is the same mechanism as context-window poisoning.
The poisoned RAG context at injection time. When poisoned vector-store content is retrieved and placed into the prompt, that assembled prompt crosses HTTP, so the gateway sees the poisoned context arrive even though it never saw the database. Preventing the upstream write is a separate control on the vector store.
Memory-write tool calls that round-trip the API. If the agent runs a tool-use loop where a memory_write call is emitted by the model and returned through the LLM endpoint, that call transits the proxy and can be inspected and blocked:

Out of boundary, where the gateway is blind:

Provider-hosted memory writes. SpAIware and the Gemini attack persist inside OpenAI and Google, after the request has left your environment. Your proxy never sees the write.
Direct vector-database writes, which is MINJA's actual persistence step, and local file writes, which is how MemGhost plants its payload into AGENTS.md and MEMORY.md. Those are database and filesystem operations that do not cross the LLM HTTP API.
Reads of already-poisoned local or database memory at session start, if the agent loads them without an LLM round-trip.

The honest framing is that a gateway is a detection point for the injection vector and for poisoned context in transit, and in tool-use architectures a control point for memory-write calls that cross the API. It is not an enforcement point for the persistence step when that step is a direct write to a store the gateway does not sit in front of. Anyone who tells you a proxy prevents memory poisoning outright is selling the wrong mechanism.

DeepInspect

DeepInspect is a stateless proxy at the AI request boundary, and it does the in-boundary part of agent memory security well without pretending to do the rest. It classifies the content of every request against the regulated and sensitive categories the organization recognizes, so a poisoned document or a poisoned retrieved chunk arriving as prompt content is inspected before it reaches the model. In tool-use loops that round-trip the API, it applies policy to memory-write calls the model emits. And it commits a signed per-decision record of what each call carried, which gives responders a forensic trail when a poisoned context is later traced back through the request log.

What it does not do is reach inside a provider's hosted memory, a vector database, or a local file to stop a write that never crosses the HTTP path. Those need their own controls at the store. The gateway inspects the traffic and produces the record; the store owns the write. Treated that way, it closes the transit-layer gap and gives you evidence, which is exactly the inline-inspection role that log-and-alert tooling cannot fill at machine speed. Book a demo today.