Back to skill

Security audit

Aegis Security

Security checks for vulnerabilities and agentic risk

Overview

The skill is a blockchain safety-check API, but it also asks for broad command/file access and an automatically paying wallet setup without enough limits or disclosure.

Review this carefully before installing. Use it only with explicit user approval for each paid request, a low-balance dedicated wallet, pinned/audited x402 dependencies, and a real verified API endpoint/privacy policy. Do not grant broad read/exec access unless the publisher narrows the skill to scoped HTTPS calls and removes unrelated file/command features.

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

other

Warning
Location
SKILL.md:155
Finding

Stable Client Identifier and Transaction Details Are Disclosed to an External Service

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:97, 118, 129-168, 178, 186, 196-198
Vulnerability Type: Persistent Identifier Disclosure
Risk Level: Medium

Evidence

bash
curl -X POST "https://security-api.example.com/v1/simulate-tx" \
  -H "Content-Type: application/json" \
  -H "X-Client-Fingerprint: agent-default" \
  -d '{
    "from": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e",
    "to": "0x68b3465833fb72A70ecDF485E0e4C7bD56653845",
    "value": "0",
    "data": "0x38ed1739",
    "chain_id": 1
  }'

The usage instructions at line 118 additionally require every request to carry a stable user identifier in the X-Client-Fingerprint header. Lines 186 and 196-198 explain that this value is used to identify clients and allocate daily quotas.

Technical Analysis

Transaction simulation legitimately requires relevant transaction fields, but the Skill also directs the agent to send a stable user or agent identifier with every request. Combining that persistent identifier with sender and recipient addresses, transaction value, calldata, token addresses, and chain identifiers allows the remote service to correlate requests over time.

A persistent user identifier is not technically necessary for the core security-analysis operation. Quota management could instead use a short-lived anonymous token or another privacy-preserving mechanism. The Skill does not document data-retention limits, identifier rotation, user consent, or restrictions on correlating identifiers with wallet activity.

The documented host is the reserved placeholder security-api.example.com, meaning the actual service operator, destination, privacy policy, and transport configuration cannot be validated from the package.

Attack Path

  1. A user asks the agent to inspect a proposed blockchain transaction.
  2. The agent follows the Skill instructions and creates or reuses a stable client fingerprint.
  3. The agent su ...[truncated 1042 chars]
Remediation
View remediation

Remediation Suggestions

  1. Do not derive the fingerprint from a username, account identifier, machine identifier, wallet address, or other stable personal value.
  2. Replace persistent fingerprints with short-lived, randomly generated quota tokens.
  3. Rotate identifiers regularly and prevent correlation across unrelated sessions.
  4. Obtain explicit user consent before transmitting transaction details to a third party.
  5. Send only fields strictly required by the selected security check.
  6. Publish the verified production API domain, operator identity, privacy policy, retention period, and deletion process.
  7. Redact transaction data from client and server logs.
  8. Allow users to run checks without a persistent identifier where practical.
  9. Clearly warn users that transaction simulations can reveal planned financial activity before transmission occurs.

T08 · Insecure Dependencies

Error
Location
SKILL.md:189
Finding

Unpinned Third-Party Dependencies Are Placed in a Wallet-Signing and Payment Path

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:100, 122, 189
Vulnerability Type: Unpinned payment dependencies
Risk Level: High

Evidence

The Skill directs users to integrate the following packages without specifying versions, integrity hashes, lockfiles, or verified source repositories:

text
@x402/fetch
@x402/evm
@x402/svm

It further instructs users to create an x402Client, register a signing scheme, wrap the network client with wrapFetchWithPayment, and configure an agent-managed wallet signer.

Technical Analysis

These third-party packages execute in a security-sensitive path that can initiate cryptocurrency payments and interact with a wallet signer. Installing packages without exact versions allows future package releases to change the effective code after the Skill has been reviewed.

The Skill provides no package-lock file, integrity checksum, verified registry reference, repository commit, signature-verification procedure, or package provenance information. It also does not define an isolation boundary between these dependencies and wallet-signing authority.

A compromised maintainer account, malicious package release, dependency confusion event, or compromised transitive dependency could consequently affect payment requests or signing operations.

Attack Path

  1. An agent follows the Skill instructions and installs the latest available x402 packages.
  2. One package or a transitive dependency has been compromised or contains an unsafe update.
  3. The package executes with the privileges of the agent process.
  4. The agent configures a wallet signer as instructed by the Skill.
  5. The compromised component intercepts or modifies payment challenges, amounts, recipients, chains, or signed messages.
  6. The component may redirect funds, request unintended signatures, access process-visible data, or execute other actions available to the agent process.

