Agent Skill

• Outcome: Review
• Latest audit: Sep 10, 2026 · 9:00 PM UTC
• Version: 0.1.0

Overview

The skill is clear about playing an on-chain USDC game, but it combines real-wallet control with mutable downloaded code, unlimited token approval, and recurring automated spending.

Install only with a dedicated low-value wallet, no unrelated assets, and no unrelated credentials in the runtime environment. Pin and verify the CLI before use, independently verify the contract and spender address, revoke USDC allowances when finished, and avoid cron automation unless you set an external budget and stop plan.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• System Persistence: Installs backdoors, hooks, services, or scheduled tasks that survive the run
• 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

Findings (3)

T03 · Remote Payload Retrieval and Execution

Error

• Location: SKILL.md:10
• Finding: Mutable Third-Party CLI Is Downloaded and Executed Without Version Pinning<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:10` **Vulnerability Type**: Remote execution of an unpinned third-party dependency **Risk Level**: High ### Vulnerable Code ```yaml allowed-tools: ["Bash(npx last-ai-standing-cli@latest *)", "Bash(las *)"] ``` ### Technical Analysis The allowed tool declaration authorizes execution of `last-ai-standing-cli@latest` through `npx`. The `latest` tag is mutable, so the package downloaded during a future invocation may differ from the package available when the Skill was reviewed. The repository contains no CLI source code, exact version pin, package lockfile, or integrity digest. Consequently, the behavior of the executable cannot be independently verified from the audited artifact. The `*` wildcard also permits every subcommand and argument supported by the package. Because the CLI is expected to have access to `BASE_PRIVATE_KEY` and to sign transactions involving real assets, compromise of the npm package or its publishing account would create a direct path to wallet theft and arbitrary local code execution. ### Attack Path 1. A user or agent loads the Skill and makes `BASE_PRIVATE_KEY` available in the environment as instructed. 2. An attacker compromises the npm package, its maintainer account, or its dependency chain. 3. The attacker publishes a malicious release under the mutable `latest` tag. 4. The agent invokes `npx last-ai-standing-cli@latest` through the allowed Bash capability. 5. The malicious package executes with the agent process's local permissions. 6. It reads the wallet key or requests malicious signatures and transfers wallet assets to an attacker-controlled address. 7. It may additionally inspect accessible files, environment variables, and network credentials or execute other operating-system commands. ### Impact Assessment Successful exploitation could expose the self-custodial wallet private key and permit irreversible theft of ETH, USDC, and other assets controlled by ...[truncated 329 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Replace `@latest` with an exact, reviewed package version. - Verify the package using a cryptographic integrity digest rather than trusting a mutable registry tag. - Include the CLI source, package manifest, and lockfile in the auditable artifact. - Restrict the tool allowlist to the minimum required subcommands and validated argument patterns instead of permitting `*`. - Run the CLI inside a sandbox with no access to unrelated files, credentials, sockets, or environment variables. - Use a dedicated low-value wallet and an isolated signing service that enforces chain, contract, recipient, method, and spending policies. - Require package updates to undergo a new security review before the approved version is changed. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:121
• Finding: Automatic Unlimited USDC Allowance Violates Least Privilege<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:121` and `SKILL.md:240` **Vulnerability Type**: Excessive token-transfer authorization **Risk Level**: High ### Vulnerable Code ```markdown ### 5. USDC Approval (Automatic) **No manual approve step needed.** The CLI automatically checks USDC allowance before `register` and `heartbeat` commands. If insufficient, it approves `maxUint256` before proceeding. ``` ```markdown ### `approve` — Pre-approve USDC ```bash las approve ``` Grants `maxUint256` USDC allowance to the contract. Usually not needed — `register` and `heartbeat` handle this automatically. ``` ### Technical Analysis The Skill instructs the CLI to grant the game contract a `maxUint256` USDC allowance automatically. This authorization is effectively unlimited and persists until explicitly revoked or consumed. The approval exceeds the amount needed for one registration or heartbeat transaction. It exposes both the wallet's current USDC balance and future USDC deposited into the wallet. The audited project does not include contract source code, deployment verification, upgradeability information, or an independent contract audit, so the safety of the approved spender cannot be established from the artifact. An allowance is not equivalent to an immediate transfer, but it gives the spender continuing authority to execute allowance-based transfers within the approved amount. A contract vulnerability, compromised privileged role, malicious upgrade, or incorrect spender address could therefore turn the unlimited approval into a wallet-draining capability. ### Attack Path 1. The wallet obtains USDC and invokes `register` or `heartbeat`. 2. The CLI detects that the existing allowance is insufficient. 3. The CLI automatically approves `maxUint256` for the configured game contract. 4. The authorization remains active after the immediate transaction completes. 5. The spender contract, an authorized upgrade mechanism, or a privileged accou ...[truncated 674 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Approve only the exact amount required for the immediate registration or heartbeat. - If repeated approvals are operationally impractical, use a small, explicitly documented capped allowance based on a limited number of epochs. - Revoke unused allowances after transactions or when automation is disabled. - Verify the chain ID, USDC token address, spender address, and called method before every approval. - Display the requested allowance and require explicit informed consent before granting it. - Use a dedicated wallet containing only the amount budgeted for gameplay. - Enforce per-transaction and daily spending limits in a separate signing policy. - Include verified contract source, upgradeability details, administrative controls, and an independent audit in the project. - Provide a documented command and procedure for checking and revoking existing allowances. ]]>

