Back to skill

Security audit

Crypto Guardian

Security checks for vulnerabilities and agentic risk

Overview

The skill aims to protect crypto wallets, but it repeatedly gives unsafe advice to store wallet recovery secrets in plaintext .env files.

Review carefully before installing. Do not follow the .env seed phrase or raw private-key examples; wallet recovery phrases should stay offline or hardware-backed, and active signing should use a hardware wallet, isolated signer, or proper secret manager with narrowly scoped runtime access. If this guidance was already followed, treat the affected wallet secret as potentially exposed, move funds to a new securely generated wallet, and retire the old secret.

Vulnerability Patterns
  • 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
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (1)

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:45
Finding
Plaintext Wallet Keys and Seed Phrases Recommended in Workspace .env Files<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:45-58`, `SKILL.md:101-107`, `SKILL.md:222-245`, and `SKILL.md:262-267` **Vulnerability Type**: Plaintext sensitive credential storage and contradictory secret-handling guidance **Risk Level**: High ### Vulnerable Documentation `SKILL.md:45-58`: ```markdown ### 1. Private keys and seed phrases MUST NOT exist in workspace files **Files that are NOT safe:** - `SESSION-STATE.md` - `working-buffer.md` - `MEMORY.md` - `.env` (with the private key itself) - Any `.json`, `.txt`, `.md` in the workspace - Any AI conversation history (public platforms) **Safe alternatives:** - `.env` only, with keys referenced as env vars at runtime - Hardware wallets (keys never leave device) - Encrypted storage with passphrase - Wallets where private key is never stored at all (watch-only + hardware sign) ``` `SKILL.md:101-107`: ```markdown ``` Purpose | Wallet Type | Key Storage ---------------------|--------------------|---------------------- Trading/Active | Software (Solflare) | .env, never in files Grip/Bounty Earn | Software (MetaMask) | Seed phrase in .env only Long-Term Savings | Hardware (Ledger) | Never touches computer ``` ``` `SKILL.md:222-245`: ```markdown ### Wallet Strategy for This Agent ``` Wallet Type | Address | Storage | Used For ---------------|-------------------|---------------|-------------------------- Active DCA | [DISCARDED] | None | (empty, was drained) Bounty Earn | 0xD1089e... | .env only | Grip, ClawMoney Watch-Only | [YOUR WALLET] | TOOLS.md | Monitor only New DCA Wallet| TBD (new generation) | Hardware | Jupiter DCA (future) ``` ### Key Storage Rules 1. **Never write full private keys anywhere** (except .env, which must be gitignored) 2. **Never in conversation**: Even "let me check if this key is correct" 3. **Never in SESSION-STATE.md or working-buffer.md** 4. **Never in memor ...[truncated 3551 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove every recommendation to store private keys or seed phrases in `.env` files. 2. Explicitly prohibit storing recovery seed phrases in any digital workspace file, including `.env`, configuration files, source files, logs, and Agent memory. 3. Prefer hardware wallets or isolated signing services where private material never reaches the Agent or general-purpose workspace. 4. For automated wallets, use an operating-system keychain, hardware-backed keystore, cloud secret manager, or dedicated signer with narrowly scoped access controls. 5. If a low-value hot wallet must receive a secret through an environment variable, inject it directly at process startup from a secret manager rather than loading it from a workspace `.env` file. 6. Ensure secret-bearing processes use least privilege, disable debug logging and crash dumps where practical, and prevent child processes from unnecessarily inheriting sensitive environment variables. 7. Add defense-in-depth controls such as secret scanning, restrictive file permissions, excluded backup paths, deployment-context exclusions, and pre-commit checks. These controls must not be presented as substitutes for secure key custody. 8. Replace the vulnerable example with a signer interface that sends transaction data to a hardware-backed or isolated signing component and returns only the signature. 9. Instruct users who previously followed the `.env` guidance to treat stored keys as potentially exposed, create a new wallet using secure key generation, move remaining assets, revoke obsolete approvals, and permanently retire the old key or seed. ]]>
Vulnerability Patterns
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • 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
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Findings (8)

