Agent Memory Guard vs Hindsight Memory Defense

Agent Memory Guard vs Hindsight Memory Defense

OWASP Agent Memory Guard is the standards-aligned reference. Hindsight Memory Defense is the production-deployed write-path implementation in Hindsight. They're complementary, not substitutes — and the comparison most buyers want isn't "which one wins," it's "which one fits my deployment, or do I need both."

OWASP Agent Memory Guard is the OWASP reference implementation for ASI06 — drop-in middleware that screens memory reads and writes via YAML policy with SHA-256 baselines and snapshot rollback. Hindsight Memory Defense is Hindsight's native write-path screening with deeper credential detection and SIEM-ready audit. They're complementary, not competitive.

That's the short answer. The rest of this article walks through what each is, where each is stronger, the deployment patterns for using them alone or together, the YAML and JSON config in concrete form, and the procurement decision framework for security buyers shopping ASI06 coverage.

If you haven't yet read the structural overview, the AI memory poisoning explainer covers what ASI06 is, the named attack families, and why defense at the memory layer matters in 2026. For the standards-aligned definition of ASI06 itself, see OWASP ASI06: Memory and Context Poisoning explained.

Why This Comparison Matters Now

OWASP Agent Memory Guard released in mid-2026 as the OWASP-sanctioned reference implementation for ASI06 (Memory and Context Poisoning). Within days of release, framework feature-request issues appeared on every major memory and agent platform:

The pattern is the strongest commercial signal in the agent-memory security space right now. Developers are filing issues across every memory framework asking for Agent Memory Guard support. Security buyers are starting to ask vendors "do you integrate with Agent Memory Guard, or implement the same ASI06 control set natively?" The procurement standard is forming in real time.

For teams running Hindsight — or evaluating it — the relevant question is how the Memory Defense feature relates to the OWASP reference implementation. The honest answer is what follows.

What Is OWASP Agent Memory Guard?

OWASP Agent Memory Guard is an open-source runtime defense layer that sits between an agent and its memory store, screening every read and write through a pipeline of detectors driven by a YAML policy. It's the OWASP reference implementation for ASI06 — the control set the standard prescribes, in concrete code form.

The architecture in summary:

  • Drop-in middleware: runs alongside any memory framework (Mem0, Letta, CrewAI, agno, Vercel AI SDK, FlowiseAI, custom builds, Hindsight) without requiring a memory-layer swap
  • Bidirectional screening: scans both memory reads (retrieval-time) and memory writes (retain-time)
  • YAML-driven policy: declarative configuration mapping each detector to one of four dispositions
  • Four dispositions: allow, redact, quarantine, block
  • Built-in detectors: prompt injection markers, secret and PII leakage, protected-key modifications, size anomalies
  • SHA-256 cryptographic baselines: out-of-band tamper detection on immutable memory keys
  • Forensic snapshots with rollback: when poisoning is detected, restore to a known-good memory state

The OWASP project lives at owasp.org/www-project-agent-memory-guard with source on the OWASP GitHub organization. Help Net Security covered the release on June 1, 2026, describing the project as "a runtime defense layer that sits between an agent and its memory store, screening every read and write." Project benchmarks cited there include a 92.5% detection rate at 100% precision with 59-microsecond median latency on AgentThreatBench. Kiteworks published a technical breakdown of Agent Memory Guard walking through the runtime defense layers and ABAC enforcement model for credential theft and prompt-injection containment — the most detailed external explainer of the project so far.

The core value of Agent Memory Guard is that it's standards-aligned and framework-agnostic. Security buyers comparing memory vendors increasingly use Agent Memory Guard as the reference: "does the vendor's defense story cover what Agent Memory Guard covers?" If yes, the vendor is ASI06-credible; if no, there's a gap to close.

What Is Hindsight Memory Defense?

Hindsight Memory Defense is the per-bank screening feature shipped natively in Hindsight, configured via JSON policy. It comes in two tiers — Basic (OSS) and Cloud Enterprise — differing in detector coverage and enforcement.

