Trust Assessment
uniclaw received a trust score of 77/100, placing it in the Mostly Trusted category. This skill has passed most security checks with only minor considerations noted.
SkillShield's automated analysis identified 5 findings: 0 critical, 0 high, 3 medium, and 2 low severity. Key findings include Unpinned npm dependency version, Potential Command Injection via CLI Arguments, Hardcoded API Key in `lib/wallet.ts`.
The analysis covered 4 layers: Manifest Analysis, Static Code Analysis, Dependency Graph, LLM Behavioral Safety. All layers scored 70 or above, reflecting consistent security practices.
Last analyzed on February 12, 2026 (commit 13146e6a). SkillShield performs automated 4-layer security analysis on AI skills and MCP servers.
Layer Breakdown
Behavioral Risk Signals
Security Findings5
| Severity | Finding | Layer | Location | |
|---|---|---|---|---|
| MEDIUM | Unpinned npm dependency version Dependency '@noble/curves' is not pinned to an exact version ('^2.0.1'). Pin dependencies to exact versions to reduce drift and supply-chain risk. | Dependencies | skills/jvsteiner/uniclaw/package.json | |
| MEDIUM | Potential Command Injection via CLI Arguments The skill's documentation (`SKILL.md`) provides examples of executing local TypeScript scripts using `npx tsx scripts/...` where user-controlled input (e.g., `<your-agent-name>`, `<market-id>`, `<address>`) is directly interpolated into the command. While the provided TypeScript scripts themselves parse arguments and use them in API calls or for display, an LLM that directly executes these commands based on user input without proper sanitization could be vulnerable to command injection. For example, if `<your-agent-name>` contained shell metacharacters, it could lead to arbitrary command execution on the host system if the LLM directly constructs and executes the shell command. Implement robust input sanitization for all user-provided arguments before constructing and executing shell commands. If the LLM is responsible for constructing these commands, ensure it is instructed to sanitize user input. For direct script execution, consider using a tool execution framework that handles argument passing securely, or ensure the scripts themselves validate and sanitize all `process.argv` inputs if they were to be used in `child_process` calls. In this specific case, the scripts appear to handle arguments as data, but the risk lies in the LLM's interpretation and execution of the example commands. | LLM | SKILL.md:25 | |
| MEDIUM | Direct Access to Internal Private Key Field The `getPrivateKeyHex` function in `lib/wallet.ts` accesses the private key directly from an internal, TypeScript-private field `_identity` of the `Sphere` object (`(sphere as any)._identity`). This bypasses the public API of the `sphere-sdk` which explicitly strips the private key from the `sphere.identity` getter. Relying on internal implementation details is fragile and could break with SDK updates. More importantly, it indicates a design where the private key is more readily accessible than intended by the SDK, increasing the risk of accidental exposure or misuse within the skill's own codebase. Refactor the skill to use the `sphere-sdk` as intended, without directly accessing internal private fields. If the SDK does not provide a secure public method to obtain the private key for signing, consider if the signing operation should be delegated to the SDK itself rather than extracting the raw private key. If direct private key access is absolutely required for a specific signing flow, consult the SDK documentation for the officially supported and secure way to do so, or raise an issue with the SDK maintainers for a public API. | LLM | lib/wallet.ts:45 | |
| LOW | Hardcoded API Key in `lib/wallet.ts` The `lib/wallet.ts` file contains a hardcoded API key (`sk_06365a9c44654841a366068bcfc68986`) which is used as a fallback if the `UNICITY_API_KEY` environment variable is not set. Hardcoding API keys, even if they are for a public or test service, can lead to misuse, rate limit exhaustion, or exposure of internal service details. While this specific key might be for a test environment, it's a poor security practice. Remove hardcoded API keys. Always require API keys to be provided via environment variables or a secure configuration management system. If a default is absolutely necessary for development, ensure it's clearly marked as such and not used in production, or use a placeholder that would cause an immediate failure if not replaced. | LLM | lib/wallet.ts:27 | |
| LOW | Debug Mode Enabled in `createNodeProviders` The `createNodeProviders` function in `lib/wallet.ts` explicitly enables `debug: true` for the transport layer. While useful for development, leaving debug mode enabled in production or publicly distributed code can expose sensitive information (e.g., request/response details, internal states, or even parts of signed payloads) that could aid an attacker in understanding the system's workings or exploiting vulnerabilities. This is particularly concerning in a wallet-related SDK. Ensure debug mode is disabled for production builds or when distributing the skill. Implement a mechanism to conditionally enable debug logging (e.g., based on an environment variable like `NODE_ENV` or `UNICLAW_DEBUG`) rather than hardcoding it to `true`. | LLM | lib/wallet.ts:30 |
Scan History
Embed Code
[](https://skillshield.io/report/1c40863eb0345592)
Powered by SkillShield