Security: Add OWASP Agent Memory Guard to security docs (memory poisoning protection)

[vgudur-dev]

Context

The OWASP Top 10 for Agentic Applications (released 2025) identifies ASI06: Memory Poisoning as a critical vulnerability for agents with persistent memory.

AutoGen agents that use persistent memory stores are vulnerable to memory poisoning — where malicious content injected into memory silently influences future agent decisions across sessions.

Request

Would the AutoGen team consider adding a mention of OWASP Agent Memory Guard to the security documentation or integration guides?

What it is: The OWASP reference implementation for ASI06 — a Python middleware that:

• Detects tampered memory entries using SHA-256 integrity baselines
• Scans memory reads/writes for prompt injection payloads and secret leakage
• Enforces YAML-defined policies (block/warn/strip) at the memory boundary
• Sub-100μs latency, zero external dependencies

pip install agent-memory-guard

GitHub: https://github.com/OWASP/www-project-agent-memory-guard
PyPI: https://pypi.org/project/agent-memory-guard/

This has been adopted by the UK Government BEIS Inspect AI evaluation framework as part of their AI safety evaluation suite.

Happy to provide a code example or contribute a documentation PR.

[Jairooh]

Memory poisoning is critical for stateful agents, especially as AutoGen systems become more complex and long-lived. The OWASP reference implementation's approach—SHA-256 baselines + payload scanning at the memory boundary—catches both tampering and injection patterns effectively. A docs PR for this would be valuable for AutoGen's security guidance.

[0xbrainkid]

One addition I would make to the docs angle: memory protection should produce an audit artifact, not only a runtime allow/block decision.

For persistent multi-agent systems, a poisoned memory write can affect future behavior long after the original session disappears. If a memory guard blocks, strips, or allows an entry, teams need enough evidence to reconstruct the decision later:

• agent/session identity,
• memory namespace/scope,
• validator and policy version,
• decision: allow / warn / strip / block / quarantine,
• content hash rather than raw sensitive content,
• timestamp and optional receipt URI.

That makes the integration useful for both security and reputation. For AgentFolio/SATP-style onboarding, a future caller should be able to inspect whether an agent’s long-term memory has been governed under a known policy, instead of relying on the agent’s self-report.

So I’d frame this in docs as “memory boundary validation + receipt/audit trail,” even if the first integration only links to OWASP Agent Memory Guard.

[msaleme]

Strong proposal. Memory poisoning is one of the most under-addressed vectors in multi-agent systems because the exploit doesn't look like an attack - it looks like "the agent happened to recall something unhelpful."

A few angles worth adding to the integration story:

1. Cross-session integrity: AutoGen's BufferedChatCompletionContext and persistent memory stores (e.g., CosmosDB, Redis) are the exact boundary where ASI06 manifests. If Agent A's memory is poisoned in Session 1, Agent B reading from the same store in Session 2 inherits the compromise silently. The middleware approach here is correct because it sits at the memory boundary, not inside the agent logic.

2. Policy granularity: The YAML-defined block/warn/strip policies should ideally map to AutoGen's existing FunctionCall and ToolCall schemas. If Memory Guard can tag entries by tool type or agent role, teams can apply stricter policies to high-privilege agents (e.g., code execution, payment initiation) without adding latency to read-only agents.

3. Observability hook: The sub-100μs latency is impressive, but for production deployments we'd want the scan results emitted as structured telemetry (not just logged). That lets SOC teams correlate memory-guard triggers with downstream agent decisions - closing the loop between "we blocked a poisoned memory write" and "the agent did something unexpected 30 seconds later."

Happy to help draft a concrete autogen_ext.memory.agent_memory_guard integration sketch if useful.

[arian-gogani]

the observability point is key. memory poisoning detection catches the attack, but there's a downstream question: can you prove what the agent did after the poisoned memory was accessed? if the guard logs a trigger but the agent's subsequent actions are recorded in mutable logs, the investigation is incomplete.