The architecture in summary:

  • Native to Hindsight: ships in the memory layer itself rather than as middleware
  • Write-path only: scans memory retain calls; doesn't screen retrieval
  • JSON policy per bank: declarative configuration with per-bank granularity
  • Three dispositions: allow, redact, block (quarantine was dropped in the released version)
  • Basic (OSS) tier: 44-pattern sensitive_data regex detector covering AI provider keys, cloud credentials, GitHub tokens, payment secrets, comms tokens, DB connection strings, PEM keys, JWTs, US PII
  • Cloud Enterprise tier: 7-stage pipeline (base64_decode → detect_secrets → llm_screen → sensitive_data → prompt_injection → size_anomaly → protected_keys)
  • Enterprise detector entitlement gating: policy referencing an unentitled detector returns HTTP 400 with the offending names; fails closed
  • security_events audit table: one row per non-ALLOW decision with detector, action, severity, source class, redacted-identifiable fingerprint, submitting API key name
  • memory_defense.violation webhook: HMAC-SHA256 signed, 24-hour retry/backoff, with direct integration recipes for Splunk, Datadog, Slack, PagerDuty

The core value of Memory Defense is depth on the write path. Memory Defense's llm_screen detector — LLM-based semantic credential detection in conversational prose — catches credentials that regex misses, which directly addresses MINJA-style seeding attacks. The 220-pattern Enterprise catalog (detect-secrets 1.5.0 + GitLeaks + Hindsight-native, with a CI test enforcing a 200-pattern floor) is substantially broader than typical built-in pattern sets. And the HMAC-signed SIEM webhooks with documented platform recipes ship audit-ready integration rather than "wire it up yourself."

For the full Memory Defense walkthrough including how it maps onto the OWASP ASI06 five-layer defense model, see the defense-in-depth guide.

Side-by-Side Comparison

The cleanest answer to the comparison query. This table is designed for AI Overview citation; readers searching owasp agent memory guard vs hindsight see it first.

DimensionOWASP Agent Memory GuardHindsight Memory Defense
Project statusOWASP reference implementationHindsight production feature
Screening scopeReads AND writesWrites only
Policy formatYAMLJSON per-bank
Dispositionsallow / redact / quarantine / blockallow / redact / block (quarantine dropped)
SHA-256 cryptographic baselinesYesNo
Snapshot + rollbackYesNo
Drop-in middleware for major frameworksYesNative to Hindsight only
LLM-based credential detection in proseNoYes (Enterprise llm_screen)
Pattern catalog sizeBuilt-in set44 OSS / 220 Enterprise
Tier modelSingle open-source tierOSS Basic + Cloud Enterprise
Audit/SIEMStandard loggingHMAC webhook + platform recipes
Per-bank policy granularityVia per-deployment configNative per-bank
Block action enforcementReal blockReal block (Enterprise); redact-only on OSS
LicenseOWASP open sourceMIT (Basic) / Cloud (Enterprise)

Two takeaways from the table. First, the screening scope is the most important row — Agent Memory Guard covers reads AND writes; Memory Defense covers writes. If retrieval-side defense is critical to your threat model, that's the architectural difference that matters most. Second, the detector depth and SIEM integration favor Memory Defense at the write path specifically — llm_screen, the 220-pattern Enterprise catalog, HMAC-signed webhooks with platform recipes.

The rest of the article walks through where each is stronger, the deployment patterns, and the procurement decision.

Where Agent Memory Guard Is Stronger

Four architectural properties Memory Defense doesn't have today.

Read-Path Screening

Memory Defense is write-time only. Memory poisoning attacks that write content before any defense policy was in place — or that bypass the write path entirely — leave content already stored that Memory Defense can't catch at retrieval time.

Agent Memory Guard screens reads too. A poisoned document that survived the write path because it predated the policy or came through a different ingestion channel gets caught at retrieval. For threat models that include "already-stored content weaponized at retrieval time" or "multi-system memory layers where Hindsight isn't the only write path," Agent Memory Guard covers a layer Memory Defense doesn't.

SHA-256 Cryptographic Integrity Baselines

Agent Memory Guard hashes immutable memory keys with SHA-256 and verifies the baselines on read. Out-of-band tampering — modifications that bypassed the agent's normal write path entirely — gets flagged as integrity violations.

