T05 · Unauthorized Access and Privilege Escalation
Warning
- Location
- SKILL.md:285
- Finding
- Default Read-Only Tier Exposes State-Changing Tools and Excessive Sensitive-Data Access## Vulnerability Details **File Location**: `SKILL.md`, lines 21, 102, 274, 285–287, 362, and 369 **Vulnerability Type**: Least-privilege violation and inconsistent authorization boundary **Risk Level**: Medium The skill describes the default `MESSAGES` tier as read-only, but its documented heartbeat tool set includes capabilities that can create todos, create notes, and modify durable memory. The documentation does not state that these tools are restricted to the `ACTIONS` tier. ### Vulnerable Code Snippets `SKILL.md`, line 21: ```markdown | Tier | `MESSAGES` (default) = read-only checks + summary. `ACTIONS` = can take write actions (future). | ``` `SKILL.md`, line 102: ```markdown - `MESSAGES` — read-only checks, delivers summary message (default) ``` `SKILL.md`, line 274: ```markdown 3. **Memory context**: loads user's long-term memory for personalization ``` `SKILL.md`, lines 285–287: ```markdown - `search_todos` / `create_todo` — task management - `search_notes` / `create_note` — workspace notes - `memory_write` — save durable facts (rate-limited: 1 write per 60min, max 4 daily entries) ``` `SKILL.md`, line 362: ```markdown - **context-sync**: Heartbeat's `memory_write` tool keeps long-term memory updated ``` `SKILL.md`, line 369: ```markdown - Heartbeat excluded tools prevent unintended write actions in MESSAGES tier ``` ### Technical Analysis A read-only authorization tier should expose only operations that cannot modify user or system state. However, the documented tool set includes `create_todo`, `create_note`, and `memory_write`, all of which perform persistent writes. The claim that only “write-heavy” tools are excluded does not establish a reliable authorization boundary. No documented server-side or tool-dispatch restriction ensures that these three write operations are unavailable under `MESSAGES`. Rate limiting `memory_write` reduces frequency but does not make th ...[truncated 2132 chars]
- Remediation
- ## Remediation Suggestions 1. Implement a server-side, deny-by-default tool allowlist for each policy tier. Under `MESSAGES`, expose only explicitly approved search and read operations. 2. Remove `create_todo`, `create_note`, and `memory_write` from the `MESSAGES` tool registry. Do not rely solely on prompt instructions to prevent their use. 3. Permit persistent writes only under `ACTIONS`, after explicit user opt-in. For sensitive or externally visible changes, require per-action confirmation. 4. Validate the active tier again at the tool-execution boundary so that a model-generated call cannot bypass policy checks. 5. Treat email, notes, memory, and other retrieved content as untrusted data. Clearly separate retrieved content from system instructions and reject embedded requests to invoke tools or alter policy. 6. Apply minimum necessary data scopes, such as limited time windows, result counts, and selected mailboxes or folders. 7. Record the tier, requested tool, authorization decision, sanitized arguments, and result for every tool call. Surface denied write attempts in run details. 8. Provide a review and rollback mechanism for todos, notes, and memory entries created by autonomous runs. 9. Add automated authorization tests proving that every state-changing tool is rejected while the active tier is `MESSAGES`. 10. Update `SKILL.md` so its tier descriptions and security claims exactly match the enforced implementation.