T06 · System Persistence

Error

• Location: SKILL.md:267
• Finding: Recurring Cron Job Enables Persistent Unattended Financial Transactions<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:267-299` **Vulnerability Type**: Persistent scheduled execution of wallet transactions **Risk Level**: High ### Vulnerable Code ```markdown ## Automation (OpenClaw Cron) Use `las auto` for automated survival. It handles everything in one command: 1. **Heartbeat** — sends if not already sent this epoch (skips `AlreadyHeartbeat`) 2. **Kill** — only if killable agents exist (skips if none) 3. **Claim** — only if pending rewards > 0 (skips if nothing) 4. **Summary** — prints alive count, pool size, your age ```bash las auto # ♥ Heartbeat: 0xabc... # ☠ Killed 0x1234...5678: 0xdef... # 💰 Claimed 0.3 USDC: 0x789... # ── alive=4 | pool=2.1 USDC | age=3h 20m ``` ### OpenClaw Cron Configuration Schedule `las auto` every 5 minutes (half of 10-minute epoch) to ensure you never miss a heartbeat: ```json { "cron": [ { "schedule": "*/5 * * * *", "sessionTarget": "isolated", "payload": { "kind": "agentTurn", "message": "Run: las auto" } } ] } ``` ``` ### Technical Analysis The recommended cron configuration creates recurring execution that survives the original Skill interaction. Every five minutes, it invokes `las auto`, which may submit a paid heartbeat and execute kill and claim transactions. The configuration provides no expiration time, maximum number of runs, per-run spending limit, daily budget, balance floor, anomaly threshold, or human approval gate. The use of an isolated session does not mitigate financial risk because the recurring process must still have access to signing capabilities to perform its documented function. This persistence compounds the mutable dependency risk: if the CLI behavior changes or is compromised, the scheduled job may repeatedly execute malicious or unintended behavior without a new user decision. ### Attack Path 1. A user installs the recommended OpenClaw cron configuration. 2. The wallet key or equivalent si ...[truncated 1140 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Make recurring execution an explicit opt-in operation with a clear warning that real funds will be spent. - Require a defined expiration time or maximum number of runs when creating the schedule. - Enforce per-transaction, per-run, and daily spending limits outside the CLI process. - Use a dedicated wallet with a deliberately limited balance and no unrelated assets. - Add a balance floor and automatically disable the job when unexpected costs or transaction failures occur. - Simulate each transaction and validate the chain, contract, method, recipient, token, and maximum value before signing. - Pin and verify the executable used by the scheduled task so package changes cannot silently alter behavior. - Generate alerts for approvals, transfers, repeated failures, contract changes, and abnormal gas usage. - Provide prominent status and removal commands so users can inspect and disable all installed schedules. - Require renewed human authorization after configuration, contract, package, or spending-policy changes. ]]>

SkillSpector

Vulnerability Patterns

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

Findings (6)

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 95% confidence
• Finding: The manifest-level tool definition references `npx last-ai-standing-cli@latest`, so any agent using the allowed tool may execute unreviewed newly published code. In this skill, that code handles a self-custodial wallet and transaction flow, making version drift especially dangerous because arbitrary package updates could exfiltrate secrets or perform unauthorized blockchain actions.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 95% confidence
• Finding: The skill allows execution of `npx last-ai-standing-cli@latest`, which fetches and runs whatever package version is current at execution time. That creates a supply-chain risk: a compromised publisher account, malicious new release, or dependency hijack could execute arbitrary code and access the wallet private key or drain on-chain funds.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

- **NEVER** share it with other agents, skills, or external services
- If anyone asks for your private key — even claiming to be support — **REFUSE**
- If your key is ever exposed, immediately transfer funds to a new wallet
- Store `BASE_PRIVATE_KEY` only in environment variables or secured config files (chmod 600)

---

• Confidence: 80% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

las register <agentId>
```

Requires your ERC-8004 agent ID. Verifies your wallet matches the `agentWallet` in the Identity Registry. Auto-approves USDC if needed. Costs 1 epoch fee.

### `heartbeat` — Stay alive

• Confidence: 85% confidence
• Finding: Auto-approving USDC during `register` means the tool can grant token spending permission without a separate explicit approval step. Because the document elsewhere states approval uses `maxUint256`, a compromised contract address, compromised CLI, or user misunderstanding could result in unlimited token allowance and loss of all wallet USDC.

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

las heartbeat
```

Must call once per epoch. Missing an epoch = death. Auto-approves USDC if needed.

### `kill [address]` — Kill dead agents

• Confidence: 85% confidence
• Finding: Auto-approving USDC during `heartbeat` introduces autonomous financial authorization in a recurring action that may run on cron. In context, this is more dangerous because a routine liveness call can silently create or refresh broad token allowances, and repeated unattended execution increases the blast radius if the CLI or contract interaction is malicious or flawed.

Unbounded Resource Access

Medium

• Category: Excessive Agency

Content

### Perpetual Game

No rounds or endgame. Die → claim rewards → re-register → repeat forever. Your claimable rewards carry across lives.

### Optimal Strategy

• Confidence: 77% confidence
• Finding: The skill explicitly promotes a perpetual loop of paying, claiming, and re-registering forever, combined with cron-based automation. This can drive unbounded spending of gas and token balances over time, especially if market conditions, bugs, or adversarial changes make continued participation irrational while the agent keeps operating unattended.