T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:145
- Finding
- Overbroad Plaintext Capture of Conversation and Personal Data<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 145-208 **Vulnerability Type**: Unrestricted plaintext persistence of conversation data **Risk Level**: Medium ### Technical Analysis The WAL protocol requires the agent to persist broad classes of user input before responding, including names, companies, dates, IDs, URLs, and preferences: ```markdown **The Law:** You are a stateful operator. Chat history is a BUFFER, not storage. `SESSION-STATE.md` is your "RAM" — the ONLY place specific details are safe. ### Trigger — SCAN EVERY MESSAGE FOR: - ✏️ **Corrections** — "It's X, not Y" / "Actually..." / "No, I meant..." - 📍 **Proper nouns** — Names, places, companies, products - 🎨 **Preferences** — Colors, styles, approaches, "I like/don't like" - 📋 **Decisions** — "Let's do X" / "Go with Y" / "Use Z" - 📝 **Draft changes** — Edits to something we're working on - 🔢 **Specific values** — Numbers, dates, IDs, URLs ### The Protocol **If ANY of these appear:** 1. **STOP** — Do not start composing your response 2. **WRITE** — Update SESSION-STATE.md with the detail 3. **THEN** — Respond to your human ``` The working-buffer protocol further requires wholesale logging after the context reaches 60%: ```markdown 1. **At 60% context** (check via `session_status`): CLEAR the old buffer, start fresh 2. **Every message after 60%**: Append both human's message AND your response summary 3. **After compaction**: Read the buffer FIRST, extract important context 4. **Leave buffer as-is** until next 60% threshold ``` ```markdown **The rule:** Once context hits 60%, EVERY exchange gets logged. No exceptions. ``` Related templates explicitly solicit and retain personal goals, important dates, projects, and relationship profiles in `assets/USER.md` and `assets/MEMORY.md`. No data-classification step, secret redaction, retention limit, encryption requirement, per-field consent, or file-permission requirement is applied to these memory files. Persistenc ...[truncated 1689 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions - Replace unconditional WAL capture with an allowlisted schema limited to task state that is necessary for continuity. - Never persist passwords, API keys, session tokens, authentication headers, private keys, one-time codes, payment information, or signed URLs. - Add secret and sensitive-data redaction before every memory write. - Remove the “EVERY exchange” requirement; store concise, user-approved summaries instead. - Ask for explicit consent before retaining personal relationships, important dates, health data, financial data, or third-party information. - Add commands to inspect, edit, export, disable, and delete retained memory. - Define retention periods and automatically purge stale working buffers and daily notes. - Require restrictive permissions for memory directories and files, such as a user-only directory mode and user-only file access. - Document whether memory files are indexed, synchronized, backed up, or supplied to external model providers. - Keep task state separate from long-term personal profiling so users can enable continuity without enabling personal-data collection. ]]>