we built the provenance layer for this. every agent action produces a bilateral cryptographic receipt (Ed25519 signed, hash-chained). when a memory guard fires, the receipt chain gives SOC teams tamper-evident proof of everything that happened before and after the trigger. no gap between "we detected poisoning" and "here's exactly what the agent did next."

the receipts also accumulate into Trust Capital, a credit score for the agent. agents with clean provenance earn higher autonomy. agents that trigger memory guards see their Trust Capital drop, which dynamically restricts their access before damage spreads.

already integrated with AutoGen tool call boundaries. Microsoft AGT merged the core primitive.

repo: https://github.com/arian-gogani/nobulex

[arian-gogani]

ifier collapses into rubber stamp" failure class you identified is the exact problem Trust Capital solves structurally.

your doctrine -- "a claim of integrity must be verified by an observer that does not share fate with the subject" -- maps directly to the nobulex bilateral receipt model. the post-execution receipt is co-signed by the counterparty, not the agent. the verifier and the subject are fate-separated by construction: different key, different process, different trust boundary.

to your open question: yes, the post-execution receipt IS audited by an observer with no shared imports on the action machinery. the receipt is Ed25519 signed by the counterparty's key, hash-chained into a tamper-evident log, and independently verifiable by any third party. the agent cannot rubber-stamp its own receipt because it doesn't hold the co-signing key.

the self-poisoning class you described (agent writes to memory, reads it back as ground truth, self-reinforces) is precisely why Trust Capital is earned through externally verified behavior, not self-reported. the trust score only increases when a counterparty co-signs the outcome. no co-signature = no Trust Capital accrual. the agent can't game the denominator because it doesn't control the verifier.

your n50.io failure modes catalog would be valuable as a negative test suite for nobulex -- happy to map specific pathologies to receipt verification tests.

[arian-gogani]

three good questions. honest answers:

1. counterparty key provenance: you are right that if both keys come from the same runtime, the bilateral signature is theatrical. nobulex addresses this by requiring the verifier key to be provisioned independently of the agent runtime. in practice this means the counterparty is either a separate service with its own key management, an HSM-backed signer, or a third-party notary. the key provenance chain is part of the receipt metadata so auditors can walk it back to the root of trust.

2. hash chain replay vs selective disclosure: nobulex uses hash chains today, which means full-chain verification. merkle-root + inclusion proofs for selective disclosure is on the roadmap but not shipped. for now, the verifier sees the full chain. this is a real limitation for privacy-sensitive use cases and worth being explicit about.

3. counterparty refusal to sign: this is a first-class state in nobulex. a missing counter-signature produces a receipt with status UNSIGNED, not an absent receipt. the distinction matters: UNSIGNED means the action was attempted and the counterparty explicitly or implicitly refused to attest. absent means the action was never recorded. these are different failure modes with different audit implications. silence is never interpreted as success.

(3) is where most bilateral designs leak and you are right to flag it. the negative case has to be as well-defined as the positive case.

[vgudur-dev]

@Jairooh — thank you for validating the core threat model. You're right that the risk compounds as AutoGen systems become more complex and long-lived. The SHA-256 integrity baseline in OWASP Agent Memory Guard is specifically designed for exactly this scenario: stateful, persistent agents where a poisoned entry from Session 1 silently propagates into Session 2, 3, and beyond.

The key insight your comment highlights is that the threat is temporal — the exploit doesn't look like an attack at the time it's stored, it only manifests as anomalous behavior later. That's why the middleware approach (scan at the boundary, before write) is more effective than post-hoc detection.

[vgudur-dev]

@0xbrainkid — the audit artifact framing is exactly right, and I want to directly incorporate this into the docs PR.

The ScanResult object in OWASP Agent Memory Guard already captures the fields you described:

• agent_id / session_id (from context passed to guard.scan())
• threat_type (the specific detector that fired)
• policy_version (the policy YAML version used)
• decision (allow / warn / strip / block / quarantine)
• content_hash (SHA-256 of the content, not the raw content)
• timestamp