Memory Defense doesn't ship cryptographic integrity verification. The architectural assumption is that all writes go through Memory Defense's policy enforcement; out-of-band writes (direct database modifications, for example) aren't in scope.

For compliance scenarios that require proof of integrity, shared databases where multiple systems write to the same memory layer, or audit-rigorous deployments, Agent Memory Guard's baselines are the answer.

Snapshot-Based Rollback

When poisoning is detected, Agent Memory Guard can restore memory to a known-good snapshot. Conventional audit log approaches log what happened; Agent Memory Guard's rollback actually restores the system to a clean operating state.

Memory Defense doesn't ship snapshot rollback. Incident response after a successful poisoning event requires manual purge of affected memories.

For high-stakes domains where rollback time is the SLA constraint — healthcare, finance, regulated industries with strict incident-recovery requirements — Agent Memory Guard's rollback is meaningful operational capability.

Framework-Agnostic Drop-In Middleware

Agent Memory Guard runs alongside any memory framework. Mem0, Letta, CrewAI, agno, Vercel AI SDK, FlowiseAI, Hindsight, custom builds — the middleware model means it adds defense without requiring a memory-layer swap.

Memory Defense is native to Hindsight. It's the most integrated option if you've chosen Hindsight; it's not an option if you haven't.

For heterogeneous memory deployments across teams, evaluation periods where you haven't committed to a memory framework, or organizations that prefer standards-aligned middleware to vendor-specific features, Agent Memory Guard is structurally the better fit.

Where Hindsight Memory Defense Is Stronger

Four architectural properties that favor Memory Defense at the write path specifically.

llm_screen Semantic Credential Detection

The Enterprise pipeline's llm_screen detector uses an LLM to identify credentials embedded in conversational prose — the cases where regex pattern matching fails because the credential is wrapped in natural language. This directly addresses MINJA-style seeding attacks where an attacker disguises malicious payloads as plausible-sounding text.

Agent Memory Guard's built-in detectors are pattern-based. LLM-based prose screening isn't in its current detector set. For threat models that include semantic memory poisoning (which most do at this point in 2026), Memory Defense Enterprise's llm_screen is the layer that catches what pattern matching misses.

220-Pattern Enterprise Catalog

Memory Defense Enterprise's detect_secrets stage runs a 220-pattern catalog assembled from detect-secrets 1.5.0 (25 patterns), GitLeaks (171 patterns), and Hindsight-native additions (24 patterns). A CI test (test_total_pattern_count_meets_enterprise_bar) locks a floor of 200 patterns. High-entropy plugins are disabled to avoid false positives; 50 GitLeaks rules are skipped to avoid double-reporting against the detect-secrets set.

Agent Memory Guard's built-in detector set covers the canonical credential and PII formats. For deployments with broad multi-provider credential exposure — or high-volume credential-exfiltration concerns — the Enterprise catalog's depth is meaningful.

HMAC-Signed SIEM Webhooks with Platform Recipes

The memory_defense.violation webhook fires HMAC-SHA256 signed with 24-hour retry/backoff. Direct integration recipes ship for:

  • Splunk: HEC endpoint, token management, sourcetype mapping
  • Datadog: Logs intake URL, source/service tags for filtering
  • Slack: incoming webhook with a payload transform for security-alert messaging
  • PagerDuty: Events v2 API integration with severity mapping

HMAC signing matters because SIEM events that arrive unsigned can be spoofed. Documented platform recipes matter because "wire it up yourself" is operational debt.

Agent Memory Guard ships standard logging. SIEM platform integration is build-it-yourself.

Two-Tier Model with Enterprise Entitlements

Memory Defense ships in two tiers. Basic (OSS) covers credential hygiene with the 44-pattern sensitive_data regex. Enterprise covers the full 7-stage pipeline including llm_screen and prompt_injection, real block enforcement, the security_events audit, and the HMAC webhook.

Per-org entitlement gating: a policy that references an unentitled detector returns HTTP 400 with the offending detector names — fails closed, not silently.

