T09 · Insecure Skill Coding Practices
Error
- Location
- failure-taxonomy.md:18
- Finding
- Agent-Directed Purchases Without Explicit Operator Authorization<![CDATA[ ## Vulnerability Details **File Location**: `failure-taxonomy.md:18`, `failure-taxonomy.md:35`, `failure-taxonomy.md:46`, `failure-taxonomy.md:57`, `failure-taxonomy.md:91`, and `trust-safety.md:74-76` **Vulnerability Type**: Financial action performed without mandatory human approval **Risk Level**: High ### Vulnerable Content From `failure-taxonomy.md`: ```markdown | 402 | `credits_exhausted` | Not enough credits | Purchase credits using `credit_pack_options` from the error response, then retry with new key | ``` ```markdown | 429 | `prepurchase_daily_limit_exceeded` | Pre-purchase limits active | Make any purchase (subscription or credit pack) to permanently remove these limits. `purchase_options` is included in the response. | ``` ```markdown ├─ Is it 402? │ └─ YES → Read credit_pack_options from error. Purchase credits. Retry. ``` ```markdown └─ Is it 429? └─ prepurchase_daily_limit_exceeded → Purchase something, retry ``` ```markdown If balance < 50 credits and you have more work to do, purchase proactively rather than hitting 402 mid-workflow. ``` From `trust-safety.md`: ```markdown These exist to let you evaluate Fabric with signup credits. **Any purchase** (subscription or credit pack) permanently removes them. When you hit `429 prepurchase_daily_limit_exceeded`, the response includes `purchase_options` with ready-to-use payloads for both subscription and credit pack purchases. ``` ### Technical Analysis The skill directs an agent to purchase credits or subscriptions in response to API errors and low-balance conditions. It does not require explicit operator confirmation, impose a transaction limit, distinguish one-time purchases from recurring subscriptions, or require independent verification of the amount and payment destination. The guidance also encourages using purchase options and ready-to-use payloads supplied by the remote API. A compromised service, malicious intermediary, or incorrectly trusted endpoint could influe ...[truncated 1596 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Require explicit, transaction-specific operator approval before every purchase or subscription. 2. Display the product, amount, currency, payment provider, recurrence terms, taxes, and total charge before approval. 3. Never execute a purchase request body directly from an API error response. 4. Validate that purchase endpoints use an allowlisted HTTPS origin and expected API path. 5. Independently validate product identifiers and prices against trusted configuration. 6. Enforce per-transaction, daily, and cumulative spending limits. 7. Disable recurring subscriptions by default and require separate confirmation for recurring billing. 8. Treat insufficient credits as a stop condition when human approval is unavailable. 9. Record an auditable transaction log containing the approving operator, selected product, amount, and response. 10. Replace autonomous language such as “Purchase something” with “Ask the operator whether to purchase; do not proceed without explicit approval.” ]]>