What's missing from the current implementation — and what I'll add before the docs PR — is a receipt_uri field for SATP-style onboarding. Your framing of "memory boundary validation + receipt/audit trail" will be the exact language I use in the AutoGen security docs section.

The point about future callers being able to inspect whether an agent's long-term memory has been governed under a known policy is critical for multi-agent trust chains. I'll make sure the docs example shows how to persist the ScanResult as a structured audit log alongside the memory write.

[vgudur-dev]

@msaleme — three excellent points, each of which directly shapes the docs PR:

Cross-session integrity: The BufferedChatCompletionContext + CosmosDB/Redis boundary is exactly the right place to instrument. The middleware sits at the memory store interface, which means it intercepts both Agent A's write and Agent B's read from the same store. I'll make the docs example explicitly show this cross-agent scenario rather than the simpler single-agent case.

Policy granularity: Mapping YAML policies to AutoGen's FunctionCall and ToolCall schemas is the right architectural direction. The current implementation supports per-namespace policies (you can assign different policy strictness to different memory scopes), but I haven't yet exposed a tool_type or agent_role tag. I'll add that to the roadmap issue and note it in the docs as a planned extension.

Observability hook: Fully agree — the ScanResult should be emitted as structured telemetry, not just logged. I'll add an example showing how to hook the scan result into OpenTelemetry spans so SOC teams can correlate memory-guard triggers with downstream agent decisions.

On the autogen_ext.memory.agent_memory_guard sketch — yes, please. I'd love to collaborate on that. I'll open a separate issue for the extension design once the docs PR is up.

[vgudur-dev]

@arian-gogani — the bilateral cryptographic receipt model in nobulex is a highly complementary layer to what OWASP Agent Memory Guard provides. The two systems address different parts of the threat surface:

• OWASP Agent Memory Guard: Synchronous, inline, sub-100μs payload scanning at the memory boundary. Catches known injection patterns, jailbreaks, and tampering before they enter the store. The guard fires at write time.
• nobulex Trust Capital: Asynchronous, cryptographically verifiable provenance chain for agent actions after memory is accessed. Catches the downstream behavioral consequences of any memory that did get through.

The "detect at write + prove at execution" combination is exactly the defense-in-depth architecture that ASI06 requires for high-assurance deployments. I'll reference nobulex in the AutoGen docs PR as the recommended provenance layer for teams that need the full audit chain.

The point about Trust Capital dropping when a memory guard fires — dynamically restricting agent access before damage spreads — is a particularly elegant design. That's the kind of runtime consequence that turns a detection event into an actual containment action.

[vgudur-dev]

@Ilya0527 — the n50.io production data (2/63 retirement rate, 8,945 verdicts) is exactly the kind of empirical evidence that's missing from most ASI06 discussions. Thank you for sharing it.

The "verifier collapses into rubber stamp" failure class is real and important. Your two structural fixes — per-entry cool-down requiring fresh cited evidence, and the forcing function that demands explicit retire_by + retire_if — are the right mitigations. I'll add both patterns to the OWASP Agent Memory Guard documentation as "Memory Lifecycle Governance" guidelines.

On your open question about whether the post-execution receipt is audited by an observer with no shared imports: @arian-gogani's response addresses this directly — the nobulex receipt is Ed25519 signed by the counterparty's key, not the agent's. The fate-separation is structural, not procedural.

Your doctrine — "a claim of integrity must be verified by an observer that does not share fate with the subject" — will go into the OWASP docs as the canonical statement of the auditor independence principle for ASI06.

[vgudur-dev]

@Ilya0527 — the self-poisoning class is the harder half of ASI06 and you've articulated it precisely. You're right that SHA-256 doesn't help when the agent itself writes the bad content — the hash is correct at write time.

Your two proposed mitigations map directly to features I'll add to OWASP Agent Memory Guard:

