Autonomous Wallet

• Outcome: Review
• Latest audit: Sep 11, 2026 · 9:01 PM UTC
• Version: 1.0.0

Overview

This wallet skill is coherent, but it needs Review because it directs users to give an unpinned global npm tool wallet secrets and authority to move real funds with limited safety boundaries.

Install only after reviewing the actual npm package source and release provenance. Use a disposable testnet wallet first, avoid pasting real mnemonics or private keys into commands or exported environment variables, prefer hardware-wallet or isolated signing flows, pin the package version, and require simulation plus explicit approval for any mainnet transfer, approval, staking, or recovery action.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (2)

T08 · Insecure Dependencies

Error

• Location: skill.md:24
• Finding: Unpinned Third-Party Package Is Entrusted with Wallet Secrets and Transaction Authority<![CDATA[ ## Vulnerability Details **File Location**: `skill.md:24-27`, with installation instructions at `skill.md:114-120` and `skill.md:125-130`; duplicated in `readme.md:43-49` **Vulnerability Type**: Unpinned, externally maintained security-critical dependency **Risk Level**: High ### Vulnerable Code ```yaml packages: - name: openclaw-autonomous-wallet source: npm version: ">=0.1.0" verified_repo: https://github.com/ZhenRobotics/openclaw-autonomous-wallet ``` The Skill then instructs users to install this package globally: ```bash # Install globally npm install -g openclaw-autonomous-wallet # Verify installation autonomous-wallet --version ``` The same unconstrained installation is repeated for ClawHub users: ```bash # Install skill clawhub install ZhenStaff/autonomous-wallet # Then install npm package npm install -g openclaw-autonomous-wallet ``` ### Technical Analysis The dependency declaration accepts every version at or above `0.1.0`. The installation command does not select an exact reviewed release or validate an integrity hash, package signature, or npm provenance record. A repository URL described as “verified” does not establish that the artifact downloaded from npm is built from that repository or corresponds to reviewed source code. This dependency is security-critical because the documentation subsequently gives its CLI access to private keys or mnemonic phrases and authorizes it to sign blockchain transactions. The audited project contains only documentation files and does not include the package implementation, lockfile, integrity metadata, or vendored source. Consequently, the dependency's handling of secrets, network communication, transaction construction, and key storage cannot be validated from this artifact. Global installation increases the exposure because package installation scripts and executables may run with the installing user's privileges and place commands in a shared executable path. ### Attack Path ...[truncated 1315 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin the dependency to an exact reviewed version rather than using `>=0.1.0`. 2. Record and verify the package archive's cryptographic integrity hash. 3. Require npm provenance or another verifiable signed build attestation and document how users must validate it. 4. Include a lockfile and the audited package implementation in the review scope, or vendor the reviewed source. 5. Prefer a project-local installation over global installation and invoke the pinned binary through a package runner configured not to download newer versions. 6. Disable or inspect package lifecycle scripts before installation, and perform initial evaluation inside a restricted container or disposable virtual machine. 7. Establish a release process that maps the source commit, generated package archive, integrity digest, and published npm version. 8. Require hardware-wallet signing or an isolated signing service so the dependency never receives raw private keys or seed phrases. 9. Apply transaction policy controls outside the package, including destination allowlists, token-approval limits, spending caps, chain verification, and explicit user confirmation. 10. Do not describe the dependency as “safe and verified” until the distributed artifact and relevant source have undergone an independent security audit. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: skill.md:139
• Finding: Private Keys and Mnemonic Phrases Are Passed Through Exposed Command-Line and Environment Interfaces<![CDATA[ ## Vulnerability Details **File Location**: `skill.md:139-145`, with additional examples at `skill.md:182-186` and `skill.md:252-256`; duplicated in `readme.md:55-59` and `readme.md:89-92` **Vulnerability Type**: Unsafe handling of wallet recovery secrets **Risk Level**: High ### Vulnerable Code The quick-start instructions pass a complete mnemonic through a command-line argument and place a private key in an exported environment variable: ```bash # Create new wallet autonomous-wallet init # Or import existing wallet autonomous-wallet import --mnemonic "your twelve word mnemonic phrase..." # Or use private key export PRIVATE_KEY="0x..." autonomous-wallet init --from-env ``` The command reference also documents direct command-line exposure of both secret types: ```bash # Initialize wallet autonomous-wallet init # Import wallet autonomous-wallet import --mnemonic "..." --private-key "0x..." ``` The configuration section recommends exported environment variables for long-lived recovery secrets: ```bash # Wallet Configuration export PRIVATE_KEY=0x... # private key export MNEMONIC="word1 word2..." # or mnemonic ``` ### Technical Analysis Command-line arguments containing private keys or mnemonic phrases can be retained in shell history, terminal logs, command auditing, support captures, or process metadata. Depending on the operating system and process isolation configuration, another local process or user may be able to observe command arguments while the command is executing. Exported environment variables are inherited by child processes. Wallet secrets can therefore become available to unrelated tools launched from the same shell, package lifecycle scripts, diagnostic utilities, crash handlers, test runners, or compromised dependencies. Environment values may also be included accidentally in debug logs and process snapshots. A mnemonic is a wallet root secret rather than a narrowly scoped credential. Exposure can compromise ...[truncated 1650 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove all examples that pass private keys or mnemonic phrases as command-line arguments. 2. Do not recommend exporting mnemonic phrases or raw private keys as environment variables. 3. Accept secrets through a hidden interactive prompt connected directly to a terminal, with echo disabled and no history retention. 4. Prefer hardware wallets, operating-system keychains, encrypted signing agents, or isolated key-management services that never expose raw recovery material to the CLI. 5. If noninteractive operation is unavoidable, use a restricted file descriptor, local IPC channel, or secret-manager integration with strict access controls and short-lived authorization. 6. Ensure secret files, if used, have owner-only permissions and are securely deleted when no longer required. Avoid predictable temporary paths. 7. Prevent secrets from appearing in logs, errors, telemetry, crash reports, transaction output, process titles, and configuration-display commands. 8. Minimize environment inheritance by launching wallet operations with an explicit sanitized environment. 9. Document shell-history cleanup only as defense in depth; it is not a substitute for eliminating command-line secret arguments. 10. Use separate, low-value wallets for autonomous agents and enforce external spending limits, destination allowlists, and transaction confirmation policies. 11. Provide a migration warning advising users who previously entered real mnemonics on the command line to treat exposed seeds as compromised and move assets to a newly generated wallet. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Rogue Agent: Self-Modification, Session Persistence
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (4)

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The README instructs users to import a wallet via a mnemonic on the command line and to perform autonomous blockchain actions, but it does not prominently warn that command-line secrets can be exposed via shell history, process listings, logs, or screenshots, nor that blockchain transfers are generally irreversible. In the context of an AI-agent wallet that can execute natural-language intents and move funds on mainnet, this omission materially increases the risk of credential compromise and unintended fund loss.

Session Persistence

Medium

• Category: Rogue Agent

Content

#### Step 1: Initialize Wallet

```bash
# Create new wallet
autonomous-wallet init

# Or import existing wallet

• Confidence: 84% confidence
• Finding: The skill instructs users to place highly sensitive secrets such as a private key and mnemonic into shell commands and environment variables, which may persist in shell history, process listings, terminal logs, agent traces, or session state. In an AI-agent setting, session persistence is especially risky because tools, logs, or orchestrators may retain these values beyond the intended runtime.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The documented execution examples perform real blockchain actions such as transfers, swaps, approvals, and staking without an adjacent warning that these operations can move irreversible real funds and may grant token spending rights. In an agent skill context, natural-language execution increases the chance of accidental or overly broad actions, especially if users treat the examples as harmless demos.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The social recovery commands describe initiating, approving, executing, and canceling recovery flows without warning that these actions can transfer wallet control, lock out the legitimate owner, or finalize ownership changes after a timelock. Because the skill is designed for autonomous agents and wallet management, presenting these commands as routine operations materially increases the risk of destructive misuse.

Static analysis

No suspicious patterns detected.