T02 · Agent Memory Poisoning
Error
- Location
- SKILL.md:46
- Finding
- Persistent Agent-State Poisoning Through Automatic Rule and Memory Modification## Vulnerability Details **File Location**: `SKILL.md`, lines 46–51 and 89–93 **Vulnerability Type**: Persistent memory and behavioral-rule modification **Risk Level**: High ### Vulnerable Code ```markdown 1. Record KPI in `memory/YYYY-MM-DD.md` - `executed`: what shipped - `result`: measurable outcome (URL/count/status) - `next`: one concrete optimization 2. Mirror the same KPI block to Obsidian daily note. 3. Include KPI in the completion message. ``` ```markdown ## Postmortem rule If a delay occurs, immediately: 1. acknowledge miss, 2. apply a permanent rule update (MISSION or this skill), 3. log the change in `memory/YYYY-MM-DD.md`. ``` ### Technical Analysis The skill directs the agent to write task-derived information into persistent memory and an Obsidian daily note. More critically, it requires the agent to apply a permanent update to `MISSION` or the skill whenever a delay occurs. The content and boundaries of that permanent update are not defined. There is no requirement to obtain user approval, present a proposed diff, validate task-derived content, or constrain changes to a safe schema. Consequently, instructions or other content originating from an untrusted task can be incorporated into files that influence later agent sessions. This is a persistent state-poisoning condition rather than ordinary operational logging. Changes to `MISSION` or the skill can alter future agent behavior after the original task has ended. ### Attack Path 1. An attacker supplies a task containing adversarial instructions or content intended to influence future behavior. 2. The task experiences or appears to experience a delay. 3. The postmortem rule requires the agent to make a permanent update to `MISSION` or the skill. 4. The agent incorporates task-derived content into that update without mandatory review or sanitization. 5. The modified file or persistent memory is loaded during future session ...[truncated 1034 chars]
- Remediation
- ## Remediation Suggestions 1. Remove the instruction to modify `MISSION` or the skill automatically. 2. Require explicit user authorization before changing any persistent behavioral configuration. 3. Present the exact target file and proposed diff before applying an approved rule change. 4. Store postmortem observations in a dedicated append-only operational log rather than executable or instruction-bearing files. 5. Make KPI logging opt-in and document every destination receiving the data. 6. Use a fixed structured schema and reject instruction-like fields, markup, or unbounded task content. 7. Apply destination allowlists and least-privilege filesystem permissions. 8. Avoid mirroring data to Obsidian unless the user has explicitly enabled that integration. 9. Separate untrusted task data from trusted instructions when persistent records are later loaded. 10. Add review, rollback, provenance, and audit mechanisms for all persistent configuration changes.