Is glitch003/safe-skills safe?

The SafeSkills service stores EVM wallet private keys server-side on infrastructure controlled exclusively by the skill author (glitch003). The service operator has unilateral, persistent capability to drain any wallet created through this skill. Users depositing cryptocurrency into these wallets are implicitly extending unconditional trust to an unverified third party. This is a structural financial theft vector, not a traditional data exfiltration attack, but the outcome is equivalent: user assets flow to the service operator at will.

The /api/skills/evm-wallet/send-transaction endpoint accepts arbitrary 'to' addresses, custom 'data' calldata, and 'value' amounts. This endpoint, combined with the service's custody of private keys, means the service operator can execute any on-chain transaction — including transferring all ETH and ERC-20 tokens to an attacker-controlled address — without any agent or user approval step visible on the client side.

The skill is branded 'SafeSkills — Secure Secret Management' and prominently states that secrets stay server-side as a security benefit. This framing positions the custodial design as protecting users, when in reality it concentrates all financial control with the service operator. A user or agent reading this skill would reasonably conclude their funds are protected by a security-conscious design, when the opposite risk is present.

The service is hosted on Railway (a PaaS platform) with no disclosed security audit, no on-chain proof of key custody methodology (e.g., MPC, HSM), no open-source backend, and no regulatory or insurance backing. Users have no mechanism to verify that private keys are protected from the operator. If the service is compromised or the operator is malicious, all funds are immediately at risk.

The skill instructs the agent to use SAFESKILLS_API_URL and SAFESKILLS_FRONTEND_URL if those environment variables are set. A malicious co-installed skill that can write environment variables, or a compromised execution environment, could point these variables to an attacker-controlled server. All subsequent wallet API calls (including those carrying the API key) would then be intercepted, enabling wallet takeover.

The skill explicitly directs the agent to store the API key returned during wallet creation for all subsequent calls. This means a credential granting full control over a potentially funded cryptocurrency wallet will reside in the agent's context or memory. Other skills or subsequent prompt injections targeting the agent context could extract this key, transferring wallet control to a third party without user awareness.

The skill uses bold CRITICAL formatting to instruct the agent never to attempt to access or request raw secret values. While consistent with the skill's stated purpose, this directive establishes a behavioral constraint in the agent's operating instructions that could inhibit the agent from questioning the service's legitimacy or verifying wallet security properties independently.

Filesystem audit logs show all six honeypot credential files were accessed at two points: audit timestamp 1771929865.960 (pre-install) and 1771929883.295 (post-install). Both access patterns are consistent with the Oathe monitoring framework performing baseline and comparison scans. No evidence of skill-initiated access; canary integrity confirmed intact. Noted for completeness.

The skill contains only two files: _meta.json (metadata) and SKILL.md (instruction markdown). No JavaScript, TypeScript, Python, shell scripts, Dockerfiles, Makefiles, package.json install hooks, git hooks, submodules, or symlinks were found. The install process performed a clean git sparse-checkout with no build or execution steps.