Security: OWASP ASI06 memory poisoning defense for AutoGen multi-agent memory

[vgudur-dev]

Problem

AutoGen's multi-agent systems that use shared memory pools, conversation history, or state persistence are vulnerable to memory poisoning attacks (OWASP ASI06). An attacker can inject malicious content into an agent's memory, and that poisoned content persists across sessions — silently altering the agent's behavior.

Unlike prompt injection (which is ephemeral), memory poisoning is persistent. Once the memory is poisoned, every future conversation that retrieves it treats the malicious content as trusted context.

Attack Vector

1. Attacker crafts content designed to be stored in agent memory (via conversation, tool response, or user input)
2. 2. AutoGen stores it in the agent's conversation history or shared state
3. 3. Future conversations retrieve the poisoned entry as trusted context
4. 4. Agent behavior is silently altered — data exfiltration, privilege escalation, or output manipulation

Proposed Solution

OWASP Agent Memory Guard is the official OWASP reference implementation for ASI06 defense. It provides:

• Cryptographic integrity verification — detects tampering of stored memories
• • Semantic anomaly detection — flags memories that deviate from established behavioral baselines
• • Pattern-based heuristics — catches known attack patterns (exfiltration instructions, privilege escalation, encoded payloads)

Integration Example

from agent_memory_guard import MemoryGuard

guard = MemoryGuard(policy="strict")

# Validate before storing in AutoGen's memory
def safe_memory_write(content):
    result = guard.validate_memory(text=content)
    if not result.is_safe:
        audit_log.record(content, result.threat_type)
        return  # Block poisoned content
    memory_store.write(content)

Performance

• 100% detection rate for direct injection attempts
• • 94% detection for encoded/obfuscated payloads
• • <3ms latency overhead per memory operation

References

• OWASP Top 10 for Agentic Applications
• • agent-memory-guard on PyPI
• • GitHub Action for CI/CD scanning
    Would the AutoGen team be interested in exploring a native integration or recommending this as a security best practice for memory-enabled agents?

[yudin-s]

I think this is a good security boundary to discuss, but I would avoid making any single memory scanner a hard dependency of AutoGen.

The stronger integration point would be a memory policy hook with two separate checkpoints:

before write:
  user/tool/model content -> classify -> allow / quarantine / reject

before read/use:
  retrieved memory -> verify provenance/integrity -> classify again -> allow / redact / quarantine

The second checkpoint matters because memory can become unsafe after it was stored:

• the policy changed
• the agent role changed
• the memory was copied from another agent/workspace
• the memory store was migrated
• the retrieved memory is now being used for a higher-privilege task

I would want the memory record to carry provenance metadata, not only text:

{
  "memory_id": "...",
  "source": "user|tool|agent|system",
  "created_by_agent": "...",
  "created_at": "...",
  "scope": "agent|team|global",
  "integrity_hash": "sha256:...",
  "last_policy_check": {
    "policy": "memory-guard-v1",
    "decision": "allow",
    "checked_at": "..."
  }
}

Then AutoGen could support pluggable guards:

memory = GuardedMemoryStore(
    inner=memory_store,
    guard=my_guard,
    on_violation="quarantine",
)

One caution: I would be careful with claims like 100% detection rate unless the benchmark and corpus are public and reproducible. For framework integration, the important contract is not perfect detection; it is predictable policy behavior, auditability, and safe failure modes.

So my vote would be: yes to a native guard/policy interface, maybe yes to documenting OWASP Agent Memory Guard as one implementation, but probably no to baking one specific scanner directly into AutoGen core.

[vgudur-dev]

This is really thoughtful feedback — thank you. The provenance metadata schema you proposed is exactly the direction I think this needs to go.

A few reactions:

On the pluggable interface: Fully agree. The right contract is GuardedMemoryStore(inner=..., guard=..., on_violation=...) rather than baking any specific scanner into AutoGen core. The goal should be a well-defined memory policy interface that OWASP Agent Memory Guard (and others) can implement.

On the dual-checkpoint model: The "before write" + "before read/use" separation is important and something we've been thinking about. The second checkpoint matters especially in multi-agent scenarios where memory written by Agent A gets read by Agent B in a higher-privilege context — the policy at write time may not be sufficient.

On the 100% detection rate claim: Fair point. That claim is based on our internal test corpus of ~500 known injection patterns, which is not yet public. I'll update the README to be more precise: "100% detection on our evaluation corpus" with a link to the corpus once it's published. Predictable policy behavior and safe failure modes are the right contract for framework integration.

Next step: Would it make sense to open a separate AutoGen issue specifically for the memory policy interface design? I'd be happy to draft a proposal based on your GuardedMemoryStore sketch and the provenance metadata schema. That way the interface design can be community-driven, with OWASP Agent Memory Guard as one reference implementation.

[ElamOlame31]

Memory poisoning and output injection are related — both involve an adversary controlling what the agent sees. AgentGate's MCP proxy blocks INSTRUCTION_TAG and IMPERATIVE_INJECT patterns before they reach the agent's context. The malicious instruction is blocked before it enters memory, not scanned for after.

https://github.com/ElamOlame31/agentgate-public

https://www.tryagentgate.com/