Agent Memory Guard: Middleware to prevent memory poisoning in multi-agent systems #7792

Update: The official AutoGen adapter is now live! 🎉

As promised, I built the AutoGen integration this week. It's available as PR #40 on the AMG repo and will ship in the next release:

What's included:

• SecureGroupChatManager — wraps AutoGen's GroupChatManager with memory scanning at the routing layer (exactly the hook point AIwalker (@jingchang0623-crypto) suggested)
• SecureConversableAgent — drop-in replacement that screens all incoming messages before they enter memory
• Trust-level configuration for different message sources (user vs agent vs tool)
• on_threat modes: "block", "quarantine", "log_only"

Quick usage:

from agent_memory_guard.integrations.autogen import SecureGroupChatManager

manager = SecureGroupChatManager(
    groupchat=group_chat,
    memory_guard=guard,
    on_threat="quarantine"
)

AIwalker (@jingchang0623-crypto) — I'd love to take you up on the testing offer. If you have specific attack scenarios from your production setup, please open an issue on https://github.com/OWASP/www-project-agent-memory-guard or share them here. I'll make sure they're covered in the test suite.

Install: pip install agent-memory-guard (adapter ships in v0.4.0, currently on TestPyPI for early testing)

The 5-layer scanning approach is solid for the write-path, but the harder problem in production is the read-path — even if you screen every write perfectly, an attacker who manages to get one payload through (or who poisons the store before the guard was installed) can persist indefinitely if memories never expire.

A complementary defense: importance-weighted memory decay. Every stored memory carries an importance score (0.0–1.0) that degrades based on access recency. Legitimate memories get their importance reinforced each time an agent references them — the agent effectively "votes" for useful context by using it. Poisoned memories that enter the store but are never naturally referenced decay below the retrieval threshold within hours.

This changes the attacker's calculus: instead of needing one successful injection to persist forever, they need to continuously reinject to keep the poisoned memory above the recall threshold, which is much easier to detect with your scanning layers.

For the trust-label dimension, we attach provenance metadata (which agent wrote it, from what session, with what confidence score) to every memory. The T-I-F layer scores each fact with truth/indeterminacy/falsity values so downstream consumers can weight recalled context by reliability: https://github.com/Dakera-AI/dakera-deploy/blob/main/examples/tif-provenance/validate_tif_provenance.py

Solid project — the 5-layer scan approach and the new AutoGen adapter with trust-level configuration per message source addresses the write-path well.

On the read-path and provenance concerns raised above: one complementary pattern is making provenance structural rather than metadata-optional. If every stored output is an evidence trace (which agent, which tool call, raw result, interpretation, confidence, source weight) attached to a content-addressed node in a shared tree, then:

• Provenance is not a tag you add — it is the data model. Every conclusion traces back through node lineage to a specific tool call by a specific agent at a specific phase.
• Source weights as defense-in-depth. Structured query results carry higher weight than LLM interpretations, which carry higher weight than agent opinions. A poisoned payload injected as an agent opinion gets naturally discounted during the estimation phase — even if it passes the write-path guard.
• No persistent agent state to poison between sessions. Agents are stateless between turns — state lives in the versioned tree. The orient pass between phases produces clean snapshots, so a contaminated write is isolated to its phase and traceable to its source.

The approach does not replace active scanning (the guard handles the immediate threat), but it gives you the audit trail to answer: "if something did get through, who wrote it, from what tool, in which phase?" without needing a separate logging layer.

We have been working on this pattern: https://github.com/MertEnesYurtseven/structura

Curious how the AutoGen adapter handles the cross-agent contamination path that AIwalker (@jingchang0623-crypto) raised — especially when two agents concurrently write conflicting outputs to shared state.

I see the write guard and the retrieval trust layer as complementary. I maintain RE-call, which does not claim to detect poisoning during ingestion. Its role begins when memory is retrieved: each hit carries provenance, validity, confidence, and a trust verdict, while unsupported or superseded results can be refused.
A useful test might combine both layers: first measure whether a poisoned item enters memory, then measure whether the read path exposes it as untrusted rather than presenting it as ordinary context: https://github.com/GiulioDER/RE-call