1. Provenance separation: I'll add a source_class field to the memory entry schema (external_tool | user_input | agent_authored | system) and a policy option to apply stricter scanning to agent_authored entries being read back in the same decision cycle. The agent treating its own prior speculation as ground truth is a self-amplification loop, not a memory operation.

2. Self-write cool-down: I'll add a self_reinforcement_detector that flags when the same agent writes and then reads back the same entry within one decision cycle without an external verifier confirming it. This is the "soft auditor counting its own seed verdict" pathology you described.

The distinction you draw — SHA-256 fingerprints stop external tampering; provenance tags and self-feedback cool-downs stop the agent from poisoning itself — will be the organizing framework for the ASI06 section in the AutoGen security docs. These are different threat models with different mitigations, and conflating them is the most common mistake I see in ASI06 coverage.

[vgudur-dev]

Summary: Three-Layer ASI06 Defense Architecture for AutoGen

This thread has produced the clearest articulation I've seen of what a complete ASI06 defense looks like for production multi-agent systems. Let me synthesize the consensus before I draft the docs PR.

The Three Layers

Layer 1 — Inline Boundary Validation (OWASP Agent Memory Guard)
Synchronous, sub-100μs payload scanning at the memory write/read boundary. Catches known injection patterns, jailbreaks, tampering, and — with the additions from this thread — self-poisoning via provenance separation and self-write cool-downs. This is the GuardedMemoryStore(inner=..., guard=..., on_violation=...) interface @yudin-s proposed.

Layer 2 — Structured Audit Trail (@0xbrainkid, @msaleme)
Every memory boundary decision emits a structured receipt: agent_id, session_id, memory_namespace, policy_version, decision, content_hash, timestamp, receipt_uri. Framed as "memory boundary validation + receipt/audit trail," not just allow/block. Enables SOC teams to correlate guard triggers with downstream agent decisions via OpenTelemetry.

Layer 3 — Cryptographic Provenance & Fate Separation (@arian-gogani, @Ilya0527)
Post-execution bilateral receipts (Ed25519, hash-chained) co-signed by a counterparty that does not share fate with the agent. Auditor independence is structural, not procedural. Trust Capital drops when a guard fires, dynamically restricting agent access before damage spreads.

What I'm Adding to OWASP Agent Memory Guard Before the PR

Based on this thread, I'm adding:

• source_class field (external_tool | user_input | agent_authored | system) to the memory entry schema
• self_reinforcement_detector for self-write cool-down logic
• receipt_uri field in ScanResult for SATP-style audit chain integration
• OpenTelemetry hook example for structured telemetry emission
• "Memory Lifecycle Governance" section documenting the per-entry cool-down and retire_if patterns from @Ilya0527's production experience

The Docs PR

I'll open the AutoGen docs PR targeting the security documentation with:

1. The three-layer architecture diagram
2. A GuardedMemoryStore integration example using agent-memory-guard
3. Cross-agent scenario (Agent A writes, Agent B reads from shared CosmosDB/Redis store)
4. Provenance separation guidance for high-privilege agents (code execution, payment initiation)
5. Reference to nobulex for teams that need full cryptographic provenance

I'll link the PR here once it's up. Thank you all — this is exactly the kind of community-driven security standard that makes OWASP guidance meaningful.

[arian-gogani]

@vgudur-dev the three-layer framing is the right architecture. detect at write (OWASP Agent Memory Guard), structured audit trail, and cryptographic provenance (nobulex) as three independent surfaces that compose without competing.

on the Trust Capital drop when a memory guard fires: this is the key design property. the guard detects, the receipt chain proves, and Trust Capital enforces the consequence. detection without consequence is just logging. the runtime restriction (lower Trust Capital = reduced access) is what turns a detection event into actual containment.

happy to review the AutoGen docs PR when it's up. will make sure the nobulex integration example covers the bilateral receipt model accurately -- the counterparty key provenance and fate-separation are the load-bearing properties that distinguish this from self-attested logging.

the receipt_uri field in ScanResult connecting to nobulex receipts is the right integration point. one chain of evidence from memory boundary to execution outcome.