Back to skill

Security audit

AgentWallet

Security checks for vulnerabilities and agentic risk

Overview

The skill is purpose-aligned for crypto wallet automation, but it gives agents high-impact signing and transfer authority without enough user-confirmation and supply-chain safeguards.

Review this before installing in any environment with real funds. Only use it with explicit per-transaction user approval, verify every recipient and amount independently, avoid blind signing, keep token lifetimes short, lock the session after use, and prefer a pinned or verified package release.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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
Findings (2)

T08 · Insecure Dependencies

Error
Location
SKILL.md:12
Finding
Unpinned npm Package Installation Permits Supply-Chain Drift## Vulnerability Details **File Location**: `SKILL.md`, lines 12-19 **Vulnerability Type**: Unpinned third-party dependency **Risk Level**: High ### Vulnerable Code ```json "install": [ { "id": "agentwallet", "kind": "node", "package": "agentwallet", "bins": ["agentwallet"], "label": "Install agentwallet (npm)" } ] ``` ### Technical Analysis The skill installs the `agentwallet` npm package without specifying an exact version or integrity hash. Consequently, the code installed at deployment time can differ from the code that was reviewed. This is especially sensitive because the package is intended to manage cryptocurrency wallets, unlock a secret vault, receive session tokens, and sign or broadcast transactions. A compromised npm release, package-maintainer account, or registry response could therefore introduce malicious behavior without requiring any modification to `SKILL.md`. The repository metadata does not bind the npm installation to a reviewed commit, release artifact, or cryptographic digest. Merely identifying a source repository is not equivalent to verifying that the installed registry artifact was built from that source. ### Attack Path 1. An attacker compromises the npm package, its publisher account, or its release pipeline. 2. The attacker publishes a malicious version under the existing `agentwallet` package name. 3. A new environment processes the skill installation declaration and resolves the package without a version constraint. 4. npm installs the attacker-controlled release and exposes its `agentwallet` executable as a trusted local command. 5. When the agent invokes wallet operations, the malicious executable can capture passwords or session tokens, alter recipient addresses, forge displayed results, or submit unauthorized transactions. 6. Because the binary is expected to handle wallet secrets and signed transactions, its output may appear legitimate to t ...[truncated 537 chars]
Remediation
## Remediation Suggestions - Pin the dependency to a specific reviewed version rather than using the floating package name. - Enforce npm lockfile integrity data or verify the downloaded artifact against an independently maintained SHA-256 digest. - Prefer installation from a signed release artifact or an immutable source commit. - Verify npm package provenance and require signed, reproducible releases in CI. - Run the wallet CLI under a dedicated, least-privileged account with restricted filesystem and network access. - Treat every version update as a security-sensitive change and repeat source and artifact review before deployment. - Confirm that the declared repository and published npm artifact correspond to one another.

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:83
Finding
Wallet Session Tokens Are Passed Through Command-Line Arguments## Vulnerability Details **File Location**: `SKILL.md`, lines 83-88; additional instances at lines 113-114, 123-124, and 131-132 **Vulnerability Type**: Sensitive credential exposure through process arguments **Risk Level**: Medium ### Vulnerable Code ```bash # Create a wallet on a specific chain agentwallet create --chain ethereum --token <token> --json # Create wallets on all 12 chains at once agentwallet create --chain all --token <token> --json ``` The same pattern is prescribed for other sensitive operations: ```bash agentwallet transfer -f <from_address> -t <to_address> -a <amount> --token <token> --json ``` ```bash echo '{"walletAddress":"0x...","transaction":{"chainType":"evm","chainId":"ethereum","to":"0x...","value":"0.01"}}' | agentwallet sign --token <token> --json ``` ```bash echo '{"network":"base","token":"native","amount":"0.001","recipient":"0x..."}' | agentwallet x402-sign --wallet <address> --token <token> --json ``` ### Technical Analysis The documentation instructs agents to place the vault session token directly in the command line through `--token`. Process arguments can be exposed through process inspection facilities, diagnostic tooling, shell tracing, orchestration telemetry, audit logs, command-history capture, and error-reporting systems. The security rule at line 139 explicitly reinforces this pattern by stating that `--token` should always be used. Although the file also documents `AGENTWALLET_TOKEN`, exporting a secret into an environment variable can still expose it to child processes or environment-capturing diagnostics. Neither mechanism is as robust as passing the credential through a protected file descriptor or local authenticated IPC channel. The token has a default one-hour lifetime and may be configured for longer periods. Until expiration or explicit locking, theft of the token may allow an attacker to invoke a ...[truncated 1600 chars]
Remediation
## Remediation Suggestions - Do not place bearer tokens in command-line arguments. - Add support for reading the token from a protected file descriptor or standard input, such as `--token-stdin`. - Alternatively, use a root/user-restricted Unix-domain socket with peer credential verification so the CLI can communicate with the vault without exposing a reusable token. - If a credential file is unavoidable, create it with mode `0600`, avoid shared temporary directories, and delete it immediately after use. - Avoid shell tracing and redact tokens from logs, telemetry, crash reports, and error messages. - Use the shortest practical session TTL and lock the session immediately after each sensitive operation. - Scope tokens to particular wallets, chains, operations, transaction limits, and recipient allowlists where possible. - Rotate or revoke a session immediately if its command line may have been recorded. - Update the security rules and all examples so they no longer recommend `--token <token>`.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (2)

Missing User Warnings

Medium
Confidence
91% confidence
Finding
The skill provides direct token transfer instructions but does not require or even recommend explicit user confirmation, destination verification, amount sanity checks, or dry-run review before moving funds. In a wallet skill used by autonomous or semi-autonomous agents, this omission materially increases the risk of accidental or prompt-induced unauthorized transfers, making the operational context more dangerous than a typical read-only utility.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The skill exposes generic transaction and x402 signing flows without warning that agents must never sign untrusted or opaque payloads. Signing is equivalent to authorizing value movement or privileged blockchain actions, so in an agent setting this can be exploited through prompt injection, malicious API responses, or attacker-supplied transaction JSON to drain funds or grant approvals.

Static analysis

No suspicious patterns detected.