Back to skill

Security audit

Swarm Tips

Security checks for vulnerabilities and agentic risk

Overview

This skill is transparent about using a remote MCP server for crypto workflows, but it asks agents to rely on that mutable server to construct real blockchain transactions for local signing.

Install only if you are comfortable connecting a wallet to a remote crypto MCP service. Use a dedicated low-balance wallet, inspect and simulate every transaction before signing, do not let autonomous steps sign or submit without approval, and treat changes in the server tool inventory as security-relevant.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (1)

T08 · Insecure Dependencies

Error
Location
SKILL.md:12
Finding
Mutable Remote MCP Service Controls Financial Transaction Construction<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 12–14, with transaction-signing workflows further documented at lines 35–38 and 50 **Vulnerability Type**: Mutable third-party service trusted to construct financial transactions **Risk Level**: High ### Vulnerable Code Snippet ```markdown One MCP server, 41 listed tools (as of 2026-08-25 — the authoritative inventory is the server's own `tools/list`) across three live Solana-mainnet protocols (Coordination Game, Shillbot content marketplace, video generation) plus universal opportunity discovery, MCP-ecosystem search, on-chain agent reputation, and a wallet-addressed agent inbox (`agent_send_message`/`agent_get_messages` — verify your wallet with `agent_verify_wallet` first). Cross-chain/EVM game tools are testnet-gated and unlisted until mainnet (still callable by name). **Non-custodial:** every state-changing tool returns an unsigned transaction you sign locally. The server never holds keys. Install: `claude mcp add --transport http swarm-tips https://mcp.swarm.tips/mcp` (or point any MCP client at `https://mcp.swarm.tips/mcp`, Streamable HTTP). ``` The financial workflow subsequently instructs the agent to sign transactions returned by that service: ```markdown 3. **Claim:** for a Shillbot task — `shillbot_get_task_details` (read the brief, blocklist, brand voice FIRST), then `shillbot_claim_task` → sign → `shillbot_submit_tx` (action `claim`). 4. **Do the work + submit:** produce the content (tip: `generate_video` output can be submitted to a video task), then `shillbot_submit_work` with the content_id → sign → `shillbot_submit_tx` (action `submit`). 5. **GET PAID — do not skip these:** after the oracle window, `shillbot_verify_task` (records the Switchboard-attested score) → sign → submit, then `shillbot_finalize_task` (releases escrow to you after the challenge window) → sign → submit. Work that is never verified+finalized never pays out. 6. **Or let the server drive:** `shillbot ...[truncated 3387 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. **Pin and verify the remote implementation** - Pin the Skill to a reviewed MCP server release or immutable deployment identifier. - Publish signed release manifests and verify them before enabling financial tools. - Treat unexpected changes to `tools/list` as a security failure rather than accepting the remote inventory as automatically authoritative. - Remove or block tools that are callable but intentionally omitted from the advertised inventory. 2. **Decode and validate every transaction before signing** - Deserialize each returned transaction locally. - Verify the expected network, recent blockhash, fee payer, program IDs, account list, instruction data, recipient addresses, token mints, amounts, fees, and signer requirements. - Reject unknown programs, extra instructions, writable accounts not required by the requested operation, unexpected address lookup tables, and authority or delegation changes. - Compare decoded instructions with a locally defined template for the requested action. 3. **Apply strict policy controls** - Maintain allowlists of approved Solana program IDs, token mints, escrow accounts, and recipient addresses. - Enforce maximum amounts for transfers, stakes, campaign funding, and fees. - Require the wallet address and all task or campaign identifiers to match the initiating request. - Prevent dispatcher responses from invoking tools outside a locally approved state machine. 4. **Require informed approval** - Display a human-readable transaction summary before every signature. - Require explicit user confirmation for transfers, staking, spending, token approvals, authority changes, and interactions with previously unseen programs. - Do not permit `shillbot_complete_task` or another remote dispatcher to trigger signing autonomously. 5. **Simulate and monitor transactions** - Simulate transactions using an independently selected RPC endpoint before signi ...[truncated 593 chars]
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.