T09 · Insecure Skill Coding Practices
- Location
SKILL.md:263- Finding
Declared Read-Only Boundary Permits High-Impact State-Changing Actions
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:263-267
Vulnerability Type: Contradictory authorization policy and excessive operational scope
Risk Level: MediumVulnerable Code
markdown ### 13. Stay read-only Do not purchase, add to cart, change account settings, log in, save payment details, send messages to sellers, or perform other state-changing actions unless the user explicitly requests and confirms that specific action. For any state-changing step, summarize what will change, where, risk, rollback if possible, and wait for explicit confirmation.The same inconsistency also appears in the non-negotiable policy at
SKILL.md:25:markdown | Read-only | No purchase/cart/login/payment/account actions without explicit confirmation. |Technical Analysis
The skill is presented as a read-only purchasing advisor, and
README.md:5states that it does not buy products, add items to a cart, or change accounts. However, the active instructions inSKILL.mddo not impose an unconditional read-only boundary. Instead, they authorize purchases, cart operations, login, payment-detail storage, account changes, seller messaging, and other state-changing actions after user confirmation.Confirmation is a useful safeguard for an intentionally transactional agent, but it does not enforce the advertised read-only design. These capabilities are unnecessary for product discovery, price comparison, seller-risk analysis, and recommendation generation. In a visible browser with an authenticated marketplace profile, the policy may therefore allow the agent to exercise account and commerce privileges beyond the skill's stated purpose.
The issue is especially significant for payment-detail storage and account-setting changes. These operations can affect sensitive account state and create consequences that extend beyond the current comparison task. The broad phrase “other state-changing actions” also leav ...[truncated 1728 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace the conditional restriction with an unconditional read-only policy. Explicitly prohibit purchases, checkout, cart modification, login, payment handling, account changes, seller messaging, and all other state-changing operations.
- Remove language stating that confirmation makes these actions permissible. The skill should instead explain that the requested action is outside its scope and provide non-interactive guidance when appropriate.
- Align
SKILL.md,README.md, design notes, and metadata so they describe the same security boundary. - Restrict browser use to navigation, filtering, and extraction operations. Do not submit forms, click purchase or cart controls, upload data, or change profile state.
- Avoid relying on authenticated browser sessions where public product information is sufficient. If authenticated browsing is necessary for regional prices, instruct the agent to avoid exposing or modifying account and payment data.
- Add a final compliance check that fails the task before any state-changing browser operation rather than merely requesting confirmation.
- If transactional functionality is intentionally required in the future, implement it as a separate, explicitly named skill with narrowly scoped permissions, transaction previews, amount and merchant verification, independent confirmation, and clear rollback or cancellation guidance.
A hardened replacement could state:
markdown ### 13. Stay strictly read-only Never purchase, check out, add to or modify a cart, log in, save or change payment details, change account settings, send messages, submit forms, or perform any other state-changing action. User confirmation does not override this restriction. If requested, explain that the action is outside this skill's scope and provide read-only guidance.