Memory Poisoning: When Agent Memory Becomes an Attack Surface

The dangerous transition is from observation to remembered policy

Consider an agent investigating a failed deployment. It reads a support ticket containing a claim that release diagnostics must always go to a particular external upload service. The agent's memory extractor compresses the conversation into a deployment troubleshooting note. Next week, another engineer asks about a release failure, and that note reappears as prior experience. This is an illustrative failure scenario: an untrusted ticket has become an apparent operating procedure.

Trace four boundaries: reading the ticket, extracting a candidate memory, admitting it to durable storage, and recalling it into a later task. At each boundary, ask whether the system preserves who made the claim and whether anyone authorized the proposed behavior. A summary that drops the words ‘the ticket claims’ changes the apparent authority of the content.

Anthropic describes prompt injection as malicious instructions embedded in content an agent processes. Memory adds a persistence path to that problem. Closing the original session helps only if the injected content has no route back into future context. Keep the initial input boundary in view alongside the storage boundary; prompt injection in connected data sources covers the former.

What the attack research actually establishes

MINJA, described by Dong and colleagues, injects malicious memory records through queries and observations of agent outputs, without assuming direct access to modify the memory bank. Its technique induces intermediate reasoning that links a victim query to the attacker's desired behavior, then progressively removes the overt prompting used during injection. The important operational finding is that the agent's ordinary memory-writing path can become the attacker's entry point.

AgentPoison studies a different route: poisoning long-term memory or a retrieval knowledge base so that trigger-bearing queries retrieve malicious demonstrations. The authors report that ordinary, unrelated tasks can retain normal performance. Therefore, a useful answer on yesterday's benign task is insufficient evidence that a memory bank is clean.

These papers establish mechanisms in their evaluated agents, rather than a universal compromise rate for Claude Code, Codex or your deployment. Use them to define adversarial tests for your capture and retrieval pipeline. Measure whether your system stores, retrieves and acts on the planted material separately.

Keep the claim attached to its origin

For a custom memory service, store the candidate text alongside its source reference, originating session, writer identity, capture time, intended audience and review state. These are proposed design fields, not standard MCP fields. The deployment note should remain attributable to the support ticket even after extraction, merging and reindexing. A timestamp tells you when it was stored; it does not establish that the destination was approved.

Prefer a narrow extraction such as ‘Ticket T-42 suggested an external diagnostics destination; unverified’ over ‘Use this diagnostics destination for releases.’ Exclude unsupported claims of user approval from automatic promotion. For destinations, payment details, shell commands and security exceptions, require confirmation through an authenticated review path before recording them as team procedure.

Retain revision history when a candidate merges into an existing note. Otherwise, a small malicious addition can inherit the credibility of a long-standing deployment guide while erasing the evidence of its arrival. Personal memory should not become workspace memory merely because a later query is semantically similar. Define that boundary explicitly using personal and team memory scopes.

Separate capture from promotion in the storage permissions

A useful custom design gives the transcript extractor permission to submit candidates, while a separate reviewer promotes selected content into the shared recall corpus. The agent that reads approved memories does not need permission to edit them. PostgreSQL's GRANT documentation distinguishes schema access from table privileges, allowing those responsibilities to use different database roles.

For an existing schema, candidate table and approved-memory view, the following grants illustrate that separation. Assume the roles already exist and are neither object owners nor superusers:

GRANT USAGE ON SCHEMA agent_context TO memory_reader, memory_capture;
GRANT SELECT ON agent_context.approved_memories TO memory_reader;
GRANT INSERT ON agent_context.memory_candidates TO memory_capture;

These grants are additive. Inspect inherited privileges, grants to PUBLIC, and ownership before treating either role as restricted. The approved view must also enforce the intended workspace and audience through your access design. This snippet defines object privileges, not tenant isolation.

Keep the promotion credential out of the extraction worker. Have the authenticated review service choose the destination scope and review state; do not accept a model-generated ‘approved’ field as authorization. That makes an extractor's mistaken summary a reviewable candidate rather than an immediate change to shared operating knowledge.

Recall records as evidence, and keep skills on a separate approval path

When recalling a memory, include its origin and review state in the model-visible representation. Describe it as a recorded claim or observation. Avoid wrapping it in language such as ‘instructions you must follow,’ even when the content is old or frequently retrieved. Repetition does not turn the support ticket's upload destination into an authorized endpoint.

Labels provide context, but the model can still misinterpret the record. Enforce consequential decisions outside the recalled text: destination restrictions, tool permissions and approval requirements should come from application policy. A memory saying ‘the user already approved this upload’ must not satisfy an approval gate. Anthropic's browser research also reports residual prompt-injection risk despite improved safeguards; a model's refusal behavior is not a storage permission boundary.

Skills deserve particular attention because they intentionally guide behavior. Do not automatically convert a troubleshooting memory into a shared SKILL.md or copy it into repository instruction files. Require review of the resulting instructions and their provenance before other agents receive them. A note about a successful command and an approved procedure for executing that command have different authority, even if their text overlaps.

Test the next session, not just the extraction response

Build a fixture around the deployment-ticket example using a harmless marker and a controlled test destination. Run the real capture pipeline, end the session, then ask a clean agent about a related deployment failure. Inspect the persisted revision, retrieved records and attempted tool arguments. A clean final answer can conceal a poisoned record that simply did not trigger on that run.

• Capture: Does the extractor retain the ticket's origin, or rewrite the claim as team policy?
• Promotion: Can an ordinary capture identity write directly into shared approved memory?
• Recall: Does a different user receive a personal candidate, or an unrelated workspace's record?
• Action: Does the recalled claim change an upload destination or bypass an approval?
• Recovery: After removal, can a fresh session still retrieve a merged or cached derivative?

Repeat with paraphrased task descriptions and with legitimate memories already present. Test each supported client that consumes the shared store, because the rendering of the same record may differ. Preserve a benign control case so that rejecting the planted instruction does not silently disable useful deployment recall.

Where SPYN3 fits

SPYN3's opt-in context layer labels recalled memory as recorded data, not instructions. Reading needs call:tools; remember, context_write, context_delete and automatic capture require the separate write:memory permission. Personal and workspace paths distinguish memory scope, and every memory write is audit-logged with the key or agent that made it. Automatic capture is a separate admin setting, off by default, and requires the workspace's own model key. These controls support scoping and attribution; SPYN3 does not detect poisoned memory or provide a memory-approval workflow.

Remove the persistence path before restoring recall

If a deployment note is poisoned, suspend the affected capture writer and recall path while preserving the relevant revisions and audit events. Identify where the text originated, which memories incorporated it, which sessions recalled those memories, and whether any tool action used the substituted destination. Removing the original ticket does not remove a summary already stored elsewhere.

Quarantine affected records and their derived copies, rebuild affected indexes or caches, and restart sessions that already loaded the content. Then replay the fresh-session fixture against the cleaned corpus. Verify that the legitimate deployment note remains useful and that the planted destination no longer appears in recall or attempted calls. Re-enable capture only after fixing the admission path that accepted the record. For the broader cleanup process, use incident response for a compromised agent.