T02 · Agent Memory Poisoning
Error
- Location
task-knowledge-framework.md:7- Finding
Persistent Instruction Injection Through Shared Memory and Generated Skill Files
- Content
View full analysis
Vulnerability Details
File Location:
task-knowledge-framework.md, lines 7-18
Vulnerability Type: Persistent memory and instruction poisoning
Risk Level: HighEvidence
The following is an English translation of the complete relevant documentation segment:
markdown ### Task Persistence Iron Law - Prohibited: Task loss. All important tasks must be written to MEMORY.md. - Format: Task description + acceptance criteria + deadline + owner + status. - Persistence: Before starting work, every agent must confirm the current tasks in MEMORY.md. - Incorrect example: Context for the mobile remote-control deployment task was lost. - Improvement: Establish a task knowledge base in which every task has a unique ID and complete record. ### Session Management Iron Law - Prohibited: Memory failure. Every agent must have a daily memory file. - Inspection: The steward checks every agent's memory/YYYY-MM-DD.md file daily. - Backup: Important memory files are backed up to shared_memory/. - Incorrect example: The writer agent repeatedly had no memory file. - Improvement: Establish session health monitoring and recovery mechanisms.Related propagation requirements also appear in:
SKILL.md, lines 18-20: review results must be written to Skill files, an Obsidian knowledge base, and daily memory logs.session-management-iron-laws.md, lines 55-70: every error must become a Skill or rule, and Skill files must be updated regularly.task-knowledge-framework.md, lines 76-85 and 112-121: errors must be converted into rules, and work cannot end until knowledge is persisted.working-iron-laws.md, lines 45-49 and 59-63: tasks and errors must be written to persistent knowledge stores.
Technical Analysis
The documentation directs an agent to copy current task content, error descriptions, and behavioral rules into
MEMORY.md, daily memory files,shared_memory/, and newly generated Skill file ...[truncated 1977 chars]- Remediation
View remediation
Remediation Suggestions
- Remove requirements that automatically convert task content or errors into persistent rules.
- Require explicit user approval before writing to
MEMORY.md, shared memory, an Obsidian repository, or a Skill file. - Store factual task state separately from executable instructions and behavioral policy.
- Mark every persisted entry with its source, author, creation time, trust level, and expiration time.
- Treat reloaded memory as untrusted data rather than authoritative instructions.
- Apply content filtering to prevent stored records from containing tool commands, role changes, safety overrides, or instructions to modify additional memory.
- Restrict shared-memory and Skill-writing permissions according to least privilege.
- Require human review and version-controlled approval before generated content becomes an active Skill.
- Add retention limits and deletion procedures for task context and personal information.
- Replace workflow vetoes such as “work cannot end” with non-binding review recommendations.