T02 · Agent Memory Poisoning
Warning
- Location
- SKILL.md:91
- Finding
- Untrusted checkpoint content can poison persistent agent state<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:91-96`; supporting checkpoint writer at `scripts/context-checkpoint.sh:15-41` **Vulnerability Type**: Persistent agent-state poisoning **Risk Level**: Medium ### Vulnerable Code `SKILL.md:91-96`: ```markdown After compaction or `/new`: 1. Read `.context-checkpoint.md` if it exists 2. Read today's daily log if the workspace has one (e.g. `memory/{today}.md`) 3. Resume from the checkpoint's "Next Steps" 4. Delete the checkpoint file after restoring context ``` `scripts/context-checkpoint.sh:15-41`: ```bash write) TASK="${3:-No active task described}" STATE="${4:-No state captured}" DECISIONS="${5:-None recorded}" FILES="${6:-None recorded}" NEXT="${7:-No next steps defined}" DATE=$(date -u +"%Y-%m-%d %H:%M UTC") cat > "$CHECKPOINT" <<EOF # Context Checkpoint — $DATE ## Active Task $TASK ## Key State $STATE ## Decisions Made This Session $DECISIONS ## Files Changed $FILES ## Next Steps $NEXT EOF echo "Checkpoint written: $CHECKPOINT" ;; ``` ### Technical Analysis The checkpoint script persists caller-controlled text in `.context-checkpoint.md`, including the `Next Steps` field. The post-compaction recovery procedure subsequently instructs the agent to read this mutable workspace file and resume from its contents without validating provenance, integrity, or whether embedded directives should be treated only as untrusted data. A process or user with workspace write access could create or alter the checkpoint before recovery. Because the checkpoint survives compaction and new-session boundaries, malicious directives could continue influencing the agent after the original conversational context has been compressed or discarded. The issue does not involve shell command injection: the supplied values are written through a here-document rather than executed by the shell. The vulnerability instead exists at the agent instruction and persistent-state trust boundary. ### Att ...[truncated 1330 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Explicitly classify checkpoint files and daily logs as untrusted data. State that instructions embedded in them must never be executed automatically. 2. Require the agent to summarize recovered state and obtain user confirmation before acting on recovered `Next Steps`. 3. Validate checkpoints against a strict schema and reject unexpected sections, instruction-like content, or malformed fields. 4. Bind checkpoints to the originating workspace and session using metadata such as a session identifier, creation timestamp, and normalized workspace path. 5. Add integrity protection where feasible, such as a keyed message authentication code stored outside the writable workspace. 6. Refuse to read or overwrite a checkpoint if the path is a symbolic link or resolves outside the expected workspace. 7. Create checkpoint files atomically with restrictive permissions, for example by writing to a securely created temporary file, setting mode `0600`, and renaming it into place. 8. Record and display the checkpoint's origin, modification time, and integrity status during recovery. 9. Treat recovered actions as contextual notes rather than authoritative instructions; re-evaluate every action against the current user request and applicable safety policy. ]]>