Back to skill

Security audit

iwantfyi

Security checks for vulnerabilities and agentic risk

Overview

The skill is a disclosed shopping integration, but its seller-lead unlock flow could let an agent spend small amounts without explicit per-payment approval.

Use this only when you are comfortable sending shopping or seller-matching details to iwant.fyi. Do not include names, addresses, payment details, credentials, or unrelated conversation content. Require an explicit confirmation before registering an agent, saving standing wants, reporting outcomes, contacting sellers, and especially before every paid lead unlock, with the exact amount and payment rail shown first.

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (1)

T09 · Insecure Skill Coding Practices

Warning
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: Medium

Vulnerable 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_url and 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_url values, 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.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (3)

External Transmission

Medium
Category
Data Exfiltration
Confidence
88% confidence
Finding

This skill instructs the agent to transmit the user's shopping request, context identifier, agent identity, and optional agent card URL to an external service at iwant.fyi. Although this is the core purpose of the skill and the document includes some consent and minimization guidance, it still creates a real data-exfiltration surface because free-form user text may contain sensitive information and is sent off-platform to a third party.

Content

Scanner excerpt · SKILL.md (reported line 41)May include surrounding context.

params: { message: { role: "user", contextId: $ctx, metadata: { from: $from, agentCard: $card }, parts: [ { kind: "text", text: $text } ] } } }'
| curl -s -X POST https://iwant.fyi/api/a2a -H "Content-Type: application/json" --data-binary @-

text

`USER_REQUEST` is the want in the user's words, for example `used road bike, 56cm, good condition, under $900, ships to Denver`. `CONTEXT_ID` is one id per user request, reused for follow-ups.

Autonomous Decision Making

Medium
Category
Excessive Agency
Confidence
75% confidence
Finding

Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Content

Scanner excerpt · SKILL.md (reported line 60)May include surrounding context.

md
When the user wants one of those cars, ask them first, then call `demand.request_introduction` with that car's `listing_id`, the original `query`, and their question. We email the dealer with a reply address that belongs to the introduction; the dealer's answer comes back to us and never exposes your user. Poll `demand.introduction_status` with the returned `introduction_id` to read the reply.

Rules for this one: never send an introduction without asking the user, and never put their name, phone, email or address in the message. The question is about the car, not about them. A `status` of `needs_contact` means we do not have a verified address for that dealer yet; tell the user we are working on it and offer the listing link so they can call.

## Path B: keyed HTTP (structured)

External Transmission

Medium
Category
Data Exfiltration
Confidence
80% confidence
Finding

The registration flow sends agent name and description to an external endpoint to obtain an API key and establish a persistent identity. Even though the skill says to ask the user first and keep the key in an environment variable, this still introduces third-party account creation, secret issuance, and potential logging/identity-linkage risks if performed automatically or without clear consent.

Content

Scanner excerpt · SKILL.md (reported line 68)May include surrounding context.

bash
jq -n --arg name "$AGENT_NAME" --arg desc "$AGENT_DESCRIPTION" '{name: $name, description: $desc, source: "clawhub"}' \
| curl -s -X POST https://iwant.fyi/api/agents/register -H "Content-Type: application/json" --data-binary @-

If your user sells things

Static analysis

No suspicious patterns detected.