T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:49
- Finding
- Unconsented Duplication of Sensitive Health Data in Persistent Agent Memory<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, line 49 **Vulnerability Type**: Sensitive data persistence without explicit consent or defined retention controls **Risk Level**: Medium ### Vulnerable Code Snippet ```markdown 1. **Data source first:** Always read `profile.json` at the start of every conversation. If missing, guide the user through initial setup. Also persist key parameters to MEMORY.md for cross-session continuity (profile.json remains the authoritative source). ``` The affected profile may contain sensitive physiological and health-related information, as demonstrated by `references/profile_schema.md`: ```json { "weight_kg": 65, "rest_hr": 50, "max_hr": 190, "lactate_threshold": { "hr": 175, "pace": "4:15", "power": 320 }, "history": { "injuries": [], "training_years": 3, "weekly_mileage_base": 50 } } ``` ### Technical Analysis The Skill requires key profile parameters to be copied into `MEMORY.md` for cross-session continuity. The phrase “key parameters” is not defined by an allowlist, so it may include heart-rate measurements, weight, lactate-threshold information, injury history, performance records, or race plans. This persistence is separate from the declared authoritative data store, `~/.workbuddy/running-coach/profile.json`. Consequently, the same sensitive information may exist in multiple locations with different access, retention, and deletion behavior. Although the Skill requires opt-in before writing to a training-log system, no equivalent consent requirement applies to `MEMORY.md`. It also provides no mechanism to: - Show the user which fields will be retained. - Exclude health-related fields from memory. - Define a retention period. - Revoke consent for memory persistence. - Delete previously retained information. - Keep deletion of `profile.json` synchronized with deletion from memory. This is an insecure data-handling practice rather than evidence of malicious memory poisoning: ...[truncated 1839 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove the automatic `MEMORY.md` write and use `profile.json` as the sole authoritative source. 2. If cross-session memory is required, obtain explicit and separate opt-in consent before the first memory write. 3. Define a strict allowlist of non-sensitive fields that may be retained. Exclude weight, heart-rate values, lactate threshold, injury history, and other health-related data by default. 4. Display the exact fields, storage destination, purpose, and retention period before requesting consent. 5. Add user controls to inspect, update, revoke, and permanently delete retained memory. 6. Ensure deletion or modification of `profile.json` is propagated to any duplicated memory records. 7. Store only the minimum information necessary for continuity, such as a non-sensitive profile-presence flag rather than profile values. 8. Update the privacy documentation to distinguish local profile storage, persistent agent memory, and optional writes to externally configured training-log systems. 9. Add a rule prohibiting secrets, credentials, access tokens, health records, and free-form user content from being written to persistent memory. ]]>