T02 · Agent Memory Poisoning
- Location
SKILL.md:316- Finding
Automatic Promotion of Untrusted Lessons into Persistent Agent Instructions
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:316-339
Vulnerability Type: Persistent agent memory poisoning
Risk Level: MediumVulnerable Code Snippet
markdown ## Gate 5 — Lessons (Auto, no confirmation needed) Run automatically after CR closes. No user action required. 【经验沉淀 #CR-YYYYMMDD-NN】 任务类型:<type> 本次教训: - <what operation caused what problem> - <what to watch for next time with similar requests> 新增底层规则: ✅ 永远要做:<rule> ❌ 永远不做:<rule> 写入: lessons/lessons.md → <dated entry> lessons/hard-rules.md → <if new permanent rule established> test-cases/all-test-cases.md → <append TCs from this CR> CHANGELOG.md → <append entry> Hard rules never expire. On every new session, load `hard-rules.md` and apply before handling any request.The associated automatic-loading requirement appears at
SKILL.md:112-116:markdown lessons/ hard-rules.md # Permanent rules, never expire lessons.md # Historical lessons, dated entries On new session start: auto-load `PROJECT.md` + `lessons/hard-rules.md` + `lessons/lessons.md`. These files are the AI's persistent memory across sessions.Technical Analysis
Gate 5 directs the agent to derive permanent behavioral rules from task outcomes and write them to
lessons/hard-rules.mdautomatically, without user confirmation. Subsequent sessions must load and apply those rules before handling new requests.Task descriptions, repository content, test output, and other project-controlled material can influence the generated lesson. The workflow does not define a trust boundary, validation procedure, provenance check, safety-policy check, or approval gate before converting that contextual material into durable instructions. Consequently, attacker-influenced content can be promoted from untrusted project data into persistent agent state.
The risk is specifically persistent instruction poisoning rather than ...[truncated 1480 chars]
- Remediation
View remediation
Remediation Suggestions
- Require explicit user approval before adding or modifying any permanent rule.
- Present the proposed rule, its source, rationale, scope, and expiration policy in a dedicated confirmation gate.
- Treat repository files, task text, logs, test output, and generated lessons as untrusted data rather than authoritative instructions.
- Validate proposed rules against higher-priority safety constraints and reject rules that request secrecy, privilege expansion, unrelated actions, or weakened review requirements.
- Record provenance for each rule, including the originating change request, source files, approving user, creation time, and last review time.
- Replace “never expire” with periodic review, expiration, revocation, and rollback mechanisms.
- Load persistent records as quoted reference data and explicitly prohibit them from overriding system, developer, user, or platform security policies.
- Restrict writes to the expected project-local
.dev-workflow/lessons/directory and review diffs before committing them. - Keep ordinary lessons separate from enforceable rules; only manually approved content should enter
hard-rules.md.
