T02 · Agent Memory Poisoning
- Location
SKILL.md:42- Finding
Unvalidated User Instructions Are Persisted and Propagated Across Sessions
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:42-55, with related propagation behavior atSKILL.md:98-109andSKILL.md:125-137
Vulnerability Type: T02: Agent Memory Poisoning
Risk Level: HighVulnerable Skill Instructions
The following is an English translation of the relevant segment at
SKILL.md:42-55:text Step 2: Determine whether it is worth persisting - If it involves only one or two simple tool calls, do not persist it. - If there is a clear "if...then..." pattern, it is worth persisting. - A process corrected by the user must be persisted. - Cross-step or cross-tool orchestration is worth persisting. Step 3: Extract it as a skill item Write it to the current daily log at memory/YYYY-MM-DD.md: ## Skill Persistence: [Skill Name] - Scenario: When to use it - Core Steps: Brief description in three to seven steps - Pitfalls: Where errors can easily occur - Optimization: How it can be improved next time Step 4: Evaluate whether it should be promoted to a formal Skill If the same pattern appears three or more times, consider creating an independent SKILL.md.The error-propagation instructions at
SKILL.md:98-109state:text When an error or user correction occurs: Step 1: Record it immediately Write it to the current day's memory/YYYY-MM-DD.md: [Error description] Cause: [Why it was wrong] Correction: [What is correct] Lesson: [How to avoid it in the future] Step 2: Check whether it affects existing knowledge Search MEMORY.md and the related Skill for entries requiring updates. If any exist, correct them immediately. Step 3: Propagate it to related contexts If the error concerns a specific platform, update the related notes. If it is a general methodology, write it to the "Lessons" section of MEMORY.md.The recurring review instructions at
SKILL.md:125-137state:text Periodic s ...[truncated 4030 chars]- Remediation
View remediation
Remediation Suggestions
- Remove mandatory persistence of user corrections. Treat corrections as untrusted observations until independently validated.
- Require explicit approval before persistent writes. Display the exact proposed entry, destination file, and reason, then require informed user or administrator confirmation.
- Separate data from instructions. Store historical observations in a non-executable format that cannot automatically become Agent policy or Skill guidance.
- Introduce provenance and trust metadata. Record the source, timestamp, validation status, reviewer, and confidence for every proposed lesson.
- Prohibit automatic promotion. Repetition alone must not promote content into
MEMORY.mdor a formal Skill. Require trusted review and successful validation. - Restrict writable locations. Apply an allowlist of files and sections the Skill may update. Prevent direct modification of existing Skills or high-trust memory by default.
- Validate proposed knowledge. Check corrections against trusted documentation, deterministic tests, or administrator-approved sources before persistence.
- Sanitize stored content. Reject embedded commands, role-changing instructions, tool directives, secrets, credentials, personal data, and content attempting to modify security constraints.
- Disable unattended Heartbeat rewrites. Recurring reviews may generate recommendations, but they should not alter
MEMORY.mdor Skills without approval. - Add rollback and audit logging. Preserve version history and provide a straightforward method to inspect and revert poisoned memory or Skill changes.
- Use least privilege. Run the review process with read-only access and delegate approved writes to a narrowly scoped component.
- Define retention controls. Avoid persisting sensitive conversation content and provide expiration, deletion, and user-consent mechanisms.