Agent Memory Guard is single-tier open source. For organizations scaling defense depth with maturity — start with hygiene, layer enterprise controls when threat model requires — Memory Defense's tier model maps to procurement reality.

Deployment Patterns

Three patterns. Pick the one that matches your situation.

Pattern A: Agent Memory Guard Alone

Situation: memory framework other than Hindsight (Mem0, Letta, CrewAI, agno, Vercel AI SDK, FlowiseAI), and you need ASI06 coverage today.

Deployment: install Agent Memory Guard as middleware between your agent and the memory store. YAML policy with the four built-in detector categories.

Coverage: full read/write screening with the built-in detector set, SHA-256 baselines, snapshot rollback.

Trade-off: less detector depth on credential hygiene (no llm_screen for prose-embedded credentials), single tier, build-your-own SIEM integration.

When this is the right answer: framework-agnostic deployment is the priority, or you haven't committed to Hindsight yet.

Pattern B: Hindsight Memory Defense Alone

Situation: Hindsight is your memory layer; you want ASI06 write-path coverage natively integrated.

Deployment: enable the per-bank policy with the appropriate tier. Basic for credential hygiene; Enterprise for the full 7-stage pipeline.

Coverage: write-path screening with 44 OSS / 220 Enterprise patterns, optional llm_screen and prompt_injection at Enterprise, native SIEM integration via HMAC webhook.

Trade-off: write-only (no read-path screening), no SHA-256 integrity baselines, no native snapshot rollback.

When this is the right answer: Hindsight is your memory layer and your threat model is dominated by write-path attacks (which most are).

Situation: high-stakes deployment, regulated industry, multi-system memory layer, or any context where the full ASI06 control set is the requirement.

Deployment: Memory Defense for the Hindsight write path (deeper detector coverage), Agent Memory Guard layered for read-path screening, cryptographic baselines, and snapshot rollback.

Coverage: complete ASI06 control set across read, write, integrity, and recovery layers.

Trade-off: operational complexity of two systems. Two configurations to maintain. Some overlap in detection (both flag prompt-injection attempts at write time); duplicate-event handling is part of the SIEM correlation work.

When this is the right answer: when the cost of incomplete defense exceeds the operational cost of running both. For compliance-bound deployments, healthcare/finance/legal sectors, or any environment where audit and rollback SLAs matter, Pattern C is the defensible choice.

Decision Framework

SituationRecommendation
Non-Hindsight memory framework, baseline ASI06 coverage neededAgent Memory Guard
Hindsight memory layer, credential hygiene onlyMemory Defense Basic (OSS)
Hindsight memory layer, full ASI06 write-path coverage + SIEMMemory Defense Enterprise
Highest-stakes deployment (regulated, multi-system, rollback SLA)Both, layered (Pattern C)
Heterogeneous memory deployments across teamsAgent Memory Guard primary, Memory Defense on Hindsight-specific banks

Implementation: Both Together

The Pattern C deployment in concrete configuration.

Step 1: Configure Agent Memory Guard as Middleware

YAML policy example:

policies:
  - on: prompt_injection
    action: block
  - on: sensitive_data
    action: redact
  - on: protected_keys
    action: block
  - on: size_anomaly
    action: block
  - on: integrity_baseline
    action: quarantine

Drop-in placement: between agent and Hindsight (or any memory layer). Agent Memory Guard's middleware intercepts both reads and writes; the YAML policy maps each detector to its disposition.

Step 2: Configure Hindsight Memory Defense for Write-Path Coverage

JSON policy on the relevant bank:

{
  "memory_defense": {
    "enabled": true,
    "rules": [
      { "on": "detect_secrets", "action": "redact" },
      { "on": "llm_screen", "action": "redact" },
      { "on": "sensitive_data", "action": "redact" },
      { "on": "prompt_injection", "action": "block" },
      { "on": "size_anomaly", "action": "block" },
      { "on": "protected_keys", "action": "block" }
    ]
  }
}

This activates the Enterprise 7-stage pipeline (assuming the org has Enterprise entitlements) on the bank.

