T02 · Agent Memory Poisoning
Warning
- Location
- POLICY.md:86
- Finding
- Unconfirmed Implicit Preferences Can Be Written to Persistent Agent Memory## Vulnerability Details **File Location**: `POLICY.md:86-91` **Vulnerability Type**: Persistent agent memory poisoning through inferred preferences **Risk Level**: Medium ### Vulnerable Code ```markdown ## Preference Learning - Before significant actions, check known preferences - Capture explicit preferences ("I prefer short replies") - Learn implicit preferences from patterns - Store in USER.md or structured preference file - Apply automatically; if unsure, default to short-first ``` ### Technical Analysis The operational policy instructs the agent to infer implicit preferences from interaction patterns, store preferences in `USER.md` or another structured preference file, and apply them automatically in future actions. This section does not require the user to review or approve an inferred preference before it is persisted. This creates a persistent-state trust problem: behavioral patterns observed during a session may be ambiguous, manipulated, or supplied by someone other than the intended workspace owner. Once recorded, the inferred state can continue affecting later sessions because `SKILL.md:46` directs the agent to read `USER.md` at session startup. `SKILL.md:48` separately states that implicit preferences must not be persisted without human consent. However, the shorter operational policy omits that restriction and directly pairs implicit learning with persistent storage. Agents using `POLICY.md` as the active or condensed policy may therefore persist inferred preferences without applying the safeguard in `SKILL.md`. The affected information is nominally limited to communication preferences, task preferences, project context, and session preferences. The package explicitly prohibits storing credentials and secrets. Nevertheless, task preferences can influence verification behavior, approval gates, error handling, and autonomy, making unverified persistent entries security-relevant. ### ...[truncated 1865 chars]
- Remediation
- ## Remediation Suggestions 1. Require explicit, informed confirmation before persisting every inferred preference. Observed patterns may be used provisionally within the current session but must not be written to durable storage automatically. 2. Revise `POLICY.md` to preserve the safeguard stated in `SKILL.md`, for example: ```markdown - Learn possible implicit preferences from patterns - Treat inferred preferences as session-local until confirmed - Persist an inferred preference only after showing it to the human and receiving explicit consent ``` 3. Never learn or persist security-sensitive preferences concerning authorization, approval gates, credential handling, destructive actions, public actions, access control, or the ability to bypass verification. 4. Store provenance with every entry, including whether it was explicitly stated or inferred, who confirmed it, the originating session, creation time, expiry time, and scope. 5. Treat loaded preference files as untrusted data. Validate entries against an allowlist of harmless preference types and ensure that preferences cannot override system instructions, safety controls, or explicit instructions in the current session. 6. Separate preferences from authorization. A stored preference such as “work autonomously” must never be interpreted as permission to perform destructive, irreversible, privileged, financial, or external actions. 7. Provide a review interface or readable pending section where inferred preferences remain inactive until the workspace owner approves them. 8. Apply expiry and revalidation consistently, and immediately remove or deactivate preferences when the user disputes them. 9. Align `POLICY.md`, `SKILL.md`, `README.md`, and `TEMPLATE.md` so every condensed policy communicates the same consent requirement.