Back to skill

Security audit

TigerPass — Hardware-Secured Crypto Wallet & Trading Terminal for AI Agents | Hyperliquid Perps, Polymarket Predictions, DEX Swaps, Cross-Chain Bridge, E2E Encrypted Agent-to-Agent Commerce

Security checks for vulnerabilities and agentic risk

Overview

This is a coherent crypto wallet and trading skill, but it gives agents broad real-money signing authority and installs an unverified external CLI, so it belongs in Review before use.

Only install this if you intentionally want an autonomous agent to control real crypto assets. Prefer a pinned, signed release with checksum verification, start in TIGERPASS_ENV=test, set explicit spend and protocol limits, verify every contract, spender, recipient, chain, and x402 merchant, avoid unlimited approvals where possible, and do not leave listener or auto-trading flows running without a policy you are willing to enforce.

Vulnerability Patterns
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • 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
Findings (3)

T03 · Remote Payload Retrieval and Execution

Error
Location
SKILL.md:43
Finding
Mutable Remote Source Is Retrieved, Built, and Installed Without Integrity Verification## Vulnerability Details **File Location**: `SKILL.md:43` **Vulnerability Type**: Remote payload retrieval and execution **Risk Level**: High ### Vulnerable Code ```yaml command: "cd /tmp && git clone https://github.com/TigerPassNet/tigerpass-cli.git && cd tigerpass-cli && make release && sudo cp .build/release/TigerPass /usr/local/bin/tigerpass" ``` ### Technical Analysis The source installation retrieves the mutable default branch of an external Git repository and immediately runs its build process. It does not pin an immutable commit or release tag, verify a cryptographic signature, or validate a checksum. The effective code executed by `make release` can therefore change after this Skill has been reviewed. Repository-controlled build files and scripts execute with the installing user's privileges. The resulting binary is then copied into `/usr/local/bin/tigerpass` using `sudo`, replacing or introducing a system-wide command used for wallet signing and financial transactions. Although `sudo` is applied specifically to the copy operation rather than the entire build, it allows the unverified artifact to be installed into a privileged executable location. ### Attack Path 1. An attacker compromises the upstream repository, a maintainer account, or the upstream development pipeline. 2. The attacker modifies the default branch, build scripts, or source used to produce the TigerPass binary. 3. A user or agent follows the documented source installation command. 4. `git clone` retrieves the attacker-controlled revision. 5. `make release` executes malicious build-time code with the installing user's privileges. 6. The attacker-controlled binary is copied to `/usr/local/bin/tigerpass`. 7. Subsequent wallet, signing, trading, bridging, or smart-contract commands run through the substituted binary. ### Impact Assessment A successful compromise can provide arbitrary code execution with the ...[truncated 521 chars]
Remediation
## Remediation Suggestions - Pin the installation to a specific audited release tag and immutable commit hash. - Verify that the tag is cryptographically signed by an authorized release key. - Publish and validate a SHA-256 checksum or signed provenance record for the source and compiled artifact. - Build in a sandbox or isolated environment with restricted filesystem and network access. - Review repository build scripts before running `make release`. - Prefer reproducible builds so users can compare the locally produced binary with an independently verified release. - Install into a user-controlled directory where possible instead of invoking `sudo`. - If system-wide installation is necessary, verify the final artifact immediately before the privileged copy operation.

T08 · Insecure Dependencies

