Threat dossier · P2

Memory and context poisoning

Persistent state can amplify one poisoned interaction across future sessions, plans, tools, and delegated work.

Direct answer

What is memory and context poisoning?

Memory poisoning stores attacker-controlled or incorrect context so it can influence later agent decisions after the original malicious input is gone.

Coverage statements below are limited to the current HOL Guard support contract and do not imply universal model or harness protection.

Copied text includes the canonical source and review date.
Reviewed Reviewer: HOL Guard EngineeringReview cadence: 30 days

Representative attack path

Defensive model only. This sequence omits weaponized payloads and is not attributed to a specific incident unless a source explicitly says so.

  1. Step 1

    Untrusted content reaches a writeable memory/context mechanism.

  2. Step 2

    Poisoned state is retained.

  3. Step 3

    A later task retrieves the poisoned state as trusted context.

  4. Step 4

    The future plan or tool action changes.

Coverage boundary

What this control can cover

  • Consequential supported actions influenced by retrieved memory can still be evaluated at action boundaries.
  • Evidence pages can preserve the distinction between context risk and runtime enforcement.

What it does not prove or prevent

  • Universal inspection or sanitization of every third-party memory store.
  • Proof that retained natural-language memory is semantically correct.

Policy pattern

Policy pattern for memory and context poisoning

Keep untrusted context or overbroad autonomy from becoming unconditional execution authority on supported action surfaces.

Use when: Persistent state can amplify one poisoned interaction across future sessions, plans, tools, and delegated work.

Decision pattern

  1. Identify the trust boundary and consequential action class.
  2. Apply least privilege and the narrowest supported policy.
  3. Require review for sensitive or ambiguous actions.
  4. Preserve only redacted, versioned evidence needed to reproduce the decision.

Limitations

  • Universal inspection or sanitization of every third-party memory store.
  • Proof that retained natural-language memory is semantically correct.

If you suspect prompt injection

  1. Step 1

    Response 1

    Quarantine affected memory/state.

  2. Step 2

    Response 2

    Trace the write source and downstream reads.

  3. Step 3

    Response 3

    Rebuild from verified context where possible.

  4. Step 4

    Response 4

    Retest downstream actions after cleanup.

Sources and mappings

Last reviewed . This dossier separates sourced threat definitions from modeled attack paths and evidence-bounded product coverage.

Author: HOL Guard Research

Reviewer: HOL Guard Engineering

Change log

  • 2026-08-09: Published canonical threat dossier with attack path, coverage/non-coverage, response procedure, and sources.

Report a correction