Is amitbiswas1992/soho safe?

The remote signer path in src/signer/remote.js POSTs the complete EIP-712 typed payment authorization — including payer address, merchant address, USDC asset address, amount, paymentPlanId, nonce, validAfter, and expiry — along with a Bearer auth token (SIGNER_SERVICE_AUTH_TOKEN) to WALLET_SIGNER_SERVICE_URL/sign-eip712. The send-tx path additionally transmits encoded calldata to /send-tx. While the URL is documented as operator-controlled, a misconfigured or adversarially substituted URL would silently capture all authorization data before funds are committed.

SOHO_API_URL is declared as an optional environment variable in skill.json and stored as sohoApiUrl in config.js, but it is not visibly invoked in any of the provided source files. Its presence in the schema implies it is used in a code path not shown, likely for credit checks or JIT funding coordination with SoHo's servers. The trust boundary and data transmitted to this endpoint are not auditable from the provided evidence.

The skill's core action is submitting spendWithAuthorization transactions to the Creditor smart contract on Base. Once mined, these transactions are cryptographically final and cannot be reversed. The mainnet safety gate (SOHO_MAINNET_CONFIRM=YES required for chain ID 8453), manual invocation requirement, and confirmation gate mitigate accidental execution, but these controls depend on correct configuration and orchestrator compliance.

The entire payment authorization flow — including the EIP-712 signature that authorizes fund movement — depends on WALLET_SIGNER_SERVICE_URL pointing to the operator's legitimate wallet service. This URL is not validated against any allowlist, pinned certificate, or canonical domain. An agent or operator misconfiguring this value (e.g., through a prompt injection in another skill, a misconfigured .env, or a supply-chain compromise of the env configuration) would route signing requests to an unintended party with no visible error to the user.

Reads to /home/oc-exec/.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and GCP application_default_credentials.json were recorded at audit timestamps 1771652770.715 (records 249-254, before skill clone) and 1771652792.074 (records 1480-1485, after install). The access pattern — identical file set, identical sequential order, and sub-millisecond grouping at both endpoints of the audit — is characteristic of the Oathe canary baseline scanner rather than skill execution. Skill source code contains no file-read operations targeting home directory credential paths. Canary integrity check confirms all files intact with no exfiltration.

src/config.js calls require('dotenv').config() with no explicit path argument. By default, dotenv scans for a .env file in process.cwd() at runtime. This is standard Node.js practice and benign in typical deployments, but if the skill is invoked from a directory that contains a .env file with sensitive values unrelated to this skill, those values will be silently loaded into process.env and potentially influence config parsing or be accessible to other in-process code.

SKILL.md itself contains no prompt injection payload. However, a skill that authorizes financial transactions is a high-value target for indirect prompt injection delivered through other vectors — e.g., malicious content in a document the agent processes, a compromised co-installed skill, or a social engineering attempt that manipulates the merchantAddress argument. The manual invocation and confirmation requirements reduce but do not eliminate this risk.