Security audit

openclaw skill for swarms ai

Security checks for vulnerabilities and agentic risk

Overview

This skill is a Swarms API guide, but it documents workflows that send Solana wallet private keys to remote services, which is unsafe enough to require review before installation.

Review this skill carefully before installing or using its token and ATP sections. Do not paste a funded or primary Solana wallet private key into these examples or send it to a remote API; prefer client-side wallet signing, testnet or low-balance burner wallets, and scoped authorization flows. Ordinary Swarms API examples still send your prompts and API key to Swarms, which is expected for the service but should be used only with data you are comfortable sharing.

A.I.G

Vulnerability Patterns

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
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 (2)

T09 · Insecure Skill Coding Practices

Error

Location: SKILL.md:92
Finding: Token Launch API Requires Transmission of a Solana Wallet Private Key<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:92-100`; supporting API specification at `references/marketplace.md:25-38` **Vulnerability Type**: Transmission of full wallet signing authority to a remote service **Risk Level**: High ### Complete Vulnerable Code Snippet From `SKILL.md:92-100`: ```python payload = { "name": "My Agent Token", "description": "Agent description", "ticker": "MAG", "private_key": "[1,2,3,...]" # Solana wallet private key } response = requests.post( "https://swarms.world/api/token/launch", ``` The corresponding API specification in `references/marketplace.md:25-38` states: ```markdown ## Token Launch API **POST** `https://swarms.world/api/token/launch` Creates agent listing + launches Solana token in single request. ### Required Fields | Field | Type | Description | |-------|------|-------------| | `name` | string | Agent display name (min 2 chars) | | `description` | string | Agent description | | `ticker` | string | Token symbol (1-10 chars, letters+numbers) | | `private_key` | string | Solana wallet key (JSON array, base64, or base58) | ``` ### Technical Analysis The documented token-launch workflow places a Solana wallet private key directly in an HTTP request body sent to `https://swarms.world/api/token/launch`. A private key provides full signing authority for its associated wallet and is not equivalent to a narrowly scoped API credential. HTTPS protects the request while it is in transit, but it does not protect the key from the receiving application, reverse proxies, request logging, observability systems, crash reports, compromised infrastructure, or personnel with access to server-side telemetry. The receiving service must process the plaintext key to use it, creating an avoidable high-value secret exposure. This behavior exceeds minimum privilege. A token-launch service only needs the user's public key and authorization for the specific transaction. It can construct an unsign ...[truncated 1199 chars]
Remediation: <![CDATA[ ## Remediation Suggestions - Remove the `private_key` field from the token-launch API and all examples. - Have the server construct an unsigned or partially signed Solana transaction. - Return the transaction to the client for signing through a local wallet adapter, hardware wallet, or trusted local signer. - Submit only the signed transaction or signature to the remote service. - Use public keys and narrowly scoped authorization proofs instead of wallet secrets. - Reject requests containing private keys to prevent accidental disclosure. - Redact sensitive fields from request logs, traces, error reports, and monitoring systems. - Add explicit documentation warning users never to submit a funded wallet's seed phrase or private key to any remote API. - Advise existing users to rotate any wallet key previously submitted through this workflow and transfer remaining assets to a newly generated wallet. ]]>

T09 · Insecure Skill Coding Practices

Error

Location: references/atp-protocol.md:45
Finding: ATP Payment Protocol Sends Wallet Private Keys to Remote Endpoints<![CDATA[ ## Vulnerability Details **File Location**: `references/atp-protocol.md:10-16` and `references/atp-protocol.md:45-57` **Vulnerability Type**: Sensitive credential exposure through HTTP headers and remote payment settlement **Risk Level**: High ### Complete Vulnerable Code Snippet The documented request flow at `references/atp-protocol.md:10-16` states: ```markdown ## Request Flow 1. Client sends request with wallet private key in header 2. Endpoint processes, returns response with usage data 3. Middleware encrypts response, sends payment request 4. Settlement service calculates cost, creates split transaction on Solana 5. After on-chain confirmation, response is decrypted and returned ``` The client example at `references/atp-protocol.md:45-57` is: ```python from atp.client import ATPClient client = ATPClient( wallet_private_key="[1,2,3,...]", settlement_service_url="https://facilitator.swarms.world" ) response = await client.post( url="https://api.example.com/v1/chat", json={"message": "Hello!"} ) ``` The server configuration also identifies the sensitive header at `references/atp-protocol.md:30-42`: ```python app.add_middleware( ATPSettlementMiddleware, allowed_endpoints=["/v1/chat"], input_cost_per_million_usd=10.0, output_cost_per_million_usd=30.0, recipient_pubkey="YourSolanaWallet", payment_token=PaymentToken.SOL, wallet_private_key_header="x-wallet-private-key", require_wallet=True, settlement_service_url="https://facilitator.swarms.world", settlement_timeout=300.0, fail_on_settlement_error=False, ) ``` ### Technical Analysis The ATP protocol explicitly sends a wallet private key in the `x-wallet-private-key` request header and configures a remote facilitator to perform settlement. This exposes unrestricted signing authority to the protected endpoint, its middleware, and potentially the facilitator. Secrets placed in headers remain vulnerable to collection by reverse proxies ...[truncated 1958 chars]
Remediation: <![CDATA[ ## Remediation Suggestions - Eliminate the `x-wallet-private-key` header and the `wallet_private_key` client parameter. - Keep all private keys inside a local wallet, hardware wallet, or dedicated local signing service. - Have the facilitator construct a transaction or typed payment authorization and return it for client-side review and signing. - Send only the public key, signed authorization, signed transaction, nonce, expiration time, and narrowly bounded payment amount to remote services. - Bind each authorization to the intended recipient, asset, maximum amount, network, request identifier, and short expiration period to prevent replay or misuse. - Implement nonce tracking and reject expired or replayed authorizations. - Redact authorization headers and payment metadata from logs and distributed traces. - Fail closed when settlement fails rather than granting paid content by default where payment enforcement is required. - Clearly warn users that previously transmitted wallet keys must be treated as compromised and should be rotated. - Use testnet wallets with minimal funds during development and integration testing. ]]>

SkillSpector

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands

Findings (18)

Missing User Warnings

High

Confidence: 99% confidence
Finding: The request flow instructs clients to send a wallet private key in an HTTP header, which is an extremely sensitive secret that can be exposed through reverse proxies, middleware, access logs, tracing systems, browser tooling, and upstream services. Even though the doc says not to log keys, the design itself normalizes transmission of raw private keys and does not provide a strong warning or a safer alternative.

External Transmission

Medium

Category: Data Exfiltration
Content: "task": "Your task here" } response = requests.post( "https://api.swarms.world/v1/agent/completions", headers={"x-api-key": API_KEY, "Content-Type": "application/json"}, json=payload
Confidence: 60% confidence
Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium

Category: Data Exfiltration
Content: "task": "Your task here" } response = requests.post( "https://api.swarms.world/v1/agent/completions", headers={"x-api-key": API_KEY, "Content-Type": "application/json"}, json=payload
Confidence: 60% confidence
Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium

Category: Data Exfiltration
Content: "task": "Your task here" } response = requests.post( "https://api.swarms.world/v1/agent/completions", headers={"x-api-key": API_KEY, "Content-Type": "application/json"}, json=payload
Confidence: 70% confidence
Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium

Category: Data Exfiltration
Content: "task": "Your task here" } response = requests.post( "https://api.swarms.world/v1/swarm/completions", headers={"x-api-key": API_KEY, "Content-Type": "application/json"}, json=payload
Confidence: 70% confidence
Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Missing User Warnings

Medium

Confidence: 97% confidence
Finding: The token launch example explicitly instructs users to place a Solana wallet private key into the JSON payload sent to a remote service, but it does not include a strong warning about the sensitivity of that secret or safer handling guidance. In a skill meant to be copied by users, this normalizes exfiltration of a high-value credential and can directly lead to wallet compromise or irreversible fund loss if users paste real private keys.

External Transmission

Medium

Category: Data Exfiltration
Content: "private_key": "[1,2,3,...]" # Solana wallet private key } response = requests.post( "https://swarms.world/api/token/launch", headers={"Authorization": "Bearer API_KEY", "Content-Type": "application/json"}, json=payload
Confidence: 98% confidence
Finding: This duplicate finding points to the token launch request that includes a private key in the JSON body. The danger is not merely the outbound request, but that the example encourages transmission of a wallet secret to a third party, which can enable full wallet takeover and irreversible blockchain asset loss.

External Transmission

Medium

Category: Data Exfiltration
Content: "private_key": "[1,2,3,...]" # Solana wallet private key } response = requests.post( "https://swarms.world/api/token/launch", headers={"Authorization": "Bearer API_KEY", "Content-Type": "application/json"}, json=payload
Confidence: 98% confidence
Finding: This duplicate finding points to the token launch request that includes a private key in the JSON body. The danger is not merely the outbound request, but that the example encourages transmission of a wallet secret to a third party, which can enable full wallet takeover and irreversible blockchain asset loss.

External Transmission

Medium

Category: Data Exfiltration
Content: ## Health Check ``` GET https://api.swarms.world/health ``` ## Conversation History
Confidence: 50% confidence
Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium

Category: Data Exfiltration
Content: ## Health Check ``` GET https://api.swarms.world/health ``` ## Conversation History
Confidence: 50% confidence
Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium

Category: Data Exfiltration
Content: ## Health Check ``` GET https://api.swarms.world/health ``` ## Conversation History
Confidence: 50% confidence
Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium

Category: Data Exfiltration
Content: ) response = await client.post( url="https://api.example.com/v1/chat", json={"message": "Hello!"} ) ```
Confidence: 50% confidence
Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Intent-Code Divergence

Medium

Confidence: 94% confidence
Finding: The documentation explicitly recommends `fail_on_settlement_error=False`, and the server example also shows that setting. In this payment-gating design, graceful degradation can result in protected responses being delivered even when settlement fails, enabling unpaid access to metered agent services and undermining the core security and billing control.

Missing User Warnings

Medium

Confidence: 93% confidence
Finding: The documentation explicitly instructs users to send a Solana wallet private key to a remote API, but provides no warning about the extreme sensitivity of that secret, no guidance on secure handling, and no indication of safer alternatives. In a multi-agent/orchestration skill, this is especially dangerous because developers may automate the flow, log request payloads, or pass secrets through agents and toolchains, increasing the likelihood of key compromise and irreversible wallet theft.

External Transmission

Medium

Category: Data Exfiltration
Content: "task": "Your task" } response = requests.post( f"{BASE_URL}/v1/agent/completions", headers=headers, json=payload, stream=True )
Confidence: 70% confidence
Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Missing User Warnings

Medium

Confidence: 93% confidence
Finding: The documentation explicitly states that autonomous sub-agents may be given file operation tools such as create_file, update_file, read_file, list_directory, and delete_file, but it provides no warning about the risks of unintended file access, modification, or deletion. In a multi-agent delegation context, this is more dangerous because spawned sub-agents can amplify mistakes or unsafe prompts across multiple concurrent tasks, increasing the chance of destructive or overbroad filesystem actions.

Missing User Warnings

Low

Confidence: 80% confidence
Finding: This markdown file includes example code that transmits credentials via request headers to a remote endpoint, but the surrounding documentation does not warn users that the example performs a network call carrying an API key. Under the markdown-file criteria for missing user warnings, examples that affect privacy or system integrity should disclose such behavior.

Vague Triggers

Low

Confidence: 86% confidence
Finding: This markdown file defines a tool with the description "Search for information on a topic" and parameter text "Search query," but it does not specify boundaries, exclusions, or narrower trigger conditions. In documentation for tool definitions, this kind of broad natural-language description can encourage overly general invocation behavior because almost any user request could be interpreted as matching the tool.

Static analysis

No suspicious patterns detected.