Warning
Location
SKILL.md:37
Finding
Recommended Homebrew Installation Trusts an Unpinned Third-Party Supply Chain## Vulnerability Details **File Location**: `SKILL.md:37` and `SKILL.md:76` **Vulnerability Type**: Insecure dependency installation **Risk Level**: Medium ### Vulnerable Code ```yaml command: "brew tap TigerPassNet/tigerpass && brew install tigerpass" ``` ```bash # 1. Install brew tap TigerPassNet/tigerpass && brew install tigerpass ``` ### Technical Analysis The recommended installation adds a third-party Homebrew tap and installs the current package resolved by mutable tap metadata. The instructions do not pin a formula version or artifact, verify a publisher signature, or require independent checksum validation. The audited project contains only documentation and no local TigerPass implementation. Consequently, the high-privilege financial behavior described by the Skill is delegated entirely to an externally supplied binary that cannot be compared against code in the package. ### Attack Path 1. An attacker compromises the Homebrew tap repository, release storage, maintainer credentials, or publication pipeline. 2. The attacker changes the formula or replaces the referenced installation artifact. 3. A user runs the recommended `brew tap` and `brew install` commands. 4. Homebrew resolves and installs the malicious package through the trusted-looking TigerPass command name. 5. The substituted CLI receives future signing, wallet, trading, payment, and smart-contract execution requests. ### Impact Assessment The installed package runs with the user's privileges and becomes the interface through which the agent authorizes financial operations. A malicious package could tamper with payment addresses, amounts, chain IDs, approval spenders, contract calldata, bridge recipients, trading orders, or messages. The scope includes assets accessible to the wallet and local information accessible to the user account. The precise effect cannot be validated from this project because the installed CLI sou ...[truncated 42 chars]
Remediation
## Remediation Suggestions - Pin installation instructions to a specific versioned formula and immutable release artifact. - Publish signed checksums and require verification before installation. - Use signed release tags and supply-chain provenance such as SLSA attestations. - Document the expected formula repository, artifact URL, checksum, signing identity, and verification commands. - Use reproducible builds and provide a procedure for comparing the Homebrew binary against an independently built artifact. - Configure automated monitoring for unauthorized changes to tap metadata and release artifacts. - Avoid silently upgrading the wallet CLI in autonomous environments; require review and explicit authorization for upgrades.

T09 · Insecure Skill Coding Practices

Warning
Location
references/advanced-commands.md:32
Finding
Workflows Recommend Persistent Unlimited Token Approvals## Vulnerability Details **File Location**: `references/advanced-commands.md:32` and repeated in `references/advanced-commands.md:199`, `references/defi-cookbook.md:369-376`, `references/defi-cookbook.md:399`, `references/defi-cookbook.md:450`, and `references/defi-cookbook.md:665` **Vulnerability Type**: Excessive ERC-20 spending authorization **Risk Level**: Medium ### Vulnerable Code ```bash # ERC-20 operations tigerpass approve --token USDC --spender 0xRouter --amount 100 tigerpass approve --token USDC --spender 0xRouter --amount max # unlimited tigerpass approve --token USDC --spender 0xRouter # query allowance (omit --amount) ``` The Hyperliquid workflow also explicitly recommends a persistent maximum allowance: ```bash # Approve Max (One-Time) For repeated deposits, approve unlimited USDC once: tigerpass approve \ --token USDC \ --spender 0x6b9e773128f453f5c2c60935ee2de2cbc5390a24 \ --amount max \ --chain HYPEREVM ``` A generic DeFi workflow repeats the same pattern: ```bash # 2. Approve the protocol to spend your tokens (skip for native ETH) tigerpass approve --token USDC --spender <PROTOCOL_ROUTER> --amount max ``` ### Technical Analysis An ERC-20 allowance authorizes the designated spender to transfer tokens from the wallet through `transferFrom`. Using `--amount max` grants authority over the wallet's entire current and future balance for that token until the allowance is revoked or replaced. Maximum approval is presented both as a protocol-specific convenience and as a generic DeFi pattern. This violates least privilege because the required authority normally corresponds to the amount used by one transaction. Simulation of the subsequent transaction does not remove the persistent allowance risk. The Polymarket setup also documents multiple unlimited ERC-20 and ERC-1155 operator approvals. Those approvals increase the number of external contracts whose ...[truncated 1196 chars]
Remediation
## Remediation Suggestions - Default to exact, transaction-specific allowances rather than `--amount max`. - Query token decimals and calculate the minimum required atomic amount before approval. - Verify the chain ID, token address, spender address, and official protocol source immediately before approval. - Revoke or reset allowances to zero after the operation completes. - Require explicit user confirmation and a prominent warning before granting unlimited approval. - Add an allowance-audit command or documented workflow that lists and revokes stale approvals. - Separate approval and execution steps so the user can verify the confirmed allowance before proceeding. - For repeated operations, use bounded allowances based on a documented spending cap instead of the maximum `uint256` value. - Monitor approved contracts for upgrades, incidents, and governance changes. - Clearly explain that transaction simulation validates execution behavior but does not mitigate persistent allowance exposure.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
Findings (20)