Intent-Code Divergence

High
Confidence
99% confidence
Finding
The recommended wallet setup says a seed phrase can be stored in `.env`, which directly contradicts the earlier prohibition on storing seed phrases in files. A seed phrase is sufficient to fully recover and drain the wallet, so normalizing file-based storage in a skill meant to protect wallets materially increases the chance of catastrophic asset loss.

Credential Access

High
Category
Privilege Escalation
Content
Purpose              | Wallet Type        | Key Storage
---------------------|--------------------|----------------------
Trading/Active       | Software (Solflare) | .env, never in files
Grip/Bounty Earn     | Software (MetaMask) | Seed phrase in .env only
Long-Term Savings    | Hardware (Ledger)   | Never touches computer
```
Confidence
99% confidence
Finding
This line recommends storing a seed phrase in `.env`, which constitutes credential exposure guidance for the most sensitive wallet secret. If followed, compromise of the file, repository, runtime logs, or workspace gives an attacker full control over funds with immediate irreversible impact.

Credential Access

High
Category
Privilege Escalation
Content
Wallet Type    | Address           | Storage      | Used For
---------------|-------------------|---------------|--------------------------
Active DCA    | [DISCARDED]          | None        | (empty, was drained)
Bounty Earn   | 0xD1089e...           | .env only   | Grip, ClawMoney
Watch-Only    | [YOUR WALLET]         | TOOLS.md    | Monitor only
New DCA Wallet| TBD (new generation)  | Hardware    | Jupiter DCA (future)
```
Confidence
95% confidence
Finding
This section normalizes `.env only` storage for a wallet tied to active use, encouraging file-based handling of private signing material. In the context of AI agents and workspace scanning, that materially raises the chance of secret disclosure and theft of on-chain assets.

Credential Access

High
Category
Privilege Escalation
Content
| Security Level | Use Case | Key Storage |
|----------------|----------|-------------|
| Maximum | Long-term savings | Hardware wallet only |
| High | Active project funds | .env + careful handling |
| Medium | Daily trading | Software wallet, small balance |
| Low | Testing/learning | Any, small amounts |
Confidence
93% confidence
Finding
Classifying `.env + careful handling` as 'High' security for active project funds is misleading and unsafe in this context. Users may infer that file-based key storage is an endorsed secure pattern, causing preventable key exposure in systems where workspace and environment handling are not strongly isolated.

Vague Triggers

Medium
Confidence
95% confidence
Finding
The description and trigger list use short, high-frequency terms such as "wallet," "crypto," and "blockchain" without narrowing context or exclusion conditions. These phrases can easily overlap with ordinary discussion about cryptocurrency or wallets, making activation boundaries unclear.

Intent-Code Divergence

Medium
Confidence
97% confidence
Finding
The skill explicitly presents `.env` as a safe alternative for private keys while also stating that workspace files should be assumed public. In an agent context, `.env` is still a file that can be indexed, committed, logged, or exfiltrated, so this contradictory guidance can directly lead to key compromise and wallet theft.

Intent-Code Divergence

Medium
Confidence
96% confidence
Finding
The implementation section again endorses storing signing material in `.env`, reinforcing unsafe operational practice despite the document's own warning that workspace artifacts may be exposed. In an AI-agent environment, repeated endorsement makes accidental adoption more likely and increases the chance that sensitive keys are stored where tooling, memory, or source control can leak them.

Natural-Language Policy Violations

Low
Confidence
98% confidence
Finding
Line L127 contains Chinese text ("纸上残留的seed phrase notes") inside an otherwise English skill document. This introduces an implicit language shift without user opt-in or any documented multilingual policy, which can violate language consistency expectations.

Static analysis

No suspicious patterns detected.