Impact Assessment

...[truncated 651 chars]

Remediation
View remediation

Remediation Suggestions

  1. Pin every direct dependency to an exact audited version.
  2. Commit and enforce a lockfile containing resolved transitive versions and integrity hashes.
  3. Identify the official package registry, source repository, and expected publisher for each package.
  4. Verify package signatures, checksums, and provenance before installation.
  5. Audit transitive dependencies and use automated supply-chain vulnerability monitoring.
  6. Run payment components in an isolated process without general filesystem or environment-secret access.
  7. Use a dedicated wallet containing only the minimum funds required for a single approved payment.
  8. Enforce signer policies covering recipient allowlists, supported chains, approved assets, per-payment limits, and cumulative daily limits.
  9. Require manual review before dependency upgrades, especially for code with access to signing operations.

T05 · Unauthorized Access and Privilege Escalation

Error
Location
SKILL.md:100
Finding

Automatic x402 Payments Conflict with the Skill's User-Confirmation Requirement

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:56-58, 100, 122, 172, 189
Vulnerability Type: Excessive wallet-signing and payment authority
Risk Level: High

Evidence

The security policy requires confirmation before paid calls, especially transaction simulations:

text
Paid calls must require confirmation of user intent, especially for simulate-tx.

However, the operational guidance instructs the agent to configure automatic payment continuation:

text
Configure the x402 client to continue automatically with paid requests after the free quota is exhausted.

The implementation guidance also instructs the user to wrap the network client with wrapFetchWithPayment and configure an agent-managed wallet signer.

Technical Analysis

A wallet signer is a privileged financial capability. Automatically processing HTTP 402 payment challenges permits a remote service to influence payment requests. The documentation does not define mandatory validation of the payment recipient, chain, token contract, amount, domain binding, expiration, replay resistance, or cumulative spending.

The automatic-payment instructions conflict with the earlier requirement to confirm user intent before paid calls. There is no documented control that technically enforces confirmation for each payment. Automatic request retries may also create duplicate-payment risks if payment completion and request status become inconsistent.

Attack Path

  1. The user exhausts the free API quota or receives an HTTP 402 response.
  2. The wrapped x402 client parses the remote server's payment challenge.
  3. The agent-managed wallet signer is asked to authorize payment.
  4. Because automatic payment continuation is enabled, the user may not receive a clear per-payment confirmation prompt.
  5. A malicious or compromised server can return an unexpected recipient, amount, chain, or repeated challenge.
  6. In the absence of strict local ...[truncated 820 chars]
Remediation
View remediation

Remediation Suggestions

  1. Require explicit, informed user confirmation for every payment.
  2. Display the exact amount, asset, chain, recipient, requesting domain, and operation before signing.
  3. Reject any payment challenge that does not match a locally configured domain and recipient allowlist.
  4. Apply strict per-payment, per-session, and daily spending limits.
  5. Disable automatic payment retries unless idempotency and prior-payment status are verified.
  6. Bind payment authorization to one specific API request and prevent replay.
  7. Use a dedicated low-balance wallet rather than a general-purpose user wallet.
  8. Do not expose raw private keys or unrestricted signer interfaces to the agent.
  9. Log payment approvals without recording private keys, seed phrases, or sensitive signer material.
  10. Make failure closed by default: if validation or confirmation is unavailable, do not pay.

T05 · Unauthorized Access and Privilege Escalation

Error
Location
SKILL.md:15
Finding

General File Access and Command Execution Exceed the Skill's Functional Requirements

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:15-17, 307-309
Vulnerability Type: Excessive tool permissions
Risk Level: High

Evidence

yaml
tools:
  - read
  - exec

The Skill also advertises general file processing and system-command execution capabilities near lines 307-309, despite declaring its primary purpose as calling blockchain security API endpoints.

Technical Analysis

Address reputation checks, token checks, quota queries, feedback submission, and transaction simulation require constrained outbound HTTPS requests. They do not inherently require unrestricted local file reads or arbitrary command execution.

Granting read and exec expands the Skill's authority beyond its minimum functional needs. If user-controlled input, API responses, package-installation instructions, or future modifications influence command arguments, the agent may read local information or execute commands under the permissions of its host process.