Credential Access

High
Category
Privilege Escalation
Content
---
name: tigerpass
version: "1.0.0"
description: "Crypto wallet and trading terminal for AI agents — trade Hyperliquid perps and spot, bet on Polymarket predictions, swap tokens on 6 EVM chains, bridge USDC cross-chain. Hardware-secured private key in Apple Secure Enclave, physically impossible to extract. Built-in engines for perpetual futures, prediction markets, DEX swaps via 0x aggregator, and Circle CCTP V2 bridging. Execute any smart contract (AAVE, Compound, Uniswap), sign EIP-191/EIP-712 messages, handle x402 HTTP payments, and sell services to other agents via ACE Protocol with E2E encrypted messaging and on-chain reputation. The only agent wallet combining hardware security with full autonomous signing — no .env keys, no MPC trust, no human-in-the-loop. Use when: Hyperliquid trading, perpetual futures, spot trading, Polymarket betting, prediction markets, copy trading, whale tracking, trading bots, algorithmic trading, arbitrage, portfolio management, sending crypto, receiving crypto, wallet balance, token swaps, DEX trading, cross-chain bridge, USDC transfer, smart contract execution, contract calls, message signing, x402 payments, DeFi yield, DeFi lending, AAVE, Compound, agent wallets, on-chain identity, ERC-8004, agent commerce, agent-to-agent payments, autonomous trading, hardware wallet, private key security, secure enclave. Works with Claude Code, Codex, Gemini CLI, OpenClaw. Requires Apple Silicon Mac."
homepage: https://tigerpass.net
tags:
  - crypto
Confidence
60% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Chaining Abuse

High
Category
Tool Misuse
Content
label: "Install TigerPass CLI via Homebrew (recommended, requires Apple Silicon Mac)"
      - id: source
        kind: custom
        command: "cd /tmp && git clone https://github.com/TigerPassNet/tigerpass-cli.git && cd tigerpass-cli && make release && sudo cp .build/release/TigerPass /usr/local/bin/tigerpass"
        bins:
          - tigerpass
        label: "Build TigerPass CLI from source (requires Xcode + Apple Silicon Mac)"
Confidence
93% confidence
Finding
The install command chains multiple operations from /tmp through git clone, build, and sudo copy in a single shell line. This combination reduces opportunities for inspection or verification between stages and makes it easier for a compromised repo, substituted dependency, or tampered build artifact to flow directly into privileged installation.

Missing User Warnings

High
Confidence
96% confidence
Finding
The documentation presents installation, initialization, trading, swapping, bridging, and message-listening as a quick-start flow without an upfront warning that these actions can move funds, create on-chain approvals, expose the agent to incoming requests, and are often irreversible. In a skill for autonomous agents handling real assets, missing prominent safety framing materially raises the risk of unintended financial loss.

Vague Triggers

Medium
Confidence
95% confidence
Finding
The skill advertises an extremely broad 'Use when' trigger list spanning generic wallet, trading, payment, DeFi, and agent-commerce tasks. In an agentic system, this can cause the skill to be selected in far more contexts than intended, increasing the chance that a model invokes high-risk financial operations when the user only asked for information, monitoring, or low-risk portfolio tasks.

Sudo/Root Execution

Medium
Category
Privilege Escalation
Content
label: "Install TigerPass CLI via Homebrew (recommended, requires Apple Silicon Mac)"
      - id: source
        kind: custom
        command: "cd /tmp && git clone https://github.com/TigerPassNet/tigerpass-cli.git && cd tigerpass-cli && make release && sudo cp .build/release/TigerPass /usr/local/bin/tigerpass"
        bins:
          - tigerpass
        label: "Build TigerPass CLI from source (requires Xcode + Apple Silicon Mac)"
