Back to skill

Security audit

Crypto Sniper Bot

Security checks for vulnerabilities and agentic risk

Overview

This crypto trading skill is coherent in purpose, but it has serious Review concerns because wallet secrets and live trading controls are exposed through weak authorization and plaintext storage.

Review this skill carefully before installing or running it. Use only a dedicated low-balance wallet, keep the server bound to localhost or otherwise firewalled, do not expose it to a network, rotate any copied SkillPay or notification credentials, and require real authentication plus redacted status responses before using live funds.

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • 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
Findings (4)

T05 · Unauthorized Access and Privilege Escalation

Error
Location
src/index.js:14
Finding
Universal Test-Signature Bypass Exposes Wallet Secrets and Trading Controls<![CDATA[ ## Vulnerability Details **File Location**: `src/index.js:14-36`, `src/index.js:107-113`, `src/utils/sniperBot.js:164-173` **Vulnerability Type**: Authentication bypass and sensitive information disclosure **Risk Level**: Critical ### Vulnerable Code ```javascript // src/index.js:14-36 app.use(async (req, res, next) => { if (req.path === '/health') return next(); // For testing, allow requests with test signature const paymentHeader = req.headers['x-skillpay-signature']; if (!paymentHeader) { return res.status(402).json({ error: 'Payment required', message: 'Please include SkillPay payment signature' }); } // In production, verify with SkillPay API // For now, accept test signatures if (paymentHeader === 'test_signature') { return next(); } return res.status(402).json({ error: 'Invalid payment', message: 'Payment verification failed' }); }); ``` ```javascript // src/index.js:107-113 app.get('/status', (req, res) => { try { const status = sniperBot.getStatus(); res.json(status); } catch (error) { res.status(500).json({ success: false, error: error.message }); } }); ``` ```javascript // src/utils/sniperBot.js:164-173 getStatus() { return { isRunning: this.isRunning, openPositions: positionManager.getPositionCount(), positions: positionManager.getOpenPositions(), totalPnL: positionManager.getTotalPnL(), winRate: positionManager.getWinRate(), config: configManager.getConfig() }; } ``` ### Technical Analysis All API routes except `/health` are nominally protected by a payment-signature middleware. However, the middleware accepts the constant value `test_signature` without cryptographic verification or a call to the implemented `SkillPayment.verifyPayment()` method. Because this bypass value is visible in the distributed source, it is not a secret and provides no meaningful authentication. A caller who can reach the Express service ...[truncated 2147 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove the `test_signature` bypass from production code. 2. Invoke a real authentication or payment-verification mechanism for every protected request. 3. Bind authorization to a user, payment transaction, timestamp, nonce, request method, and request path. 4. Prevent replay by storing consumed transaction IDs or validating short-lived signed requests. 5. Return only explicitly selected, non-sensitive status fields. Never serialize the internal configuration object. 6. Implement a redaction layer that removes private keys, passwords, API tokens, and webhook credentials from every response and log. 7. Bind the service to `127.0.0.1` by default unless remote access is explicitly required. 8. Require TLS through a properly configured reverse proxy when remote access is enabled. 9. Add rate limiting, request-size limits, audit logging, and authorization checks specific to administrative endpoints. 10. Rotate the configured wallet and notification credentials if the affected service has ever been remotely reachable. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
src/utils/configManager.js:18
Finding
Wallet and Notification Credentials Are Persisted in Plaintext<![CDATA[ ## Vulnerability Details **File Location**: `src/utils/configManager.js:18-55` **Vulnerability Type**: Plaintext sensitive-data storage **Risk Level**: High ### Vulnerable Code ```javascript loadConfig() { if (fs.existsSync(this.configPath)) { return JSON.parse(fs.readFileSync(this.configPath, 'utf8')); } return { walletPrivateKey: process.env.WALLET_PRIVATE_KEY || '', buyAmount: parseFloat(process.env.BUY_AMOUNT) || 0.1, takeProfitPercent: parseFloat(process.env.TAKE_PROFIT_PERCENT) || 50, stopLossPercent: parseFloat(process.env.STOP_LOSS_PERCENT) || 30, maxPositions: parseInt(process.env.MAX_POSITIONS) || 10, minLiquidity: parseFloat(process.env.MIN_LIQUIDITY) || 1000, minHolders: parseInt(process.env.MIN_HOLDERS) || 10, maxHolderConcentration: parseFloat(process.env.MAX_HOLDER_CONCENTRATION) || 50, botActive: false, notifications: { telegram: { enabled: !!process.env.TELEGRAM_BOT_TOKEN, botToken: process.env.TELEGRAM_BOT_TOKEN || '', chatId: process.env.TELEGRAM_CHAT_ID || '' }, discord: { enabled: !!process.env.DISCORD_WEBHOOK_URL, webhookUrl: process.env.DISCORD_WEBHOOK_URL || '' }, email: { enabled: !!process.env.EMAIL_USER, host: process.env.EMAIL_HOST || 'smtp.gmail.com', user: process.env.EMAIL_USER || '', pass: process.env.EMAIL_PASS || '', to: process.env.EMAIL_TO || '' } } }; } saveConfig() { fs.writeFileSync(this.configPath, JSON.stringify(this.config, null, 2)); } ``` ### Technical Analysis The configuration object contains a wallet private key and multiple notification credentials. `saveConfig()` serializes the entire object directly to `data/config.json` without encryption, field-level protection, or an explicit restrictive file mode. Consequently, credentials originally supplied through environment variables or the `/configure` and `/notifications` endpoint ...[truncated 1360 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Do not persist wallet private keys in the general configuration file. 2. Use a hardware wallet, remote signer, operating-system keychain, cloud KMS, or dedicated secret manager. 3. If local storage is unavoidable, encrypt sensitive fields with a key stored separately from the encrypted data. 4. Create configuration files with an explicit restrictive mode such as `0600`. 5. Separate non-sensitive trading settings from secret material. 6. Avoid copying secrets from environment variables into persistent JSON files. 7. Add schema-based serialization that excludes private keys, passwords, bot tokens, and webhook credentials. 8. Ensure backups and logs do not contain historical plaintext copies. 9. Rotate all credentials after migrating away from plaintext storage. 10. Update the documentation so its security claims accurately reflect the implementation. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
src/trading/tradingEngine.js:136
Finding
Opaque Remote Swap Transactions Are Signed Without Instruction Validation<![CDATA[ ## Vulnerability Details **File Location**: `src/trading/tradingEngine.js:136-187` **Vulnerability Type**: Unsafe transaction signing across a remote trust boundary **Risk Level**: High ### Vulnerable Code ```javascript async getJupiterSwapTransaction(quote) { try { const response = await axios.post( `${this.jupiterUrl}/swap`, { quoteResponse: quote, userPublicKey: this.wallet.publicKey.toString(), wrapAndUnwrapSol: true, dynamicComputeUnitLimit: true, prioritizationFeeLamports: 'auto' }, { headers: { 'Content-Type': 'application/json' }, timeout: 10000 } ); return response.data.swapTransaction; } catch (error) { console.error('Jupiter swap transaction error:', error.message); return null; } } /** * Execute Solana transaction */ async executeTransaction(swapTransactionBase64) { try { // Deserialize transaction const swapTransactionBuf = Buffer.from(swapTransactionBase64, 'base64'); const transaction = VersionedTransaction.deserialize(swapTransactionBuf); // Sign transaction transaction.sign([this.wallet]); // Send transaction const txid = await this.solanaConnection.sendRawTransaction( transaction.serialize(), { skipPreflight: true, maxRetries: 2 } ); // Confirm transaction await this.solanaConnection.confirmTransaction(txid, 'confirmed'); console.log('Transaction confirmed:', txid); return txid; } catch (error) { console.error('Transaction execution error:', error.message); throw error; } } ``` ### Technical Analysis The application asks a remote API to construct a serialized Solana transaction. It then base64-decodes, deserializes, signs, and broadcasts the returned transaction. Before signing, the implementation does not verify: - Invoked program IDs - Source and destination accounts - Input and output mint addresses - Maximum in ...[truncated 2063 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Decode and inspect every transaction instruction before signing. 2. Maintain strict allowlists for expected Jupiter, SPL Token, associated-token, compute-budget, and system program IDs. 3. Verify that all source, destination, mint, and authority accounts match the requested trade. 4. Enforce an exact maximum input amount and a minimum output amount derived from the approved quote. 5. Reject account closure, authority modification, unrelated transfers, or unknown instructions. 6. Resolve and validate versioned-transaction address lookup tables before approval. 7. Recalculate transaction intent locally rather than trusting descriptive response fields. 8. Enable preflight simulation and inspect balance changes and program logs before broadcasting. 9. Apply wallet-level transaction and daily spending limits. 10. Prefer locally constructed transactions or a constrained signer that enforces policy independently of application code. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
skill.json:14
Finding
Production-Shaped SkillPay API Credential Is Hard-Coded in Metadata<![CDATA[ ## Vulnerability Details **File Location**: `skill.json:14` **Vulnerability Type**: Hard-coded credential **Risk Level**: Medium ### Vulnerable Code ```json "apiKey": "sk_e390b52cb259fc4f4aa1489547a48375d72876acdee75de57101d9e0e833fcb7", ``` ### Technical Analysis The distributed Skill metadata contains a production-shaped API key in plaintext. Static review cannot establish whether the key is currently valid, expired, public by design, or restricted to non-sensitive operations. Nevertheless, embedding secret-shaped credentials in a source-controlled and distributed package is insecure because every recipient can extract and reuse the value. The credential is separate from `process.env.SKILLPAY_API_KEY`, which the runtime payment class expects. This mismatch also increases the likelihood of inconsistent credential handling and accidental exposure. ### Attack Path 1. An attacker downloads or reads the project package. 2. The attacker opens `skill.json` and extracts the API key. 3. If the key is valid and treated as confidential by SkillPay, the attacker submits it to associated API endpoints. 4. The attacker may consume services or impersonate the registered integration within the key’s granted scope. ### Impact Assessment If the value is active and privileged, possible impact includes: - Unauthorized use of SkillPay API operations - Consumption of paid quota or generation of charges - Impersonation of the Skill integration - Access to metadata or analytics available to the credential - Operational disruption if the provider revokes the exposed key The exact impact depends on the server-side permissions and restrictions assigned to the credential. ]]>
Remediation
<![CDATA[ ## Remediation Suggestions 1. Revoke and rotate the exposed credential if it is active. 2. Remove the key from `skill.json` and source-control history. 3. Load confidential credentials from a deployment secret manager or protected environment variable. 4. Ensure published Skill metadata contains only public identifiers. 5. Apply least-privilege scopes, usage limits, origin restrictions, and expiration to replacement credentials. 6. Add automated secret scanning to development and release pipelines. 7. Document whether any metadata credential is intentionally public; if so, use a clearly non-secret identifier rather than an `sk_`-style key. ]]>
Vulnerability Patterns
  • 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
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Findings (69)

Credential Access

High
Category
Privilege Escalation
Content
## Configuration

### Complete .env Example

```env
# Wallet Configuration
Confidence
60% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Intent-Code Divergence

High
Confidence
99% confidence
Finding
The guide claims .env files should never be committed, yet the example includes what appears to be a fully populated SkillPay API key rather than an obvious placeholder. Publishing a real secret in documentation can enable unauthorized use of the associated account, fraud, billing abuse, or compromise of linked services, and it undermines the document's own security guidance.

Intent-Code Divergence

High
Confidence
99% confidence
Finding
The skill’s security section claims private keys are never sent over the network, yet the documented /configure endpoint explicitly requires a walletPrivateKey in the request body. This contradiction is dangerous because users may trust false security assurances and transmit blockchain signing credentials to a service that can then spend all funds in that wallet if compromised or misused.

Known Vulnerable Dependency: axios==1.13.6 — 16 advisory(ies): CVE-2026-44494 (axios Vulnerable to Full Man-in-the-Middle via Prototype Pollution Gadget in `co); CVE-2026-44495 (axios Vulnerable to Credential Theft and Response Hijacking via Prototype Pollut); CVE-2025-62718 (Axios has a NO_PROXY Hostname Normalization Bypass that Leads to SSRF) +13 more

High
Category
Supply Chain
Confidence
96% confidence
Finding
The lockfile pins axios 1.13.6, and the reported advisories include SSRF/proxy bypass and prototype-pollution-related request manipulation issues. In a bot that likely makes outbound HTTP calls to exchanges, APIs, webhooks, or alerting services, a vulnerable HTTP client can enable request redirection, credential leakage, or abuse of trusted network paths.

Known Vulnerable Dependency: bigint-buffer==1.1.5 — 1 advisory(ies): CVE-2025-3194 (bigint-buffer Vulnerable to Buffer Overflow via toBigIntLE() Function)

High
Category
Supply Chain
Confidence
83% confidence
Finding
bigint-buffer 1.1.5 is flagged for a buffer overflow in integer conversion logic. Although this is a transitive dependency in Solana-related code and may only be reachable on specific parsing paths, malformed blockchain or externally supplied binary data could trigger crashes or undefined behavior in dependent components.

Known Vulnerable Dependency: brace-expansion==5.0.4 — 5 advisory(ies): CVE-2026-13149 (brace-expansion: DoS via exponential-time expansion of consecutive non-expanding); CVE-2026-33750 (brace-expansion: Zero-step sequence causes process hang and memory exhaustion); CVE-2026-45149 (brace-expansion: Large numeric range defeats documented `max` DoS protection) +2 more

High
Category
Supply Chain
Confidence
80% confidence
Finding
brace-expansion 5.0.4 has multiple DoS advisories related to pathological expansion behavior. It appears here as a development-time transitive dependency, so exploitation is less likely in production, but if build tools or file watching operate on attacker-influenced glob patterns, it can still hang CI or developer environments.

Known Vulnerable Dependency: form-data==4.0.5 — 1 advisory(ies): CVE-2026-12143 (form-data: CRLF injection in form-data via unescaped multipart field names and f)

High
Category
Supply Chain
Confidence
87% confidence
Finding
form-data 4.0.5 is reported vulnerable to CRLF injection via unescaped multipart names/filenames. If this bot constructs multipart requests using attacker-controlled fields or filenames, an attacker may manipulate HTTP payload structure, potentially enabling request smuggling or header injection against downstream services.

Known Vulnerable Dependency: ws==7.5.10 — 1 advisory(ies): CVE-2026-48779 (ws: Memory exhaustion DoS from tiny fragments and data chunks)

High
Category
Supply Chain
Confidence
84% confidence
Finding
ws 7.5.10 is flagged for memory exhaustion via fragmented frames/data chunks. This instance is pulled in through jayson, so if the application exposes or consumes websocket-based JSON-RPC with attacker-reachable peers, an adversary could cause resource exhaustion and process instability.

Known Vulnerable Dependency: lodash==4.17.23 — 2 advisory(ies): CVE-2025-13465 (lodash vulnerable to Prototype Pollution via array path bypass in `_.unset` and ); CVE-2021-23337 (lodash vulnerable to Code Injection via `_.template` imports key names)

High
Category
Supply Chain
Confidence
90% confidence
Finding
lodash 4.17.23 carries prototype pollution and template/code-injection advisories. In this lockfile it is a transitive library, and exploitability depends on the application using risky APIs such as _.template or merging untrusted object paths, but those classes of bugs can become serious if user-supplied data is processed dynamically.

Known Vulnerable Dependency: nodemailer==6.10.1 — 12 advisory(ies): CVE-2026-82661 (Nodemailer: CRLF injection in Nodemailer List-* header comments allows arbitrary); GHSA-2x7j-588g-ccc2 (Nodemailer: Quadratic (O(n²)) time complexity in addressparser allows remote den); GHSA-8m3c-c648-2xjj (Nodemailer: resolveContent() on a MailMessage bypasses disableFileAccess/disable) +9 more

High
Category
Supply Chain
Confidence
94% confidence
Finding
nodemailer 6.10.1 has multiple advisories including header injection, file/content access bypass, and parser-related DoS. In a bot that sends alerts or notifications, attacker-controlled email fields, attachments, or templated content could abuse these flaws to inject headers, access unintended resources, or disrupt service.

Known Vulnerable Dependency: path-to-regexp==0.1.12 — 1 advisory(ies): CVE-2024-45296 (path-to-regexp vulnerable to Regular Expression Denial of Service via multiple r)

High
Category
Supply Chain
Confidence
88% confidence
Finding
path-to-regexp 0.1.12 is a known ReDoS risk and is used by Express routing. If the bot exposes HTTP endpoints with crafted route matching scenarios, an attacker may be able to trigger excessive CPU usage through specially formed requests, degrading service availability.

Known Vulnerable Dependency: picomatch==2.3.1 — 2 advisory(ies): CVE-2026-33672 (Picomatch: Method Injection in POSIX Character Classes causes incorrect Glob Mat); CVE-2026-33671 (Picomatch has a ReDoS vulnerability via extglob quantifiers)

High
Category
Supply Chain
Confidence
80% confidence
Finding
picomatch 2.3.1 is flagged for glob-related injection/ReDoS issues, but here it is a dev-only transitive dependency used by tooling such as chokidar/nodemon. This makes production exploitability limited unless attacker-controlled patterns are fed into development or CI automation.

Known Vulnerable Dependency: undici==6.21.3 — 13 advisory(ies): CVE-2026-1525 (Undici has an HTTP Request/Response Smuggling issue); CVE-2026-6733 (undici vulnerable to HTTP response queue poisoning via keep-alive socket reuse); CVE-2026-1527 (Undici has CRLF Injection in undici via `upgrade` option) +10 more

High
Category
Supply Chain
Confidence
95% confidence
Finding
undici 6.21.3 is flagged for multiple high-severity HTTP parsing/smuggling/queue-poisoning issues. This package is used by discord.js-related components, so if the bot communicates heavily with remote APIs over persistent HTTP connections, these flaws could enable request confusion, credential leakage, or downstream protocol abuse.

Known Vulnerable Dependency: ws==8.19.0 — 2 advisory(ies): CVE-2026-45736 (ws: Uninitialized memory disclosure); CVE-2026-48779 (ws: Memory exhaustion DoS from tiny fragments and data chunks)

High
Category
Supply Chain
Confidence
92% confidence
Finding
ws 8.19.0 is flagged for both memory disclosure and memory exhaustion issues. This project includes multiple bot/networking libraries that may maintain websocket connections, so attacker-controlled or hostile peers could potentially trigger information leakage or denial of service through crafted websocket traffic.

Known Vulnerable Dependency: nodemailer==6.10.1 — 12 advisory(ies): CVE-2026-82661 (Nodemailer: CRLF injection in Nodemailer List-* header comments allows arbitrary); GHSA-2x7j-588g-ccc2 (Nodemailer: Quadratic (O(n²)) time complexity in addressparser allows remote den); GHSA-8m3c-c648-2xjj (Nodemailer: resolveContent() on a MailMessage bypasses disableFileAccess/disable) +9 more

High
Category
Supply Chain
Confidence
92% confidence
Finding
A known vulnerable nodemailer version is a true vulnerability because published advisories include issues such as CRLF/header injection and denial-of-service conditions. In this skill's context, the bot appears capable of unattended notifications and may incorporate external or user-controlled content into emails, making mail-layer vulnerabilities more dangerous than in a static offline tool.

Intent-Code Divergence

High
Confidence
99% confidence
Finding
The payment gate is effectively bypassable because any client that sends the hardcoded value `test_signature` is treated as paid, and there is no real verification with SkillPay despite comments implying production verification. In this skill context, the bypass is more dangerous because it exposes bot control endpoints such as configuration, start, stop, and history to unauthorized users, allowing misuse of a cryptocurrency trading bot.

Intent-Code Divergence

High
Confidence
99% confidence
Finding
The function signature and log message imply that only the caller-provided amount will be sold, but the implementation ignores that parameter and instead computes the sell amount from the wallet's full token balance. In a live trading skill, this can cause unintended liquidation of the user's entire position, leading to immediate financial loss and violating user intent in a security-sensitive operation.

Missing User Warnings

High
Confidence
96% confidence
Finding
The code initializes configuration from environment variables that include highly sensitive secrets such as a wallet private key, Telegram bot token, Discord webhook URL, and email credentials, then keeps them in the in-memory config object that is later persisted wholesale to disk. Because saveConfig() writes the entire config object to data/config.json, these secrets can be stored in plaintext on the local filesystem, increasing the risk of credential theft, wallet compromise, and unauthorized access if the file is read, copied, backed up, or committed accidentally.

Missing User Warnings

High
Confidence
98% confidence
Finding
saveConfig() writes the full configuration object directly to disk as formatted JSON without any redaction or access control logic. In this application context, the configuration contains financial and notification secrets, so plaintext local persistence materially increases exposure and can enable account takeover, message abuse, or direct theft of crypto assets if the file is accessed by another user, malware, backups, logs, or source control.

Credential Access

High
Category
Privilege Escalation
Content
if (!process.env.BITQUERY_API_KEY) {
      console.log('   ⚠️  Bitquery API key not configured - skipping four.meme test');
      console.log('   To test four.meme, add BITQUERY_API_KEY to .env');
    } else {
      console.log('   Attempting to fetch new tokens from four.meme...');
      const fourTokens = await fourMonitor.getNewTokens();
Confidence
60% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High
Category
Privilege Escalation
Content
if (!process.env.BITQUERY_API_KEY) {
      console.log('   ⚠️  Bitquery API key not configured - skipping four.meme test');
      console.log('   To test four.meme, add BITQUERY_API_KEY to .env');
    } else {
      console.log('   Attempting to fetch new tokens from four.meme...');
      const fourTokens = await fourMonitor.getNewTokens();
Confidence
60% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High
Category
Privilege Escalation
Content
if (!process.env.BITQUERY_API_KEY) {
      console.log('   ⚠️  Bitquery API key not configured - skipping four.meme test');
      console.log('   To test four.meme, add BITQUERY_API_KEY to .env');
    } else {
      console.log('   Attempting to fetch new tokens from four.meme...');
      const fourTokens = await fourMonitor.getNewTokens();
Confidence
60% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High
Category
Privilege Escalation
Content
if (!process.env.BITQUERY_API_KEY) {
      console.log('   ⚠️  Bitquery API key not configured - skipping four.meme test');
      console.log('   To test four.meme, add BITQUERY_API_KEY to .env');
    } else {
      console.log('   Attempting to fetch new tokens from four.meme...');
      const fourTokens = await fourMonitor.getNewTokens();
Confidence
60% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The .env example instructs users to configure highly sensitive values including a wallet private key, bot token, webhook URL, email credentials, and API keys in one block without prominent, immediate warnings about the consequences of leakage. In a crypto trading bot context, mishandling these secrets can directly lead to wallet theft, account takeover, spam/abuse of notification channels, and unauthorized trading activity.

Missing User Warnings

Medium
Confidence
89% confidence
Finding
The changelog announces real trading, live blockchain/API integrations, and required API keys/RPC endpoints, but provides no user-facing warning that the skill can perform live network activity and potentially financial actions on production infrastructure. In an agent-skill context, this omission can mislead users into enabling or updating a skill without understanding that it may interact with real markets, incur costs, expose credentials, or trigger unintended trades.