Is echennells/sparkbtcbot-proxy-deploy safe?

The skill instructs the agent to solicit the user's BIP39 mnemonic seed phrase (12-24 words), which confers total and irrevocable control over all funds in the Spark wallet. The agent is then directed to embed this value in a Vercel REST API call as a JSON body parameter. In a typical agentic workflow, tool inputs and outputs are logged, stored in conversation history, and sent to the LLM provider — any of these exposures permanently compromise the wallet with no recovery path.

The skill directs the agent to clone https://github.com/echennells/sparkbtcbot-proxy.git and run npm install. This repository is entirely separate from the audited skill package and was not inspected during this audit. A malicious or compromised postinstall script in that repository could read environment variables (including any already-collected mnemonic), spawn network connections to exfiltrate credentials, or install persistent malware. The Spark SDK and its transitive dependencies add additional unverified code surface.

The deployed proxy exposes POST /api/l402 which autonomously fetches URLs, parses 402 responses, pays Lightning invoices, and returns the protected content — all without additional user confirmation. An agent equipped with this skill and manipulated via prompt injection or confused by ambiguous user instructions could be directed to pay attacker-controlled L402 paywalls, resulting in immediate and unrecoverable Bitcoin loss. The skill's own documentation acknowledges that failed polling results in lost funds.

The one-liner provided for generating a new wallet mnemonic calls console.log(r.mnemonic), causing the 12-word seed phrase to appear in the command's standard output. When an agent executes this via a shell tool, the output becomes part of the tool result returned to the LLM, is stored in the agent's conversation context, and may be transmitted to the LLM API provider. This is avoidable — the mnemonic could be written directly to a file — but the SKILL.md specifically instructs this pattern.

The skill explicitly instructs the agent to ask the user for their Upstash account credentials and BIP39 mnemonic 'upfront' before proceeding. This positions the agent as an intermediary that collects and retransmits secrets of extraordinary sensitivity. While framed as legitimate deployment configuration, any agent operating under this skill becomes a credential handler for assets whose exposure leads to direct financial loss — a pattern that significantly elevates the impact of any secondary compromise (e.g., conversation log leak, LLM provider breach).

The API_AUTH_TOKEN environment variable is described as a 'hardcoded admin fallback' that grants full admin access 'even if Redis is down or tokens get wiped.' Unlike Redis-stored tokens which can be revoked, this token cannot be invalidated without redeployment. If an agent echoes this value in output, includes it in an error message, or stores it in an accessible location, any observer gains permanent admin-level access to wallet balance reads, invoice creation, Lightning payments, fund transfers, and token management.

The skill instructs the agent to deploy the cloned external repository to Vercel production using npx vercel --prod. If the echennells/sparkbtcbot-proxy repository contains malicious code or is compromised between clone and deploy, the resulting Vercel deployment is an attacker-controlled service that receives all wallet mnemonic and API credentials as environment variables and handles all financial transactions. The skill does not instruct the agent to review the cloned code before deploying.

The skill presents MAX_TRANSACTION_SATS and DAILY_BUDGET_SATS as security controls against overspending. However, these limits are enforced exclusively by the proxy server being deployed using code from the external repository. If that repository is malicious, the spending limits may be non-functional or bypassable, providing false assurance to users who believe they have capped their financial exposure.

Six honeypot credential files (.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, gcloud application_default_credentials.json) were opened and read during the monitoring period. The initial access cluster at 13:16:03 occurred before the git clone initiated at 13:16:08, and the second cluster at approximately 13:16:24 occurred after install completion — both timing patterns are consistent with the audit monitoring infrastructure performing baseline and post-install canary verification rather than skill-initiated access. No canary content was transmitted over any network interface; the integrity checker confirms all files remain intact.

The skill installation produced only the expected files (SKILL.md, _meta.json) in the designated skill directory. All observed network connections were consistent with the GitHub clone operation. No new listening services, unexpected processes, filesystem changes outside the skill directory, or persistent connections were introduced.