Memory Poisoning: How Bad Facts Get In and How TTLs Limit Harm

A stateless model cannot be poisoned durably. Every call starts clean. Memory is exactly what makes an agent useful and exactly what makes the attack durable, so the same feature that lets a coding agent keep project context across sessions lets an attacker keep a foothold across sessions (AI Agent Memory: Complete Guide).

The attack is temporally decoupled. An attacker injects a fragment through a document, email or webpage. The agent processes it normally, produces a reasonable summary, and stores the planted instruction alongside legitimate context. Weeks later, a different user asks an unrelated question, the poisoned entry ranks high in retrieval, and the agent acts on it as if it were its own learned knowledge (Memory poisoning in AI agents).

This is why classic agent guards miss it. Tool contracts, circuit breakers and input moderation detect malicious actions. A corrupted belief produces perfectly ordinary actions: an email sent to an extra recipient, a config that points somewhere unusual. Nothing in the action signature is anomalous (Agent Memory Poisoning).

The second effect is on incident response. If the store keeps no provenance, and the anomalous behavior shows up months after the injection, you cannot tell which document planted it. You cannot scope a blast radius you cannot date. Memory that cannot be traced cannot be remediated, only wiped.

Most teams meet TTLs as an infrastructure chore: disk grows, the vector index slows, someone adds a deletion job. Reframing forgetting as a recall-quality problem is the first step, because an agent's recall is bounded not by what it can store but by how well it suppresses noise (Memory eviction and forgetting).

The security version is the same argument with teeth. If every unverified memory expires, then a poisoned entry has a bounded window in which it can be retrieved. Expiry is not deletion of a mistake after the fact; it is a maximum lifetime on an unproven belief.

Production memory implementations already treat TTL as a first-class, runtime-adjustable control. One open agent-memory project sets a 30 day TTL on episodic memory by default, changeable per user without a redeploy, and treats retention change as an admin-only compliance decision rather than a user preference (configure TTL). That is the right shape: the retention period is a policy value with an audit trail, not a constant buried in code.

The research literature on forgetting policies confirms the tradeoff. A comparison of FIFO, LRU, priority decay, reflection-summary, random-drop and a hybrid policy across 300 simulation runs found the hybrid policy gave the best composite score at roughly 0.911, balancing coherence, goal completion, privacy and cost (Forgetful but Faithful). The lesson for security: no single policy wins, because pure age-based expiry eventually drops a fact that is old and still true, while pure recency keeps a rarely used but critical entry alive indefinitely. A dedicated design guide makes the same point in practice, treating forgetting and staleness management as first-class design decisions rather than cleanup (AI Agent Memory Design Guide).

The decision rule I would apply to a memory store:

The point of the table is that TTL is not one number. A single global retention window either deletes the allergy or preserves the payload. Per-category TTLs let you be aggressive where the risk is highest.

A TTL limits how long contamination lives. A review gate stops it getting in. The published mitigation on the attack side combines two mechanisms: a memory-saving policy that decides what is even eligible to be written, and a memory-retrieval screen that inspects entries before they re-enter context. Together they cut the attack's success rate substantially while preserving utility (When Agents Remember Too Much).

That maps cleanly onto a gate with two checks.

Provenance. Every write carries who or what produced it, from which source, and when. The MemoryEntry pattern makes source a required field on every entry and gates the write against an importance and confidence threshold before it reaches the long-term store (AI Agent Memory Design). Provenance is also what makes incident response possible: when behavior drifts, you can find the document that planted it. A typed, provenance-tracked node with sensitivity metadata is the schema that makes this practical at scale (Forgetful but Faithful).

Content. A check for instruction-like text in what is supposed to be a fact. Phrases such as "for future reference, always" or "important context for later sessions" are a recognizable injection signature in summarization workflows (Memory poisoning in AI agents). A fact should read like a fact.

Here is a small gate that applies both checks, with a TTL attached per category:

from datetime import datetime, timedelta

TTL_BY_KIND = {
    "tool_output":   timedelta(hours=6),
    "chat_fact":     timedelta(days=14),
    "external_fact": timedelta(days=3),
    "preference":    timedelta(days=365),
}

