T01 · Skill Instruction Hijacking
- Location
SKILL.md:12- Finding
Mutable Remote Document Is Granted Highest-Priority Control Over Agent Behavior
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is for real Gate futures trading, but it needs Review because it combines live financial write access with mutable remote runtime instructions and inconsistent confirmation rules.
Install only if you intentionally want an agent to manage live Gate USDT perpetual futures with Fx:Write. Use restricted exchange credentials, require explicit confirmation before every order, cancellation, leverage change, or margin-mode switch, and prefer a version that vendors or pins all runtime rules instead of loading mutable remote instructions.
SKILL.md:12Mutable Remote Document Is Granted Highest-Priority Control Over Agent Behavior
references/open-position.md:112Margin Mode and Leverage Can Be Modified Before Final Order Confirmation
Referenced artifact was not completely inspected
**Read and strictly follow** [`references/mcp.md`](./references/mcp.md), then execute module-specific routes in this `SKILL.md`.
Referenced artifact was not completely inspected
**Read and strictly follow** [`references/mcp.md`](./references/mcp.md), then execute module-specific routes in this `SKILL.md`.
Skill contains instructions that could directly expose system prompts, internal rules, or hidden instructions to users or external parties.
- **Base (e.g. BTC, ETH)**: contracts = base_amount ÷ quanto_multiplier
- Floor to integer; must satisfy `order_size_min`.
2. **Mode**: **Switch margin mode only when the user explicitly requests it**: switch to isolated only when user explicitly asks for isolated (e.g. "isolated"); switch to cross only when user explicitly asks for cross (e.g. "cross"). **If the user does not specify margin mode, do not switch — place the order in the current margin mode** (from position `pos_margin_mode`). If user explicitly wants isolated, check leverage.
3. **Mode switch**: only when user **explicitly** requested a margin mode and it **differs from current** (current from position: `pos_margin_mode`), then **before** calling `cex_fx_update_fx_dual_position_cross_mode`/`cex_fx_update_fx_position_cross_mode`: get **position mode** via `cex_fx_get_fx_accounts(settle)` → **`position_mode`** (single/dual); if `position_mode === "single"`, show prompt *"You already have a {currency} position; switching margin mode will apply to this position too. Continue?"* and continue only after user confirms; if `position_mode === "dual"`, **do not** switch—interrupt and tell user *"Please close the position first, then open a new one."*
4. **Mode switch (no conflict)**: only when user **explicitly** requested cross or isolated and that target differs from current: if no position, or single position and user confirmed, call `cex_fx_update_fx_dual_position_cross_mode` (dual) or `cex_fx_update_fx_position_cross_mode` (single) with **`mode`** `"cross"` or `"isolated"`. **Do not switch if the user did not explicitly request a margin mode.**
5. **Leverage**: if user specified leverage and it **differs from current** (from position query per dual/single above), call **`cex_fx_update_fx_dual_position_leverage`** in dual mode or **`cex_fx_update_fx_position_leverage`** in single mode **first**, then proceed. **If user did not specify leverage, do not change it — use the current leverage from the positi
...[truncated 25 chars]
The routing table uses broad keywords like 'buy', 'sell', 'open', and 'close' to dispatch into trading submodules. In a high-risk context like perpetual futures trading, ambiguous trigger terms can cause the wrong skill path to activate from ordinary discussion or incomplete user phrasing, increasing the chance of unintended order preparation or execution flow.
The manifest description includes ambiguous activation phrases such as 'open long', 'close short', and 'futures TP/SL', which may match casual user language without clearly signaling that real futures trading actions are in scope. Because this skill has authenticated write access, ambiguous invocation materially raises the risk of accidental activation in normal portfolio discussion.
Skill grants unrestricted tool access without appropriate constraints. An agent with unfettered tool access can perform arbitrary actions including file modification, network requests, and code execution.
## General Rules
⚠️ STOP — You MUST read and strictly follow the shared runtime rules before proceeding.
Do NOT select or call any tool until all rules are read. These rules have the highest priority.
→ Read [gate-runtime-rules.md](https://github.com/gate/gate-skills/blob/master/skills/gate-runtime-rules.md)
- **Only call MCP tools explicitly listed in this skill.** Tools not documented here must NOT be called, even if they
exist in the MCP server.
The skill advertises broad trigger keywords like 'buy', 'sell', 'long', 'short', and 'open', which overlap heavily with ordinary trading conversation. In an agent environment, this increases the chance of unintended routing into a write-capable futures trading skill, potentially leading to accidental order placement or risky follow-up prompts in a high-impact financial context.
The trigger examples in this section are short, generic command forms that can plausibly appear in broader conversation and may cause the trading skill to activate without sufficiently clear user intent. In a futures-trading context, ambiguous invocation is risky because it can steer the agent into modifying live orders tied to financial positions, increasing the chance of unintended order changes or prompting the user down a high-impact workflow.
The no-ID trigger phrases are especially broad because they can activate the skill before a specific target order is identified, causing the agent to list open orders and proceed within a sensitive trading workflow based on minimal input. In a perpetual futures skill, that ambiguity is more dangerous than in low-risk domains because exposure, leverage, and order modifications can materially affect a user's financial position even if the tool later asks follow-up questions.
The trigger phrases include very broad inputs such as 'Cancel my order', 'Cancel order', and 'Show my orders', which can cause the cancellation workflow to activate from ambiguous user intent. In a trading skill, unintended invocation is risky because it can quickly progress into destructive account actions if the system misinterprets context or stale selections.
The numbered-selection flow cancels orders immediately after parsing a list choice, without an explicit confirmation that identifies the exact order details to be cancelled. This is dangerous because users can easily misclick, misunderstand list numbering, or act on stale order lists, leading to unintended loss of trading opportunities or protective orders.
The contract-wide cancellation flow performs bulk destructive action for all orders on a contract without requiring an explicit warning or confirmation. In futures trading, wiping all resting orders for a symbol can remove entries, exits, and hedges at once, materially increasing market exposure and operational risk.
Direct cancellation by order ID executes immediately once an ID is parsed, without warning the user or confirming the target order metadata. This is risky because a mistyped, pasted, or spoofed identifier can cancel the wrong live order, and the user may not realize the consequence until market conditions change.
The custom-text cancellation flow allows destructive action based on a text identifier without an explicit confirmation step. Because text labels can be easier to confuse, reuse, or socially engineer than numeric IDs, this increases the chance of cancelling the wrong order or automating unsafe cancellation from ambiguous references.
Side-based bulk cancellation can remove multiple buy or sell orders across one or more contracts without a required warning or confirmation. In a futures context, this can abruptly strip layered entries, exits, or risk controls on one side of the book, causing significant unintended exposure during fast markets.
The guidance instructs the agent to place market reduce-only orders that can immediately close futures positions, realize PnL, and change liquidation/margin dynamics, but it does not require an explicit warning that these are real trading actions with financial consequences. In the context of leveraged perpetual futures, omission of that warning increases the risk that users approve or invoke actions without understanding that exposure and losses can change instantly.
The trigger examples include generic phrases like "Close BTC position" and similar natural-language requests that can easily occur in ordinary conversation without conveying full trading intent, account, or order details. In a live futures-trading skill, ambiguous close-position triggers can cause unintended execution of real market orders, immediately altering exposure and realizing profit or loss.
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.
3. **Re-create**: call `cex_fx_create_fx_price_triggered_order` with the updated parameters.
4. **Verify new order**: confirm new order status is `open`.
When user requests to amend a conditional open order (e.g. "change trigger price to X"), automatically perform the cancel-and-recreate flow without requiring separate confirmation for each step. Show one combined confirmation: *"Conditional open orders cannot be amended directly. I will cancel the old order and create a new one. Confirm?"*
The file’s global rules say margin mode must only be switched when the user explicitly requests cross or isolated, but Scenario 1 directs an unconditional switch to cross. In a trading skill, silently changing margin mode alters the user’s risk configuration and can affect existing or future positions, creating unauthorized account-state changes beyond the requested order.
The document establishes a pre-order confirmation requirement before opening positions, but the FOK scenario instructs immediate order placement. Because FOK orders are still live trade instructions that may execute instantly, skipping confirmation can cause unauthorized trades and financial loss if the agent misparsed the symbol, size, or price.
This scenario tells the agent to submit the order first and only react after the exchange rejects it for excessive price deviation. Even if the exchange blocks many such orders, placing obviously invalid or extreme-price orders without prior user confirmation or validation can create unnecessary execution attempts, user confusion, and in edge cases may execute if the market moves into range.
The insufficient-balance scenario describes placing the order directly to discover margin insufficiency, without mentioning the file’s required confirmation step for opening positions. In a financial-trading skill, attempting order submission before confirmation can still create unauthorized execution if balances or market conditions differ from expectation, and at minimum results in unsafe order attempts against the user’s account.
The insufficient-balance guidance suggests increasing leverage as a remedy even though the document elsewhere forbids changing leverage unless the user explicitly requests it. In a futures trading context, recommending or triggering leverage changes can materially increase liquidation risk and may cause the agent to steer users toward a riskier position than intended.
No suspicious patterns detected.