hyperliquid-trading-agent

• Outcome: Review
• Latest audit: Sep 16, 2026 · 3:29 AM UTC
• Version: 1.0.1

Overview

This skill is clearly for Hyperliquid trade execution, but it gives an agent live financial trading authority without a strong user-confirmation or default simulation guard.

Review this carefully before installing. Only use it with a restricted or paper-trading Hyperliquid client unless you intentionally want an agent to submit real orders, and add host-side controls for explicit live-trading approval, market allowlists, hard risk limits, stop-order verification, and emergency shutdown.

A.I.G

Vulnerability Patterns

• 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
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T09 · Insecure Skill Coding Practices

Warning

• Location: examples/basic_usage.py:25

Finding

Incomplete Input Validation Allows Malformed Trade Requests

Content

View full analysis

tuple[bool, str]: if not signal.should_trade: return False, "no valid signal" if risk_per_trade <= 0 or risk_per_trade > 0.02: return False, "risk_per_trade outside allowed range" if leverage < 1 or leverage > 5: return False, "leverage outside allowed range" if account_state["daily_pnl_pct"] <= -0.05: return False, "daily loss limit reached" if signal.entry_price == signal.stop_loss: return False, "entry equals stop" return True, "ok" def build_order_request(market: str, signal: Signal, size: float, leverage: float) -> dict: return { "market": market, "side": signal.side, "order_type": "market", "size": round(size, 6), "leverage": leverage, "entry_price": signal.entry_price, "stop_loss": signal.stop_loss, "take_profit": signal.take_profit, } ``` ### Technical Analysis The validation routine checks only a subset of the controls described by the Skill. It does not validate: - `market` against supported markets. - `signal.side` against the expected `long` and `short` values. - Whether balance, entry price, stop loss, leverage, and risk values are finite numbers. - Whether the calculated position size is finite, positive, and accepted by the market. - Available margin, notional exposure, open-position limits, liquidation distance, funding, or slippage. - Whether the stop loss is directionally valid relative to the requested side. Floating-point values such as `NaN` are particularly problematic because ordinary comparisons with `NaN` evaluate to false. For example, a `risk_per_trade` value of `NaN` bypa ...[truncated 1552 chars]

Remediation

View remediation

T09 · Insecure Skill Coding Practices

Warning

• Location: examples/basic_usage.py:37

Finding

Protective Stop-Loss and Take-Profit Orders Are Not Established or Confirmed

Content

View full analysis

dict: return { "market": market, "side": signal.side, "order_type": "market", "size": round(size, 6), "leverage": leverage, "entry_price": signal.entry_price, "stop_loss": signal.stop_loss, "take_profit": signal.take_profit, } ``` ```python execution_result = client.submit_order(order_request) return { "trade_status": execution_result["status"], "reason": "validated and submitted through host-provided client", "order_request": order_request, "execution_result": execution_result, } ``` ### Technical Analysis The example places `stop_loss` and `take_profit` values inside the market-order dictionary but does not establish them through an explicit trigger-order or protective-order API. It also does not verify that the authenticated client recognizes those fields. After submission, the code trusts the returned status without: - Confirming that separate stop-loss and take-profit orders were accepted. - Ensuring that exits are marked reduce-only where appropriate. - Reconciling the resulting position with actual exchange state. - Handling partial fills. - Detecting a filled entry followed by failure to create protection. - Closing or reducing the position when protective-order setup fails. - Entering safe mode when order and position states are inconsistent. A live client may ignore unknown dictionary fields while successfully executing the entry market order. This creates a discrepancy between the apparent order request and the protections actually active at the exchange. ### Attack Path 1. A valid signal passes the limited trade checks. 2. The a ...[truncated 1069 chars]

Remediation

View remediation

SkillSpector

Vulnerability Patterns

• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access

Findings (2)

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 93% confidence

Finding

The skill explicitly enables live trade execution, position management, and automatic halts/reductions, but it does not include a clear user-facing warning that real orders may be placed and real financial losses may occur. In an agent context, this omission increases the chance of unintended live trading or misuse by operators who mistake it for simulation or advisory-only behavior.

Content

No source excerpt is available for this finding.

Autonomous Decision Making

Medium

• Category: Excessive Agency
• Confidence: 80% 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.

Content

Scanner excerpt · skill.md (reported line 104)May include surrounding context.

md

4. inject only the minimum necessary data into the skill
5. keep secrets out of logs, prompts, and package inputs

The skill should never ask the user to paste a private key into the skill inputs.

---

Static analysis

No suspicious patterns detected.