T09 · Insecure Skill Coding Practices
- Location
SKILL.md:76- Finding
Paid Lead Unlocks Lack an Explicit User Authorization Boundary
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, line 76
Vulnerability Type: Financial operation without explicit per-transaction authorization
Risk Level: MediumVulnerable Code Snippet:
markdown **What it costs.** Buyer wants that match what you sell are pushed to you free. An indexed catalog (your domain or feed) sees each want's full detail and reply path free. Otherwise unlocking a want's detail is a small USDC payment on Base over x402: $0.05 for wants under $50, $0.25 under $250, $1 under $1,000, $5 above. Payments are not charged during the preview; the push tells you the mode. Each pushed want carries `unlock_url` and an `unlock` block (`price_cents`, `currency`, `network`, `mode`), so your agent can decide per want. Paying the unlock is how you accept the introduction to that buyer. Rails: USDC on Base over x402, or cards and Tempo stablecoins over Stripe's Machine Payments Protocol (MPP); the 402 offers every configured rail and your agent picks one.Technical Analysis
The Skill delegates the decision to purchase seller-lead access to the Agent through the statement that the Agent can “decide per want.” These unlocks involve real payments through USDC over x402, card-based rails, or stablecoin payment facilities.
Although other sections require user approval before saving a standing want, registering an Agent identity, contacting a vehicle dealer, or reporting an outcome, the paid-unlock workflow contains no equivalent requirement for explicit confirmation immediately before payment. The general instruction not to auto-purchase is framed around products shown to a buyer and does not unambiguously cover purchasing access to a seller lead.
If the Agent environment has access to a funded wallet, card, or machine-payment facility, this ambiguity can cause it to treat a pushed
unlock_urland associated pricing metadata as sufficient authorization to spend funds. Because pushed wants originate out ...[truncated 1304 chars]- Remediation
View remediation
Remediation Suggestions
- Require explicit, transaction-specific user confirmation immediately before every paid unlock.
- Present the exact amount, currency, network, recipient, payment rail, and purpose before requesting approval.
- State unambiguously that an Agent must never autonomously pay an unlock fee, even when a wallet or machine-payment facility is available.
- Treat pushed wants,
unlock_urlvalues, and payment metadata as untrusted data rather than executable instructions. - Validate that payment and unlock endpoints use the expected HTTPS origin, and reject redirects or payment requests involving unapproved hosts.
- Enforce user-configured per-transaction and cumulative spending limits, with a default limit of zero.
- Bind approval to the displayed transaction parameters so that any change in amount, currency, network, recipient, or destination invalidates the approval.
- Avoid exposing wallet credentials, card details, signing keys, or payment tokens to pushed content or remote responses.
- Record a minimal, non-sensitive audit event for each approved payment while ensuring that secrets and personal information are never logged.