Confidence
91% confidence
Finding
The source install path instructs the user to clone code from the internet, build it, and then copy the resulting binary into a privileged system path using sudo. If the repository, dependency chain, or build process is compromised, this becomes a straightforward route to local privilege misuse and persistent installation of malicious code.

Autonomous Decision Making

Medium
Category
Excessive Agency
Content
- **Bet on prediction markets** via Polymarket — arbitrage, probability modeling, high-probability bonds
- **Swap tokens** across 6 EVM chains (Ethereum, Base, Arbitrum, Polygon, BNB Chain, HyperEVM) using 0x DEX aggregator
- **Bridge USDC** cross-chain via Circle CCTP V2 — Ethereum, Arbitrum, Base, Polygon, HyperEVM
- **Copy trade whales** — monitor large positions and auto-execute proportional trades
- **Build autonomous trading bots** — algorithmic trading with hardware-secured signing
- **Execute any smart contract** — AAVE lending, Compound, Uniswap, or any protocol via universal `exec` command
- **Sell AI services** to other agents — GPU compute, trading signals, data feeds, API access via ACE Protocol
Confidence
88% confidence
Finding
The skill explicitly promotes autonomous trading bots, auto-execution, and arbitrary smart-contract execution, which enables an agent to take irreversible financial actions without human review. While these are core features, in this context they materially increase the blast radius of prompt mistakes, model misclassification, or malicious inputs.

Autonomous Decision Making

Medium
Category
Excessive Agency
Content
#    (see references/defi-cookbook.md for the approve+deposit steps)
```

Builder fee is **auto-approved on your first order** — no separate step needed.

**Trading:**
Confidence
87% confidence
Finding
Auto-approving builder fees on first order means the first trade may also create an on-chain approval or permission change without a separate explicit consent step. In autonomous use, hidden approval side effects can grant spending rights or add unexpected state changes that the operator does not realize occurred.

Autonomous Decision Making

Medium
Category
Excessive Agency
Content
tigerpass hl info --spot --type balances      # spot token balances
```

**Builder fees**: Perps 5bp (0.05%), spot 50bp (0.5%). Auto-approved on your first order.

For full workflows, spot examples, and output details, read `references/defi-cookbook.md`.
Confidence
86% confidence
Finding
Repeating that fees are auto-approved normalizes silent approval behavior as part of ordinary trading. In a wallet skill with autonomous signing, this reduces transparency around delegated token spending and can expose users to unnecessary approval risk if the spender or approval scope is broad.

Autonomous Decision Making

Medium
Category
Excessive Agency
Content
## "I want to copy trade Hyperliquid whales"

You can build a whale tracking → auto-execute pipeline. The pattern:

1. **Monitor whale positions** — use on-chain data tools (HyperTracker, CoinGlass, Hyperbot) or Hyperliquid's public API to detect large position changes
2. **Evaluate the signal** — you (the AI) assess whether the whale's move makes sense given current market conditions
Confidence
85% confidence
Finding
A documented whale-tracking to auto-execute pipeline encourages agents to mirror external trading signals with minimal friction. In this context, that can amplify bad data, manipulated signals, or adversarial market behavior into direct losses because execution authority is embedded in the same toolchain.

Autonomous Decision Making

Medium
Category
Excessive Agency
Content
## Fees

- Swap: 15bp (0.15%) integrator fee
- Hyperliquid: perps 5bp, spot 50bp (builder fee, auto-approved on first order)
- Bridge: dynamic fee from Circle (~$0.20-$3.60 USDC per transfer)

## Performance Flags
Confidence
85% confidence
Finding
Listing auto-approved builder fees in the fees section reinforces that hidden state-changing approvals are a routine part of use. In an autonomous wallet, undisclosed or implicit approvals are dangerous because they can persist beyond the immediate transaction and widen the attack surface.

Autonomous Decision Making

Medium
Category
Excessive Agency
Content
## Performance Flags

`--no-wait` (skip confirmation), `--simulate` (dry-run: `exec`, `swap`, `pay`).

## Environment
Confidence
85% confidence
Finding
Advertising a '--no-wait' flag that skips confirmation encourages workflows where an agent proceeds without verifying transaction finality or failure. In a financial automation context, this can cascade into duplicate actions, inconsistent state handling, or further risky decisions based on unconfirmed transactions.

