T09 · Insecure Skill Coding Practices
- Location
references/capabilities.md:84- Finding
Destructive MCP operations lack an enforced approval gate
- Content
View full analysis
Vulnerability Details
File Location:
references/capabilities.md:84-89
Vulnerability Type: Missing authorization and confirmation enforcement for destructive operations
Risk Level: HighRelevant snippet:
markdown | `purge_queue(vhost, name)` | **high** | message count about to be destroyed | none — messages unrecoverable | | `delete_queue(vhost, name)` | **high** | full queue definition + message count | re-declare the captured definition (**messages NOT restored**) | Every write takes `dry_run` (MCP) / `--dry-run` + double-confirm (CLI); the two high-risk writes (`purge_queue`, `delete_queue`) are gated by that same dry-run preview + double confirmation at the CLI, nothing more.Corroborating instructions state:
SKILL.md:215-218: the tool does not decide whether a write is permitted and has no read-only switch, policy file, or approval gate.SKILL.md:228-229: dry-run is supported, but double confirmation applies only at the CLI.references/agent-guardrails.md:13-25: authorization is delegated to the agent or broker account rather than enforced by the tool.
Technical Analysis
The MCP interface exposes irreversible
purge_queueand destructivedelete_queueoperations. Although these operations accept adry_runparameter, the reviewed instructions do not require a successful preview before execution. The double-confirmation control is explicitly limited to the CLI.Consequently, an MCP caller can invoke either operation in execution mode without presenting an approval token, completing an interactive confirmation, or passing a server-enforced policy check. Audit logging and risk labels provide accountability but do not prevent an unauthorized or mistaken operation. The runaway guard also does not address a single destructive call.
This is especially significant because
purge_queuehas no undo mechanism. Fordelete_queue, the recorded inverse can recreate only the que ...[truncated 1305 chars]- Remediation
View remediation
Remediation Suggestions
- Enforce authorization in the MCP implementation rather than relying on agent instructions.
- Default every state-changing MCP operation to dry-run and reject omitted or ambiguous execution intent.
- Require a two-stage workflow:
- Generate a preview containing the exact target, operation, and captured prior-state digest.
- Return a short-lived, single-use confirmation token bound to that preview.
- Require the token in a separate execution call and reject it if the target, parameters, state, or expiry differs.
- Add a server-enforced read-only mode and allow administrators to disable destructive tools independently.
- Require explicit approval metadata for high-risk operations and validate it as an authorization condition rather than merely recording optional annotations.
- Continue broker-side least privilege by using monitoring-only RabbitMQ accounts by default and granting purge/delete permissions only for narrowly scoped maintenance sessions.
- Retain audit logging and runaway protection as defense-in-depth controls, but do not treat either as a substitute for authorization.
