Alkahest User

• Outcome: Review
• Latest audit: Sep 12, 2026 · 12:25 AM UTC
• Version: 1.0.0

Overview

This skill is coherent for blockchain escrow work, but it asks users to handle wallet secrets and real asset transfers in ways that need careful review before use.

Review this skill carefully before installing. Use a hardware wallet or external signer where possible, avoid putting private keys or mnemonics in prompts, shell commands, source files, shell history, or long-lived environment variables, and test first with low-value testnet wallets. Before any transaction, independently verify the chain, contract address, token, amount, recipient or payee, arbiter, demand data, expiration, and approval scope. Prefer a pinned, locally installed, provenance-verified CLI rather than an unpinned global npm install.

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 (3)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:30
• Finding: Unpinned Third-Party CLI Installed Globally<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, line 30 **Vulnerability Type**: Unpinned global dependency installation **Risk Level**: Medium ### Vulnerable Code ```bash Install globally via `npm install -g alkahest-cli`, then run commands with: ``` ### Technical Analysis The Skill directs users to install `alkahest-cli` globally without specifying an exact version, package integrity hash, lockfile, or verified source repository. Consequently, the package version installed at execution time may differ from the version reviewed or expected by the Skill author. The package is especially sensitive because it receives wallet private keys and mnemonics and submits financial transactions. Its implementation is not included in this project, so its installation scripts, secret-handling behavior, and transaction construction cannot be audited from the supplied files. A global installation also increases exposure because package executables become available across the user's environment. No evidence establishes that the current package is malicious. The vulnerability is the absence of dependency pinning and provenance controls. ### Attack Path 1. An attacker compromises the npm package, a maintainer account, or the package publication process. 2. The attacker publishes a malicious version under the same package name. 3. A user follows the Skill and runs `npm install -g alkahest-cli`. 4. npm retrieves the current release rather than a previously audited version. 5. Malicious lifecycle or runtime code executes under the user's account. 6. When the user supplies a wallet key or mnemonic, the compromised CLI may capture it, alter transaction parameters, or submit unauthorized transactions. ### Impact Assessment A compromised package would execute with the permissions of the installing user. It could access user-readable files, intercept wallet credentials supplied to the CLI, modify transaction recipients or contract addresses, and potentially c ...[truncated 179 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Pin the CLI to an exact, audited version, such as `alkahest-cli@X.Y.Z`. - Publish and verify package integrity information before installation. - Link to the authoritative source repository and document how users can verify npm package provenance. - Prefer a project-local installation governed by a committed lockfile instead of a global installation. - Disable npm lifecycle scripts during installation where compatible with the package. - Document a controlled upgrade and security-review process for new versions. - Recommend testing new releases with testnet wallets that do not hold valuable assets. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:38
• Finding: Wallet Private Keys and Mnemonics Accepted Through Command-Line Arguments<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 38–47; representative transaction usage at lines 88–96 **Vulnerability Type**: Plaintext wallet secrets in command-line arguments **Risk Level**: High ### Vulnerable Code ```markdown Provide a wallet via one of (in priority order): | Method | Flag / Env Var | |--------|---------------| | Private key flag | `--private-key 0x...` | | Mnemonic flag | `--mnemonic "word1 word2 ..."` | | Ledger USB | `--ledger [--ledger-path <path>]` | | Private key env | `ALKAHEST_PRIVATE_KEY=0x...` | | Mnemonic env | `ALKAHEST_MNEMONIC="word1 word2 ..."` | | Compat env | `PRIVATE_KEY=0x...` | ``` The private-key flag is then used throughout the documented workflows, including: ```bash # ERC20 escrow with auto-approve alkahest --private-key 0xKEY escrow create \ --erc20 \ --token 0xTOKEN_ADDRESS \ --amount 1000000000000000000 \ --arbiter 0xARBITER_ADDRESS \ --demand 0xENCODED_DEMAND \ --expiration 1735689600 \ --approve ``` ### Technical Analysis Command-line arguments are not an appropriate transport for wallet private keys or mnemonic phrases. Depending on the operating system and execution environment, arguments may be exposed through: - Shell history files - Process inspection facilities - Terminal session recording - CI/CD logs - Monitoring and endpoint-management agents - Agent transcripts and debugging output - Wrapper scripts and command telemetry The authentication table assigns the private-key and mnemonic flags higher priority than Ledger or environment-based methods, and most transaction examples reinforce use of the private-key flag. This creates a realistic risk that users will substitute production secrets directly into commands. Environment variables are also not ideal for long-lived wallet secrets because child processes and diagnostic tooling may expose them. They are preferable to command-line arguments only when populated by a protected secret-management mechanism and ...[truncated 1143 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Remove private-key and mnemonic values from all command-line examples. - Make hardware-wallet signing the recommended and highest-priority authentication method. - Support secure interactive secret entry with terminal echo disabled when hardware signing is unavailable. - Integrate with established secret managers or signing services so the CLI receives signatures rather than raw wallet secrets. - If environment-variable compatibility must remain, clearly warn that secrets must be injected by a protected secret manager and must not be placed in shell startup files or command history. - Add explicit warnings about process listings, terminal logs, Agent transcripts, CI logs, and shell history. - Use dedicated low-value or testnet wallets for automation, with narrowly scoped balances and permissions. - Encourage users to review chain ID, contract address, recipient, amount, allowance, and calldata on a trusted signing device before approval. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: references/typescript-sdk.md:12
• Finding: SDK Example Encourages Embedding a Private Key in Source Code<![CDATA[ ## Vulnerability Details **File Location**: `references/typescript-sdk.md`, lines 12–16 **Vulnerability Type**: Hardcoded secret pattern in example source code **Risk Level**: High ### Vulnerable Code ```typescript const walletClient = createWalletClient({ account: privateKeyToAccount("0xYOUR_PRIVATE_KEY"), chain: baseSepolia, transport: http("https://your-rpc-url"), }); ``` ### Technical Analysis Although `0xYOUR_PRIVATE_KEY` is a placeholder rather than an actual secret, the example teaches developers to place a wallet private key directly in application source. Developers commonly replace such placeholders during testing, after which the live key may be committed to version control or copied into build artifacts. Source-embedded secrets can propagate through repository history, code review systems, package distributions, source maps, backups, logs, and Agent context. Removing the key from the latest revision does not remove it from prior commits or other replicated systems. ### Attack Path 1. A developer copies the SDK example into an application. 2. The developer replaces `0xYOUR_PRIVATE_KEY` with a live private key to test transactions. 3. The source file is committed, uploaded, packaged, logged, or shared with an external service. 4. An attacker searches the exposed material and extracts the key. 5. The attacker imports the key into a wallet or signing library. 6. The attacker signs arbitrary transactions as the victim and transfers assets or exercises protocol roles. ### Impact Assessment Exposure grants complete signing authority for the affected wallet. The attacker can transfer wallet assets, authorize token spending, interact with arbitrary contracts, create or collect escrows, and impersonate an oracle if the wallet holds that role. Repository history and distributed artifacts make containment difficult even after the literal is removed. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions - Replace the source-code literal with an example that uses a hardware wallet, external signer, or dedicated secret-management provider. - If an environment variable must be demonstrated, validate that it exists without printing it and state that it must be injected by a protected secret manager. - Add secret-scanning controls to local hooks and CI pipelines. - Prevent `.env` and other local secret files from entering version control, while noting that ignored plaintext files still require restrictive permissions. - Use separate low-value development wallets and never use production keys in sample applications. - Treat any key committed to a repository as compromised: revoke associated permissions where possible, migrate all assets and roles to a new wallet, and remove the secret from repository history and downstream artifacts. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (7)

Missing User Warnings

Medium

• Confidence: 98% confidence
• Finding: The skill explicitly instructs users to pass private keys and mnemonics on the command line and via environment variables without any safety warning or preference for safer signing methods. This is dangerous because CLI arguments can be exposed via shell history, process listings, logs, and agent telemetry, leading to wallet compromise and theft of on-chain assets.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The skill walks users through escrow creation and related asset-moving transactions, including token approvals and native-token transfers, without any explicit warning that these actions can move real funds irreversibly. In an agent-driven context, missing verification steps for chain, token, recipient/arbiter addresses, expiration, and amounts materially increases the risk of accidental loss or sending value to the wrong contract or network.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

Use the `--arbiter` address and the encoded `--demand` hex from step 1:

```bash
# ERC20 escrow with auto-approve
alkahest --private-key 0xKEY escrow create \
  --erc20 \
  --token 0xTOKEN_ADDRESS \

• Confidence: 85% confidence
• Finding: Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

Use the `--arbiter` address and the encoded `--demand` hex from step 1:

```bash
# ERC20 escrow with auto-approve
alkahest --private-key 0xKEY escrow create \
  --erc20 \
  --token 0xTOKEN_ADDRESS \

• Confidence: 85% confidence
• Finding: Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: This reference documents escrow flows that lock assets and later release them based on arbiter validation, but it does not explicitly warn users that interacting with these contracts can result in real asset loss if they choose the wrong contract, arbiter, demand bytes, or network. In a CLI skill intended for buyers, sellers, and oracles, omission of financial-risk warnings increases the chance of unsafe execution of irreversible on-chain actions.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The payment section states that payments transfer assets immediately upon attestation creation, but it still lacks a prominent end-user warning that these are immediate, non-escrowed transfers with no hold period. In the context of an operational skill for interacting with contracts via CLI, users could misinterpret payment obligations as safer escrow-like actions and send assets irreversibly to unintended payees.

Missing User Warnings

Medium

• Confidence: 87% confidence
• Finding: The reference instructs users to instantiate a wallet client with a raw private key string and later documents auto-arbitration behavior, but it does not include clear safety guidance about secret handling or the risks of automated on-chain decisions. In a blockchain escrow context, users may copy this pattern into production, hardcode secrets, or deploy unattended arbitration logic that can irreversibly move value based on flawed logic or compromised infrastructure.

Static analysis

No suspicious patterns detected.