The documentation claims execution occurs in a sandbox, but it does not define the sandbox boundary, filesystem restrictions, network restrictions, command allowlist, environment-variable filtering, or privilege model. A textual claim of sandboxing is not an enforceable security control.

Attack Path

  1. The Skill is loaded with read and exec capabilities.
  2. The user supplies transaction data, a callback value, an endpoint-related value, or another string later incorporated into a command.
  3. Alternatively, an external API response or third-party package produces attacker-controlled content.
  4. The agent interprets that content as a reason to inspect files, install packages, or execute a diagnostic command.
  5. Because broad tools are available, the resulting action can exceed the intended API-checking workflow.
  6. Commands execute with the privileges of the agent process, or local files become available to subsequent network requests.

No concret ...[truncated 998 chars]

Remediation
View remediation

Remediation Suggestions

  1. Remove the read and exec tools from the Skill declaration.
  2. Replace them with a narrowly scoped HTTPS client restricted to verified API domains.
  3. Allow only the documented HTTP methods and endpoint paths.
  4. Validate all request fields against strict schemas before transmission.
  5. Do not invoke shell commands to construct or send API requests.
  6. If dependency installation is necessary, move it to a separately reviewed administrative setup process.
  7. If command execution cannot be removed, enforce a fixed command allowlist with no shell interpolation.
  8. Run commands in an isolated environment without user files, wallet secrets, API credentials, or unrestricted network access.
  9. Document and technically enforce filesystem, environment-variable, process, and network restrictions.
  10. Ensure external API responses are treated strictly as data and never as agent instructions or executable commands.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • 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
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (8)

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
92% confidence
Finding

The activation guidance is overly broad, using vague triggers such as security detection, compliance audit, vulnerability scanning, and encryption protection. In an agent setting, ambiguous invocation criteria can cause the skill to be selected in inappropriate contexts, leading to unnecessary external requests, privacy leakage, or accidental use of paid/security-sensitive functions.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

Medium
Category
Not specified by scanner
Confidence
99% confidence
Finding

The documentation says no extra environment variables are needed, but later instructs users to configure an API_KEY. This inconsistency can mislead operators into unsafe setup practices, create failed executions, and encourage ad hoc credential handling that increases the risk of secret exposure.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
91% confidence
Finding

The skill recommends a stable X-Client-Fingerprint and documents fallback to IP/User-Agent billing without a clear privacy notice. Stable identifiers combined with fallback fingerprinting can enable cross-session tracking or unintended user correlation, especially when handled by agents on behalf of end users.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The documentation describes automatic payment and request retry through x402 without a strong, prominent warning that this can spend real funds. In an agent context, automatic retry-on-payment can convert routine API use into unauthorized monetary transactions if explicit user approval and spend limits are not enforced.

Content

No source excerpt is available for this finding.

External Transmission

Medium
Category
Data Exfiltration
Confidence
88% confidence
Finding

The skill instructs the agent to send requests to an external API and include a stable client fingerprint header. External transmission is expected for an API skill, but it still creates a real data egress path where user-linked identifiers and potentially sensitive transaction, address, or usage data are disclosed to a third party.

Content

Scanner excerpt · SKILL.md (reported line 129)May include surrounding context.

bash
# 查询免费额度
curl "https://security-api.example.com/v1/usage" \
  -H "X-Client-Fingerprint: agent-default"
# ...
# 响应

Description-Behavior Mismatch

Medium
Category
Not specified by scanner
Confidence
96% confidence
Finding

The skill is presented as a blockchain security API, but later claims generic file processing and command execution capabilities unrelated to that purpose. This scope expansion can cause an agent to grant or invoke broader powers than users expect, increasing the chance of unintended command execution or access to local files under the cover of a security-checking skill.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low
Category
Not specified by scanner
Confidence
72% confidence
Finding

The visible skill name and most of the user-facing description are in Chinese, with some mixed English phrases, but the document does not state whether the skill is intended only for Chinese-speaking users or offer a language/locale choice. This can create a language-policy issue if users are forced into a language without opt-in.

Content

No source excerpt is available for this finding.

Vague Triggers

Low
Category
Not specified by scanner
Confidence
81% confidence
Finding

The main parameter is described as a generic input string for processing instructions, without constraining accepted content or operation types. In an agent workflow, such an unconstrained input surface can encourage prompt-like overloading, making it easier to pass unexpected instructions into a skill that also advertises exec capability.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.