Agent Memory Governance

What memory poisoning is, and why governance matters

Agents that carry durable memory — facts embedded and recalled across sessions — inherit a new attack surface. Where a prompt injection lasts one turn, a memory-poisoning payload is engineered to persist: an adversary writes content designed to survive into future sessions, displace the system prompt, or overwrite the agent's stored state and identity. The malicious instruction is recalled and re-applied long after the original request is forgotten.

This maps to the OWASP Agentic Security Initiative threat ASI06 (Memory & Context Poisoning) and MITRE ATLAS technique AML.T0080 (Manipulate AI Model — Memory). EvalGuard's detector is a clean-room re-implementation, in the platform's TypeScript pattern-set style, of the memory-poisoning attack taxonomy in NVIDIA's SkillSpector (Apache-2.0). Governance sits betweenthe write-time poisoning screen and the tamper-evident memory-mutation ledger: given an org's policy and a proposed memory write, it decides whether to allow, flag, block, or require human approval — deterministically, with no LLM call, no database, and no network in the decision path.

Policy modes: off / monitor / enforce

A policy is scoped to an org (and optionally a single project) and carries one of three enforcement postures. The database default is monitor. In monitor mode every actionable signal is downgraded to a flag — the engine records the would-be verdict but never gates the write, mirroring the plan-gate and access-policy monitor semantics elsewhere in the platform.

Verdicts and how they combine

The engine renders one of four verdicts, ordered by severity: allow < flag < require_approval < block. When several signals fire on one write, the strongest contributing signal wins. The signal → verdict rules are:

The decision object carries the verdict, one human-readable reason per contributing signal, a requiresApproval boolean (true only for require_approval), a screened summary (detected, confidence, poisonedCount), and numeric scores (poisonConfidence, provenanceScore) for dashboard and audit pivots.

Detection classes: MP1, MP2, MP3

The poisoning screen runs a deterministic, low-false-positive detector over each memory's content. Alongside the generic prompt-injection, contradiction, and trust-escalation pattern sets (and base64 / homoglyph obfuscation checks), it applies three classes that specifically target durable memory. Every pattern is a concrete attack phrase, not casual English — so benign memory like "I'll remember to buy milk" or "the user's new role is team lead" stays unflagged by design.

MP1 — persistent cross-session injection

Content engineered to survive and steer future sessions and turns, rather than override a single prompt. Indicator type persistent-injection, severity high. Triggers include:

• "always remember this for all future conversations" — persist-for-future-sessions
• "from now on, always …" / "henceforth, you must …" — from-now-on standing order
• "store this permanently in your long-term memory" — write-to-durable-memory
• "add this to your memory" / "implant it into your context" — implant-into-memory
• "this is a permanent instruction" — declared-permanent-directive
• "treat this as a permanent rule" — treat-as-permanent-rule
• "permanently update your core behavior" — alter-core-behavior

MP2 — context-window stuffing (ReDoS-safe)

Displacing legitimate or safety content by flooding or repeating text until the original context is pushed out. Indicator type context-stuffing, severity high. Phrase triggers include "repeat this 1000 times", "fill up the context window", "push out the system prompt", "exhaust the token window", and "generate thousands of words".

A separate literal-repetition scan catches raw stuffing that has no natural-language trigger. It is a bounded, linear O(20·n) scan — not a backreference regex, so it cannot be turned into a ReDoS. It flags a short unit (1–20 characters) repeated 20 or more times in a row within a string of at least 60 characters. A decorative single-character run with no spaces (a rule like ===== or -----) is deliberately ignored to stay low-false-positive; a multi-character or spaced unit repeated many times is the stuffing signal.

MP3 — memory / identity manipulation

Directly wiping, overwriting, poisoning, or rewriting the agent's memory, state, or persona — the highest-severity class. Indicator type memory-manipulation. Most patterns are high; two are critical:

Confidence and the actionability threshold

The screen aggregates indicators into a confidence score: critical × 0.35 + high × 0.20 + medium × 0.10, capped at 1.0. A poisoning result is actionableonly when its confidence is at or above the policy's poisonMinConfidence threshold — default 0.2. This is why a lone medium-severity signal (for example a single base64-looking blob at 0.10) does not trip enforcement on its own, while a single MP1/MP3 high signal (0.20) meets the bar. Raise the threshold to make the policy less trigger-happy; lower it to catch weaker signals.

