T09 · Insecure Skill Coding Practices
- Location
SKILL.md:78- Finding
Destructive desktop actions execute without mandatory user confirmation
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 78–83; corroborating behavior at lines 158–161
Vulnerability Type: Destructive action execution without a mandatory local confirmation gate
Risk Level: HighVulnerable Snippet
markdown **A step that is hard to undo is not taken quietly.** The same request asks how hard the step would be to reverse. An ordinary step needs 0.70 confidence in its target, one rated destructive needs 0.90, and below 0.55 nothing runs. When the bar is not met the run stops and names the candidate it would have acted on, so you decide instead of it. By default, a destructive step at target confidence 0.90 or higher runs. Pass `--confirm-destructive` to `run.mjs` or `act.mjs` to stop for confirmation on every step rated destructive, regardless of confidence.The documented risk policy further identifies relevant destructive actions:
markdown - **Risk sets the bar.** The answer says what; confidence says whether to act. An ordinary action needs 0.70. One that Jev rates `destructive` at 0.50 or more needs 0.90 — writing a file, deleting, sending, confirming a warning. Below 0.55 nothing acts at all.Technical Analysis
The Skill delegates desktop operation selection, target selection, confidence scoring, and destructive-risk assessment to a remote decision endpoint. Its default policy allows an action classified as destructive to execute automatically when the endpoint reports target confidence of at least
0.90.The only documented unconditional confirmation mechanism,
--confirm-destructive, is optional and is not enabled in the primary invocation examples. Confidence scoring is not an authorization control: it expresses the endpoint's assessment of its prediction but does not establish that the user approved a particular irreversible action.Consequently, the same remote decision component that proposes an operation can provide the values that allow it to pass the execution thres ...[truncated 1784 chars]
- Remediation
View remediation
Remediation Suggestions
- Make destructive-action confirmation mandatory by default in both
run.mjsand executableact.mjsflows. - Require a local, action-specific approval after displaying the exact application, operation, target, and expected consequence.
- Do not permit confidence or destructiveness values returned by the remote endpoint to bypass this approval.
- Issue a short-lived approval token bound to the exact operation, target, application window, and current screen state; reject execution if any value changes.
- Keep non-executing or dry-run behavior as the default for one-step resolution, and require an explicit execution flag in addition to destructive approval.
- Apply hard local prohibitions or additional confirmation for deletion, sending, file overwrite, warning acceptance, purchases, publication, and permission changes.
- Treat ambiguous risk classifications conservatively: if an operation may be destructive, require confirmation.
- Record the approved action and final delivery status in an audit log without storing sensitive screen or field contents unnecessarily.
- Make destructive-action confirmation mandatory by default in both