Missing User Warnings

Medium
Confidence
90% confidence
Finding
The documentation instructs agents to execute owner-originated `agent-request` and `agent-action` messages after only checking `senderRole == "owner"` and `ownerVerified == true`, but it omits any explicit user-consent, policy, parameter-validation, or transaction-risk warning before performing on-chain actions. In a wallet skill with autonomous signing and smart-contract execution, this can normalize blind execution of high-risk commands and make socially engineered, overly broad, or malicious-but-owner-signed instructions far more likely to result in irreversible fund loss or dangerous contract interactions.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
This section documents raw contract execution, ERC-20 approvals including unlimited approvals, and message signing without a prominent warning that these actions can irreversibly move funds, grant spending authority, or authorize dangerous off-chain actions. In an autonomous agent wallet context, operators may treat examples as routine commands, which materially increases the chance of accidental loss or overbroad approvals.

Missing User Warnings

Medium
Confidence
97% confidence
Finding
The x402 flow explains how to sign a payment payload and retry the request, but does not clearly warn that doing so authorizes a real payment to the merchant and may transfer value immediately. Because this skill is designed for autonomous agent commerce, an agent could automatically satisfy any 402 response and pay an attacker-controlled endpoint if origin, amount, asset, or timeout are not independently validated.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
The bridge section describes CCTP transfers as a simple one-command flow but lacks a prominent warning that bridging burns USDC on the source chain first, completion can be delayed, and mistakes in destination selection or recipient details can lead to funds being inaccessible or difficult to recover. In a wallet skill meant for autonomous trading and cross-chain movement, presenting bridging as routine increases the risk of irreversible operational mistakes.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
This cookbook gives step-by-step instructions for autonomous swaps, transfers, approvals, bridging, leveraged trading, and arbitrary contract execution without prominently warning that these actions can cause irreversible on-chain loss, liquidation, or approval abuse. In a wallet/trading skill intended for agent automation, omission of explicit safety gating materially increases the chance that an agent executes risky financial actions without meaningful user consent or review.

Autonomous Decision Making

Medium
Category
Excessive Agency
Content
### Setup (Once)

Bridge USDC to HyperEVM and deposit to L1 — see [Bridge to Hyperliquid](#bridge-to-hyperliquid). Builder fee is auto-approved on first order; no separate setup needed.

### Trading Workflow
Confidence
87% confidence
Finding
The statement that builder fees are auto-approved on first order indicates an order can silently trigger an approval side effect in addition to trade placement. Hidden or implicit approval behavior is dangerous in wallet automation because users and supervising agents may believe they are only placing an order, not expanding token permissions.

Missing User Warnings

Medium
Confidence
98% confidence
Finding
The guide recommends `--amount max` approvals as a convenience pattern but does not explain that unlimited ERC-20 allowance lets the spender drain all present and future approved tokens if the contract is compromised, upgraded maliciously, or the address is wrong. Because this skill targets autonomous DeFi execution, normalizing unlimited approvals significantly expands blast radius from a single mistake or dependency compromise.

Autonomous Decision Making

Medium
Category
Excessive Agency
Content
# 6. Check balance on L1 (NOT HyperEVM balance!)
tigerpass hl info --type balances

# 7. Place your first order (builder fee auto-approved on first order)
tigerpass hl order --coin BTC --side buy --price 95000 --size 0.01
```
Confidence
87% confidence
Finding
Repeating that the first order auto-approves builder fees reinforces a workflow where a trade command can also change authorization state without a dedicated approval action. In a high-risk financial skill, combining trading and permission-granting increases the chance of unnoticed authorization changes and weakens auditability of agent actions.

Missing User Warnings

Medium
Confidence
97% confidence
Finding
The Polymarket setup instructs users to grant six approvals, including unlimited ERC-20 and ERC-1155 operator permissions, without clearly stating that these permissions can enable broad asset movement or disposal if any approved contract is compromised or misidentified. Multiple sequential broad approvals compound risk, especially for an autonomous agent wallet that may execute them with minimal human review.

Static analysis

No suspicious patterns detected.