Human-in-the-loop on rewrite / consolidate

A durable-memory write has a kind: remember, forget, consolidate, or rewrite. The last two mutate memory the agent already holds — the riskiest autonomous operations. With requireApprovalOnRewrite set, a consolidate or rewrite resolves to require_approval under enforce (the write is held for a human to approve) and to flag under monitor. A plain remember or forget is never gated by this rule.

Independently, requireProvenance flags any governed write in which a memory item lacks a non-empty source — a transparency defect that is flagged in both modes. Provenance completeness is scored 0..1by the memory-provenance scorer and surfaced on the decision's provenanceScore.

The hash-chained decision ledger

When enforcement is active, every verdict is appended to agent_memory_governance_decisions — an org-scoped, append-only, hash-chained ledger modelled exactly on the agent-memory-mutation ledger. It gives you a tamper-evident record of what governance decided, without ever storing the memory content itself.

• Hashes only, no PII. The sealed decision body concatenates the write kind, verdict, actor, and a per-memory fnv1a64 content digest — raw memory text never lands in the ledger. Only a content_hash is stored.
• Linear chain. Each entry's chain_hash links to the prior entry within the (org_id, session_key) chain, so any insertion, deletion, or reorder breaks the link. A UNIQUE (org_id, session_key, seq) constraint pins ordering.
• Append-only for every role. A BEFORE UPDATE OR DELETE trigger raises a restrict_violation for all roles — including service_role. Corrections append a compensating entry (revert_of), never an in-place edit.
• Least-privilege RLS. Org members may SELECTtheir org's entries; service_role is the sole writer; anon is revoked entirely.

REST API

The policy is managed through one org-scoped route. All four verbs require the owner or admin role (enforced by the API handler and by RLS at the database), and every write is written to the audit log (agent_memory.governance.update / agent_memory.governance.delete).

The upsert body is strict: orgId (UUID, required), projectId (UUID or null; absent = the org-wide policy), enabled (boolean), mode (off / monitor / enforce), and a config object of { thresholds: { poisonMinConfidence }, requireApprovalOnRewrite, requireProvenance }. The returned policy record carries id, orgId, projectId, enabled, mode, config, createdBy, createdAt, and updatedAt.

curl -X PUT "https://evalguard.ai/api/v1/agent-memory/governance" \
  -H "Authorization: Bearer eg_live_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "orgId": "00000000-0000-0000-0000-000000000000",
    "enabled": true,
    "mode": "enforce",
    "config": {
      "thresholds": { "poisonMinConfidence": 0.8 },
      "requireApprovalOnRewrite": true,
      "requireProvenance": true
    }
  }'

Configure it from any surface

The same policy CRUD is exposed across every EvalGuard surface. Each is a thin client over the route above and carries the same admin-role gate.

# Read the current policy (null if none / pre-migration)
evalguard agent-memory governance get --org 0000...-0000

# Enforce, require approval on rewrites, require provenance,
# and only act on poisoning at confidence >= 0.8
evalguard agent-memory governance set \
  --org 0000...-0000 \
  --mode enforce \
  --enable \
  --require-approval-on-rewrite \
  --require-provenance \
  --poison-min-confidence 0.8

# Scope a stricter policy to one project
evalguard agent-memory governance set \
  --org 0000...-0000 --project 1111...-1111 --mode monitor --enable

The policy is also editable from the dashboard under organization settings. Whichever surface you use, the write lands in the same org-scoped table and audit log.

Activation prerequisites (honest current state)

Read this before you rely on governance to block anything. The policy plane and the pure decision engine are shipped; enforcement is deliberately gated so it is turned on only after the data plane exists in production.

In other words: today the REST route and every SDK/CLI/Terraform client manage configuration. The evaluation engine (evaluateMemoryGovernance) is pure, tested, and ready, but the app-layer wiring that runs it on each durable-memory write and seals the verdict into the ledger only takes effect once the founder has applied migration 20260783 and flipped EVALGUARD_ENFORCE_MEMORY_GOVERNANCE on. Setting a policy to enforce records your intent; it does not, by itself, block a write until those two prerequisites are met.