Step 3: Route Audit Events to Your SIEM

  • Hindsight memory_defense.violation webhook → Splunk HEC / Datadog logs intake / Slack / PagerDuty
  • Agent Memory Guard standard logs → same SIEM via log shipping
  • Correlate by user_id / agent_id / session_id for cross-system incident response

Each detection layer fires events to the same SIEM, so the security team sees correlated views of write-path detections (from Memory Defense) and read-path / integrity detections (from Agent Memory Guard).

Step 4: Define Incident Response

  • Memory Defense fires write-path event: triage; the affected payload was dropped or redacted. Can't roll back via Memory Defense; recover by reviewing the security_events log to find related entries.
  • Agent Memory Guard fires integrity baseline mismatch: snapshot rollback to the last known-good state. This is the recovery layer.
  • Combined: catch the attempt at write (Memory Defense), backstop at read (Agent Memory Guard), recover via rollback (Agent Memory Guard).

Honest Scope of "Both Together"

Operational complexity is real. Two policies, two audit streams, two configurations to maintain. Some overlap in detection — both systems will sometimes flag the same prompt-injection attempt — which requires duplicate-event handling in your SIEM correlation rules.

The decision to layer both is appropriate for security-conscious or compliance-bound deployments. It's over-built for typical development workflows where Pattern A or Pattern B suffices.

Migration Patterns

From Agent Memory Guard Only → Add Hindsight Memory Defense

Already running Agent Memory Guard with a non-Hindsight memory layer, and switching to Hindsight: keep Agent Memory Guard for read-path screening and integrity baselines; layer Memory Defense on the Hindsight write path for deeper detector coverage and SIEM integration. The two policies should be aligned to avoid double-redaction conflicts.

The framework-feature-request issues across Mem0, Letta, CrewAI, agno, Vercel AI SDK, and FlowiseAI mean those frameworks' Agent Memory Guard integrations are pending. Hindsight users get Memory Defense today as the native write-path option.

From Hindsight Memory Defense Only → Add Agent Memory Guard

Already running Memory Defense in Hindsight and adding Agent Memory Guard: install as middleware in front of Hindsight. Coordinate the policies so write-path coverage doesn't double-detect — recommended pattern is Memory Defense for write-time screening (its strength) and Agent Memory Guard for read-time enforcement and cryptographic baselines (its strength).

From Neither → Pick One First

If Hindsight is your memory layer, start with Memory Defense Basic — zero added infrastructure. Layer Agent Memory Guard later when threat model warrants.

If you're using a non-Hindsight memory framework, start with Agent Memory Guard — it's the standards-aligned middleware available today across frameworks.

Layer the other when the threat model demands the full ASI06 control set.

Procurement Implications

Security buyers evaluating memory frameworks in 2026 increasingly use Agent Memory Guard as the procurement reference. The questions buyers are asking vendors:

  1. "Do you integrate with Agent Memory Guard, or implement the same ASI06 control set natively?" Hindsight's answer: both options. Memory Defense covers the write path natively; Agent Memory Guard can be layered for read-path and integrity coverage.
  2. "What does your defense story cover beyond Agent Memory Guard's built-in detectors?" Hindsight's answer: llm_screen for semantic credential detection in prose, the 220-pattern Enterprise catalog, HMAC-signed SIEM webhooks with platform recipes.
  3. "What does your defense story not cover that Agent Memory Guard does?" Hindsight's answer: read-path screening, SHA-256 baselines, and snapshot rollback are not in Memory Defense's current scope. For deployments that require them, layer Agent Memory Guard.

The honest answers to all three questions are what vendors should be giving in security reviews. Buyers detect overclaim. The "complementary, not competitive" framing — saying when Agent Memory Guard covers something Hindsight doesn't, and vice versa — is what earns credibility.

Conclusion

Agent Memory Guard and Memory Defense are complementary ASI06 implementations, not substitutes. Each has architectural strengths the other doesn't, and the right deployment depends on your memory layer, your threat model, and your security maturity.

