Context Memory Recovery

• Outcome: Review
• Latest audit: Sep 16, 2026 · 7:34 AM UTC
• Version: 0.2.0

Overview

This is a coherent memory-recovery skill, but it needs review because it lets workspace memory files persist operating rules and drive future agent actions without strong integrity or confirmation controls.

Install only in workspaces where the memory files are writable by trusted parties. Review SESSION-STATE.md, memory/*.md, and MEMORY.md before recovery, and require confirmation before adopting standing rules or executing saved next steps, especially in shared projects or sensitive environments.

A.I.G

Vulnerability Patterns

• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally
• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs

Findings (1)

T02 · Agent Memory Poisoning

Warning

• Location: SKILL.md:39

Finding

Persistent Agent Memory Poisoning Through Untrusted Workspace Files

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 39-44; related behavior at lines 137-143, 165-175, and 283-287
Vulnerability Type: Persistent memory poisoning caused by treating writable workspace files as authoritative instructions
Risk Level: Medium

Vulnerable Code Snippets

markdown

## Source-of-Truth Hierarchy

Use this hierarchy when saving or recovering context:

1. `SESSION-STATE.md` — immediate operational recovery file
2. `memory/YYYY-MM-DD.md` — daily continuity log
3. `MEMORY.md` — durable long-term memory and standing rules

If chat history conflicts with saved files, trust the files unless there is strong evidence they are stale.

The recovery procedure reinforces this trust model:

markdown

7. Reconstruct:
   - current mission
   - active tasks
   - latest decisions
   - blockers
   - important preferences
   - next step
8. If the next step is clear and safe, continue. Do not wait passively.
9. If the files disagree, use this priority: session-state for immediate task state, daily memory for recent evidence, long-term memory for standing rules.

The save procedure permits rules and preferences to persist:

markdown

1. Identify what must be preserved:
   - current mission
   - active tasks
   - decisions
   - blockers
   - preferences
   - next step
   - recovery-critical file paths, service names, IDs, or commits
2. Update the recovery file with the current operational state.
3. Update today's `memory/YYYY-MM-DD.md` with the relevant event, decision, task state, or preference.
4. Update `MEMORY.md` only if the information is durable, long-term, or a standing rule/preference/decision.
5. Verify the saved content is sufficient for a fresh agent to recover without chat history.
6. Reply exactly:

The quality rules repeat the unsafe precedence:

markdown

- Long-term memory is for durable rules only.
- Files beat chat history.
- After recovery, act if the path is clear.

Technical Analysis

The ...[truncated 3132 chars]

Remediation

View remediation

Remediation Suggestions

1. Treat all recovered memory as untrusted data

   • Explicitly prohibit interpreting memory-file content as higher-priority instructions.
   • Use stored files only to reconstruct factual task state.
   • Require current authenticated user instructions and platform safety policies to take precedence.

2. Separate facts from instructions

   • Store state in a constrained schema with fields such as task status, evidence, timestamps, and identifiers.
   • Do not permit free-form standing rules, policy overrides, tool commands, or behavioral instructions in recoverable state.
   • Escape or quarantine text that resembles prompt injection.

3. Record and validate provenance

   • Record who or what created each entry, when it was written, and the source interaction or operation that authorized it.
   • Reject entries with missing, invalid, or unexpected provenance.
   • Distinguish user-approved durable preferences from model-generated summaries.

4. Protect integrity

   • Apply restrictive filesystem permissions so only the intended owner and trusted agent process can modify memory files.
   • Where feasible, authenticate records using signatures or keyed message authentication codes.
   • Detect unexpected modifications through hashes, version control, or an append-only audit log.

5. Require confirmation for consequential recovery actions

   • Present recovered missions, rules, and next actions to the current user before adopting them.
   • Require explicit approval before executing commands, accessing sensitive data, changing configuration, contacting external services, or exposing durable memory.
   • Never automatically resume a high-impact operation solely because a memory file labels it as the next step.

6. Remove unsafe precedence statements

   • Replace “trust the files” and “files beat chat history” with a rule stating that stored state is advisory and must be reconciled with authenticated current-session in ...[truncated 385 chars]

SkillSpector

Vulnerability Patterns

• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (3)

Vague Triggers

Medium

• Category: Not specified by scanner
• Confidence: 93% confidence

Finding

The save trigger accepts broad, natural-language phrases like 'remember this' and 'we may need this later' based on inferred intent, which can cause unintended activation during normal conversation. In a file-writing skill, accidental triggering can persist incorrect, sensitive, or partial context to workspace memory, creating privacy leakage and state corruption risks across future sessions.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium

• Category: Not specified by scanner
• Confidence: 88% confidence

Finding

The recovery trigger also allows intent-based activation beyond the exact command, so ordinary requests like 'recover from memory' or loosely similar phrasing may initiate file reads and workflow resumption without a deliberate recovery command. Because recovery may read SESSION-STATE, daily memory, and MEMORY.md, ambiguous triggering increases the chance of unnecessary exposure of stored context and unintended autonomous action.

Content

No source excerpt is available for this finding.

Vague Triggers

Low

• Category: Not specified by scanner
• Confidence: 88% confidence

Finding

The manifest description says the skill is for "OpenClaw, Hermes, and similar agents," but does not define what qualifies as a similar agent or the context in which the skill should be invoked. In a manifest file, this kind of broad applicability can create ambiguity about trigger scope and increase the chance of unintended activation.

Content

No source excerpt is available for this finding.