T02 · Agent Memory Poisoning
- Location
SKILL.md:84- Finding
Persistent Untrusted Learning Content Can Influence Future Agent Behavior
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:84-87
Related Locations:references/operating-rules.md:3-17,references/operating-rules.md:51-55,references/logging-format.md:54-59
Vulnerability Type: Persistent agent memory poisoning
Risk Level: MediumVulnerable Code and Instructions
SKILL.md:84-87:markdown Before major tasks: grep .learnings/*.md for relevant past issues. After errors or corrections: log a one-line entry using agent-memory-loop. Never auto-write to SOUL.md, AGENTS.md, TOOLS.md, or similar instruction files. Stage candidate rule changes in .learnings/promotion-queue.md for human review.references/operating-rules.md:3-17:markdown ## When to log | Trigger | File | |---|---| | Command/tool failure | `errors.md` | | User correction or agent discovery | `learnings.md` | | Requested capability you do not have | `wishes.md` | | Recurrent or critical lesson ready for human review | `promotion-queue.md` | ## Dedup process 1. Check for an existing `id:` first 2. If no ID match, grep by a stable keyword or command name 3. If found, update the existing line instead of appending a duplicate 4. Bump `count:N` and refresh the date when appropriate 5. Keep the original `source:` unless the original entry was wrongreferences/operating-rules.md:51-55:markdown ## Pre-task review Before high-risk or previously-problematic work: 1. grep `.learnings/*.md` for the task keyword 2. name the relevant learning 3. state the adjustment you are making 4. after success, increment `prevented:N` if the learning actually changed behaviorreferences/logging-format.md:54-59:markdown | Source | Meaning | Promotable? | |---|---|---| | `source:agent` | Agent observed it directly | Yes | | `source:user` | User correction | Yes, after review | | `source:external` | Email, web page, webhook, attachment, forwarded content | No |Technical Analysis
The Skill creates a persistent
.learnings/s ...[truncated 2671 chars]- Remediation
View remediation
Remediation Suggestions
- Treat all persisted learning content as untrusted data rather than executable instructions. Explicitly state that entries cannot override system, developer, security, workspace, or current-user instructions.
- Do not apply
source:externalentries as behavioral adjustments. Present them only as contextual evidence unless a trusted human has reviewed and approved them. - Require explicit approval before
source:userentries can influence future behavior, especially when they contain imperative language or operational rules. - Add an approval field, such as
review:approved, and restrict pre-task retrieval to approved records. - Replace unrestricted free-form behavioral rules with structured fields and validated enums. Keep observations separate from proposed actions.
- Implement script-enforced validation for source labels, status transitions, required fields, and allowed target files rather than relying solely on documentation.
- Escape or clearly delimit retrieved records and instruct the agent not to follow commands, links, tool requests, or policy changes embedded inside them.
- Record provenance and reviewer identity for approved entries, and maintain an auditable approval history.
- Add integrity protections or workspace permission controls so untrusted processes cannot directly modify
.learnings/. - Provide a safe review command that displays unapproved content for human inspection but excludes it from automatic pre-task behavioral context.