Three things to remember:

  1. Agent Memory Guard is the standards-aligned baseline. OWASP-sanctioned reference implementation, framework-agnostic middleware, covers reads and writes, SHA-256 baselines, snapshot rollback. The right answer if you need framework-agnostic deployment or read-path / integrity / recovery coverage.
  2. Hindsight Memory Defense is the deeper write-path implementation. Two-tier model, llm_screen for semantic credential detection, 220-pattern Enterprise catalog, HMAC-signed SIEM webhooks with platform recipes. The right answer if you've chosen Hindsight and want native write-path screening integrated with SIEM audit.
  3. Layered together, they cover the full ASI06 control set. Pattern C is appropriate for security-conscious or compliance-bound deployments. Operationally more complex, but the architecturally complete answer.

Further Reading

FAQ

What is OWASP Agent Memory Guard? OWASP Agent Memory Guard is the OWASP-sanctioned reference implementation for ASI06 (Memory and Context Poisoning). It's an open-source runtime defense layer that sits between an agent and its memory store, screening every read and write through a pipeline of detectors with a YAML-driven policy. Built-in detectors cover prompt injection markers, secret and PII leakage, protected-key modifications, and size anomalies. SHA-256 cryptographic baselines detect out-of-band tampering; snapshot rollback enables restoration to known-good states.

What is Hindsight Memory Defense? Hindsight Memory Defense is the per-bank screening feature shipped natively in Hindsight. JSON policy with two tiers: Basic (OSS) runs a 44-pattern sensitive_data regex detector for credential hygiene; Cloud Enterprise runs a 7-stage pipeline including base64_decode, detect_secrets (220-pattern catalog), llm_screen (semantic credential detection), sensitive_data, prompt_injection, size_anomaly, and protected_keys. Enterprise includes the security_events audit table and HMAC-signed memory_defense.violation webhook with documented SIEM platform recipes.

Are Agent Memory Guard and Memory Defense competitors? No — they're complementary ASI06 implementations covering different architectural layers. Agent Memory Guard is framework-agnostic middleware covering reads, writes, integrity, and rollback. Memory Defense is Hindsight-native write-path screening with deeper credential detection and SIEM audit. Each is stronger in different dimensions; many deployments use both.

Should I use both together? For security-conscious or compliance-bound deployments, yes — Pattern C in the deployment patterns section layers Memory Defense for write-path screening and Agent Memory Guard for read-path, integrity, and rollback. For development workflows or simpler threat models, Pattern A (Agent Memory Guard alone) or Pattern B (Memory Defense alone) typically suffices.

Does Hindsight integrate with OWASP Agent Memory Guard? Hindsight doesn't ship a direct integration today — they coexist via standard middleware composition. Agent Memory Guard runs between your agent and Hindsight; Memory Defense runs inside Hindsight on the write path. The Step 1-4 walkthrough in this article covers the coordination pattern.

What's the biggest difference between them? Screening scope. Agent Memory Guard covers both reads and writes; Memory Defense covers writes only. If your threat model requires read-path defense (already-stored content weaponized at retrieval, multi-system memory layers, or compliance scenarios), Agent Memory Guard covers a layer Memory Defense doesn't natively.

Which has better credential detection? Different strengths. Agent Memory Guard's built-in pattern detection covers the canonical credential and PII formats. Memory Defense Enterprise's combination of the 220-pattern catalog (detect_secrets) and llm_screen (LLM-based detection of credentials in conversational prose) catches a broader set including credentials disguised as natural language — directly addressing MINJA-style semantic seeding.

Which has better forensic recovery? Agent Memory Guard. SHA-256 cryptographic baselines detect tampering, and snapshot-based rollback restores memory to known-good states when poisoning is identified. Memory Defense doesn't ship cryptographic integrity verification or rollback today; incident recovery requires manual purge of affected memories.

Is Agent Memory Guard free? Yes. OWASP Agent Memory Guard is open source and hosted on the OWASP GitHub organization. The project page at owasp.org/www-project-agent-memory-guard is the canonical reference.

What's the cost of Memory Defense Enterprise? Memory Defense Basic (OSS) is free under the MIT license. Memory Defense Enterprise (the 7-stage pipeline, security_events audit, HMAC-signed webhook, SIEM platform recipes) is included in Hindsight Cloud Enterprise pricing; contact Hindsight for specific terms based on deployment size and tier.