T09 · Insecure Skill Coding Practices
- Location
src/runtime.ts:79- Finding
Unrestricted outbound requests enable server-side request forgery and automatic payment abuse
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is openly a blockchain payment tool, but it can spend or lock funds and call arbitrary external URLs without enforceable approval controls.
Review before installing. Use only test wallets or tightly limited wallets, configure spending caps outside the agent, avoid production private keys, restrict allowed service endpoints, and require a separate human approval workflow before payments, subscriptions, escrow creation, wallet funding, spending-limit changes, or agent authorization.
src/runtime.ts:79Unrestricted outbound requests enable server-side request forgery and automatic payment abuse
src/runtime.ts:484Financially sensitive tools execute without enforceable user approval or mandatory transaction limits
package.json:27Stale lockfile and npx-based execution make the private-key-bearing runtime non-reproducible
The declared description presents a blockchain payment and subscription skill with wallet and escrow capabilities. However, the supplied code chunk is solely a packaging/build configuration file for tsup. It specifies bundling settings and an external dependency but contains no operational logic related to blockchain payments, x402, Monad, wallet management, subscriptions, or escrow. This is a material mismatch in primary purpose and implemented capabilities.
The declared description is about runtime AgentXPay functionality on Monad/x402: discovering services, making payments, managing wallets, subscriptions, and escrow. The supplied code does none of that. It is only build tooling configuration for tsup, specifying how to bundle the package and which dependencies to inline or externalize. While such tooling may support the overall project, this chunk’s primary purpose is materially different from the declared skill behavior, so this is a clear description-behavior mismatch.
The recommended smart-call flow permits activation from generic task descriptions and then autonomously discovers, selects, pays for, and calls an external service. This is a strong prompt-to-payment risk: a normal user request could trigger external transmission of task data and on-chain spending without a discrete approval step, which is particularly sensitive given wallet management and automated retry/payment behavior.
The manifest describes autonomous blockchain payment, wallet management, subscriptions, and escrow, but does not warn that the skill can initiate actions affecting user funds. In this context, missing a prominent risk disclosure is dangerous because integrators may install or auto-enable the skill without appreciating the financial consequences.
The pay action constructs calldata and executes an on-chain payment through the managed wallet, causing irreversible value transfer with no user-facing confirmation at the point of spend. Even with checks for authorization, balance, and allowance, an agent or upstream prompt flow could still trigger unintended payments to services within those constraints.
Creating escrow locks user funds until release or expiry, and this function executes the escrow transaction directly based on caller-supplied parameters. Because funds become unavailable and recovery may depend on contract logic or deadlines, silent escrow creation carries a high risk of financial loss or operational lockup if triggered unintentionally.
The README advertises autonomous on-chain payment, wallet management, subscriptions, and escrow operations without any visible warning, confirmation requirement, spending limits, or explanation of financial risk. In an agent skill, this is dangerous because integrators may enable capabilities that let an LLM initiate irreversible blockchain transactions or recurring payments with real funds based only on model decisions or prompt-triggered workflows.
The README explicitly promotes autonomous service discovery, on-chain payments, wallet management, and subscriptions, but provides no warning about irreversible financial actions, private key or wallet-risk considerations, or the need for explicit user authorization. In an agent context, this increases the chance that downstream integrators enable spending or subscription behavior without adequate consent, limits, or human review, which can lead to unintended asset loss.
The tool descriptions for auto-pay service calls and smart-call behavior imply that the agent may discover external services, send requests to them, and trigger blockchain payments automatically, yet there is no warning about data exfiltration, third-party trust, or paid network side effects. This is dangerous because users or integrators may treat the tool as a normal API helper while it can both disclose prompts/data to external endpoints and spend funds in a single automated flow.
The skill declares powerful capabilities involving environment variables and network access, including use of a blockchain private key, but does not restrict tool scope with explicit permissions or allowed-tools. In this context, missing scope boundaries increases the chance that the agent can invoke sensitive payment or network behaviors more broadly than intended, especially because the skill is user-invocable and designed to spend funds.
The tool examples use broad natural-language triggers for actions that may lead to network access and potentially paid service selection. Because the skill is user-invocable and intended for autonomous service discovery, vague activation phrases can cause the agent to invoke capabilities without clear user consent, increasing the risk of unintended spending or data disclosure to external endpoints.
The paid-call workflow can be activated by generic user requests like 'help me call this AI API,' yet it performs automatic 402 payment and retries against a remote endpoint. In this skill context, that is especially dangerous because it combines autonomous network calls, handling of payment metadata from the remote service, and direct fund expenditure using PRIVATE_KEY, making prompt-triggered unintended purchases plausible.
Referencing execution via 'npx tsx' without a pinned version creates a supply-chain risk because the resolved package version may change over time or be influenced by the environment. In a payment-oriented skill that can access PRIVATE_KEY and make on-chain transactions, even a small dependency substitution could lead to credential theft or unauthorized transactions.
The description advertises broad autonomous payment capability for AI agents without narrowing triggers, authorization boundaries, or operator expectations. For a wallet/payment skill, overly broad activation language increases the chance that hosts or users enable high-risk financial actions more permissively than intended.
The script invokes npx tsx, which can resolve and fetch an executable at run time instead of using a fully pinned local binary. In a security-sensitive payment skill, this weakens build/runtime supply-chain integrity because a different tsx version could be executed than the one reviewed.
The documentation promotes client.fetch(..., { autoPayment: true }) for handling HTTP 402 responses automatically, but it does not prominently warn that this can spend on-chain funds and transmit request data to third-party services. In an agentic context, this creates a real risk of unintended micropayments, repeated charges, or data disclosure if the endpoint is malicious, misconfigured, or called without explicit operator approval.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
client.fetch(url, options) — x402 自动付费请求const response = await client.fetch("https://ai-service.com/api/chat", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ prompt: "Hello" }),
The API reference lists many value-transferring methods such as payPerUse, deposit, withdraw, subscribe, escrow actions, and wallet execute without user-facing warnings about irreversibility, authorization sensitivity, or financial risk. In a skill meant for autonomous agents, understated documentation can lead integrators to expose dangerous operations without proper policy controls, resulting in fund loss or abuse.
The document explicitly describes an agent automatically reacting to HTTP 402 responses by submitting an on-chain payment and retrying the request, but it provides no requirement for user approval, spending limits, payee allowlisting, or human-visible warnings. In the context of an agent payment skill, this omission is dangerous because a malicious or compromised service could induce repeated or inflated payments, or redirect agents to pay attacker-controlled addresses, leading to direct fund loss.
The shebang uses env npx tsx, which can fetch and execute whatever tsx version is resolved at runtime instead of a pinned, reviewed dependency. In a payment and wallet-management skill, that creates a supply-chain risk where a compromised package, unexpected version drift, or hostile registry resolution could execute arbitrary code with access to PRIVATE_KEY and blockchain transaction capabilities.
The usage example instructs operators to run npx tsx, reinforcing an execution pattern that may resolve an unpinned tool version at runtime. While this line is documentation rather than executable logic, it still increases the chance that users will run a mutable external package in an environment holding wallet secrets.
This usage example promotes npx tsx for a tool that can trigger payment and service calls. If npx resolves a malicious or unexpected tsx, arbitrary code could run before the script, exposing environment variables and transaction authority.
The example continues to encourage runtime package resolution through npx tsx. In this skill, the context is more sensitive than a normal CLI because the process consumes RPC endpoints, private keys, and contract addresses for on-chain payments.
This documentation line teaches operators to invoke the wallet-management command via unpinned npx tsx. Because the command manages wallets and authorization, any supply-chain compromise in the transient runner could directly affect funds and wallet control.
This example also relies on npx tsx for a wallet authorization flow. Even though it is only sample text, it normalizes a risky operational pattern in a high-value blockchain context where compromise could expose signing keys or alter transaction behavior.
No suspicious patterns detected.