T02 · Agent Memory Poisoning
- Location
hooks/openclaw/handler.js:8- Finding
Untrusted User Feedback Can Be Promoted into Persistent Agent Instructions
- Content
View full analysis
Vulnerability Details
File Location:
hooks/openclaw/handler.js, lines 8-26
Vulnerability Type: Persistent agent memory poisoning through unvalidated learning promotion
Risk Level: HighVulnerable Code
javascript const REMINDER_CONTENT = ` ## Self-Improvement Reminder After completing tasks, evaluate if any learnings should be captured: **Log when:** - User corrects you → \`.learnings/LEARNINGS.md\` - Command/operation fails → \`.learnings/ERRORS.md\` - User wants missing capability → \`.learnings/FEATURE_REQUESTS.md\` - You discover your knowledge was wrong → \`.learnings/LEARNINGS.md\` - You find a better approach → \`.learnings/LEARNINGS.md\` **Promote when pattern is proven:** - Behavioral patterns → \`SOUL.md\` - Workflow improvements → \`AGENTS.md\` - Tool gotchas → \`TOOLS.md\` Keep entries simple: date, title, what happened, what to do differently. `.trim();The same promotion model is defined in
SKILL.md, lines 12-14 and 34-42:markdown 1. Detect signal: error, correction, capability gap, or repeated workaround. 2. Log to `.learnings/` with the right entry type. 3. Resolve or promote high-value patterns into durable workspace files. 4. Reuse scripts/hooks to keep capture consistent. ## Promotion rules Promote broadly reusable learnings out of `.learnings/`: - behavior/style -> `SOUL.md` - workflow/orchestration -> `AGENTS.md` - tool constraints/gotchas -> `TOOLS.md` Update original entries with status transitions (`resolved`, `promoted`, `wont_fix`) and references.Technical Analysis
User corrections are treated as learning sources, and the agent is instructed to promote selected learnings into
SOUL.md,AGENTS.md, andTOOLS.md. According toreferences/openclaw-integration.md, these workspace files are injected into agent context at session startup and therefore affect later sessions.The workflow does not require an en ...[truncated 2891 chars]
- Remediation
View remediation
Remediation Suggestions
-
Require explicit human approval before promotion
- Treat
.learnings/as untrusted, non-executable notes. - Generate a proposed diff for
SOUL.md,AGENTS.md, orTOOLS.md. - Require an affirmative user confirmation before applying it.
- Treat
-
Track provenance and trust
- Record the source session, author, timestamp, evidence, and affected files.
- Mark user feedback as untrusted until independently verified.
- Do not allow source text to change its own trust status or approval requirements.
-
Use a strict promotion schema
- Promote concise, declarative facts rather than raw user text.
- Reject shell commands, URLs, credential instructions, encoded content, prompt-control language, and directives to ignore existing policies unless separately reviewed.
- Escape or delimit quoted source material so it cannot be interpreted as an instruction.
-
Add mandatory verification gates
- Require corroboration from repository configuration, official documentation, tests, or repeated independently observed behavior.
- Define “proven” using objective criteria.
- Require security review for rules affecting command execution, authentication, networking, data handling, or agent safety.
-
Separate memory from policy
- Do not directly inject untrusted learning logs as authoritative bootstrap instructions.
- Store observations in a data-only format and have trusted code selectively render approved entries.
- Keep immutable safety policy at higher precedence than promoted workspace guidance.
-
Provide rollback and audit controls
- Version all promoted changes.
- Include the originating learning ID in each promoted rule.
- Support review, expiry, revocation, and automatic rollback of newly promoted instructions.
-
Harden the reminder text
- Explicitly state that user corrections may be adversarial.
- Instruct ...[truncated 180 chars]
-
