Trust Assessment
near-dca received a trust score of 65/100, placing it in the Caution category. This skill has some security considerations that users should review before deployment.
SkillShield's automated analysis identified 4 findings: 2 critical, 0 high, 0 medium, and 2 low severity. Key findings include Direct Exposure of Private Key in Action Parameters, Private Key Passed to Internal Swap Functions, Storage of Sensitive Financial Strategy Data.
The analysis covered 4 layers: Manifest Analysis, Static Code Analysis, Dependency Graph, LLM Behavioral Safety. The LLM Behavioral Safety layer scored lowest at 36/100, indicating areas for improvement.
Last analyzed on February 13, 2026 (commit 13146e6a). SkillShield performs automated 4-layer security analysis on AI skills and MCP servers.
Layer Breakdown
Behavioral Risk Signals
Security Findings4
| Severity | Finding | Layer | Location | |
|---|---|---|---|---|
| CRITICAL | Direct Exposure of Private Key in Action Parameters The `executePurchase` action explicitly accepts `private_key` as a parameter. Passing sensitive credentials like private keys directly through action parameters is a severe security risk. This means the private key would be exposed in the LLM's context, potentially logged, or visible in skill invocation traces, making it highly vulnerable to credential harvesting and unauthorized access. Even if the current implementations are mocks, the design pattern is fundamentally insecure. Never pass private keys or other sensitive credentials directly as action parameters. Instead, use secure credential management systems (e.g., environment variables, secure vaults, or a dedicated credential provider service) that the skill can access securely without exposing the key to the LLM or logs. The skill should only receive a reference or token to access the key, not the key itself. | LLM | actions/index.js:99 | |
| CRITICAL | Private Key Passed to Internal Swap Functions The `NEARIntegration.executeSwap` method and subsequent exchange `swap` implementations (e.g., `RefFinanceExchange.swap`, `JumboExchange.swap`) receive `privateKey` as a direct argument. This confirms the design flaw identified in `actions/index.js`, indicating that the private key is intended to be handled directly within the skill's core logic. This practice significantly increases the risk of the private key being compromised through various attack vectors, including memory inspection, logging, or vulnerabilities in the skill's processing. Refactor the credential handling. Instead of passing the private key, pass a secure identifier or use a pre-configured signer object that encapsulates the private key securely. The skill should interact with the NEAR blockchain using a secure, pre-authorized method that does not require the private key to be directly exposed or passed around in memory or function calls. | LLM | src/dca-manager.js:80 | |
| LOW | Storage of Sensitive Financial Strategy Data The skill stores DCA plan details (including token, amount, schedule, account, total invested, total accumulated, etc.) in local JSON files (`~/.near-dca/plans.json` and `./data/dca_state.json`). While not directly containing private keys, this data represents sensitive financial strategy information. Unauthorized access to these files could reveal a user's investment strategy and financial activity. Ensure that these local storage files are protected with appropriate file system permissions (e.g., readable only by the owner). Consider encrypting the contents of these files if the data is deemed highly sensitive and the environment allows for secure key management. Inform users about the location and nature of stored data. | LLM | src/dca-manager.js:196 | |
| LOW | User Input Directly Embedded in Output Messages User-provided input, such as strategy names (`name`), token types (`token`), amounts (`amount`), and schedule (`schedule`), is directly embedded into `console.log` statements and action return messages without explicit sanitization. While this is not a direct prompt injection vulnerability for the LLM itself, it could potentially be exploited via terminal escape sequences or by crafting inputs that confuse or mislead the user or downstream systems that process these messages. Sanitize or escape user-provided strings before embedding them directly into output messages, especially if those messages are displayed in a terminal or processed by other systems. For example, escape special characters that could be interpreted as control sequences or markup. | LLM | actions/index.js:40 |
Scan History
Embed Code
[](https://skillshield.io/report/44148a20ed76dc32)
Powered by SkillShield