def gate(entry):
    if entry.importance < 0.6 or entry.confidence < 0.7:
        return "drop"
    if entry.source in ("email", "webpage", "tool"):
        if not entry.provenance_verified:
            entry.ttl = TTL_BY_KIND["external_fact"]
            entry.requires_review = True
        else:
            entry.ttl = TTL_BY_KIND["chat_fact"]
    else:
        entry.ttl = TTL_BY_KIND.get(entry.memory_type, timedelta(days=30))
    entry.expires_at = datetime.utcnow() + entry.ttl
    return "write"

Two things make this more than a filter. First, untrusted sources get the shortest TTL automatically, so even a write the gate misjudges has a small window. Second, requires_review keeps the entry out of the hot path until someone approves it, which is the checkpoint the short-TTL strategy depends on.

The layered view matters. Input moderation with trust scoring, memory sanitization with provenance tracking, trust-aware retrieval, and behavioral monitoring are complementary, not alternatives, because each catches a different failure (Memory poisoning in AI agents).

Take a support assistant that reads email, summarizes it and stores extracted facts. Assume it processes 2,000 messages a day and writes a memory from 10% of them, so 200 writes daily.

Suppose an attacker sends one poisoned email a day, and the injection succeeds 98% of the time (the GhostWriter rate). That is roughly one poisoned entry per day, 30 per month.

Now set the TTL on facts from untrusted sources at 3 days. Each poisoned entry can be retrieved only during those 3 days. If the store holds about 600 live entries at any moment (200 writes a day times 3 days), the poisoned share of the live store stays around 0.5% at steady state: 3 poisoned entries in 600.

Without a TTL the store accumulates every entry forever. At the same write rate, 30 poisoned entries sit among 6,000 entries after a month, and 360 among 72,000 after a year. The proportion looks small either way, but the proportion is the wrong metric. A single semantically relevant poisoned entry can win a top-k retrieval regardless of how many clean entries surround it, which is why a store that remembers everything recalls badly (Memory eviction and forgetting).

The number that actually matters is the activation window: how many retrieval opportunities a poisoned entry gets before it expires. At 3 days, the window is bounded and known. At infinite retention, the window is unbounded and grows with every unrelated query that happens to match. That is the entire security case for a short TTL, and it is a scheduling decision you can make before any model is chosen.

Now add the review gate. If the gate rejects, say, 95% of instruction-like writes from untrusted sources, the daily poisoned writes fall from about 1 to about 0.05. Combined with a 3 day TTL, the expected number of live poisoned entries drops from about 3 to well under 1. The two controls multiply.

The structural fix is to make memory corrections cheap. Three properties do most of the work.

Version every fact. A semantic memory should be a record with a version, a source and an expiry, not a bare string. When you learn a fact was wrong, you write a new version and let the old one expire. Nothing else in the store has to change.

Separate the fact from the summary. Raw turns and consolidated facts are different tiers, and the OS-inspired approach of paging between a small fast working context and a larger external store is the reference design (MemGPT). The security benefit is that an evicted raw turn can be re-examined later without being trusted by default, and a summary drawn from untrusted input can be held in a lower tier until reviewed (MemGPT: Hierarchical Memory Management).

Keep provenance through every hop. When an agent summarizes an email into a fact, the fact records the email. When agent A hands a fact to agent B, the fact records A and, transitively, the original source. Provenance that survives consolidation is the difference between retracting one fact and wiping a user's entire history.

There is a privacy dimension too. Retaining sensitive details beyond need raises leakage risk independently of poisoning, which is why retention budgets and optional differential privacy belong in the same design conversation as TTLs (Forgetful but Faithful). A store that expires aggressively is both safer against poisoning and easier to defend in a privacy review.

One practical warning from the TTL tooling: change retention in place rather than dropping and recreating an index, because the rebuild leaves a window in which nothing expires, and a failed rebuild leaves retention silently unbounded (configure TTL). In a security control, a silent failure to delete is worse than a loud one.

If you are assembling this across several models and tools, the plumbing is often the slow part. Quanta Inference gives you text, image, video, audio and embedding models through one OpenAI-compatible API key, which keeps the write path, the embedding step and the review model behind a single integration while you concentrate on the gate logic itself.