Back to skill

Security audit

Bagman

Security checks for vulnerabilities and agentic risk

Overview

This security-guidance skill is mostly coherent, but some examples could expose wallet credentials if followed literally.

Install only if you understand it is guidance for high-impact wallet and secret workflows. Do not paste real private keys or session keys into shell commands as shown; use a concealed prompt, stdin, or another 1Password-supported secret input path, and replace the valid-format sample private key with an impossible placeholder before reusing the material.

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 (2)

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:91
Finding
Session Key Exposed Through Command-Line Arguments<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 91-99 **Vulnerability Type**: Secret exposure through process arguments and shell history **Risk Level**: High ### Vulnerable Code ```bash # Store agent session key (not master key!) op item create \ --vault "Agent-Wallets" \ --category "API Credential" \ --title "trading-bot-session" \ --field "session-key[password]=0xsession..." \ --field "expires=2026-02-15T00:00:00Z" \ --field "spending-cap=1000 USDC" \ --field "allowed-contracts=0xDEX1,0xDEX2" ``` ### Technical Analysis The documented command supplies the wallet session key directly as a command-line argument. Replacing the placeholder with an actual key can expose that key through: - Shell history files. - Terminal session recording and audit logs. - Process inspection utilities while the command is running. - Process accounting or endpoint-monitoring software. - Debug output or copied command transcripts. Although the key is described as a bounded session key rather than a master key, it remains an authentication credential capable of authorizing wallet operations. Storing it securely in 1Password does not prevent disclosure that occurs before the CLI receives and stores it. ### Attack Path 1. An operator follows the documented setup procedure and substitutes a real session key for `0xsession...`. 2. The shell records the command in history, or the operating system exposes its arguments while it executes. 3. An attacker with access to the same account, terminal logs, process telemetry, backups, or other local inspection facilities recovers the session key. 4. The attacker uses the recovered credential before expiration or revocation. 5. The attacker performs transactions permitted by the key's spending cap, contract allowlist, and other delegated policies. ### Impact Assessment Successful exploitation compromises the delegated wallet authority associated with the session key. The attacker could authorize oper ...[truncated 390 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Do not pass secrets as literal command-line arguments. - Use a supported 1Password input mechanism that obtains secret values from protected standard input, an interactive concealed prompt, or another channel that does not expose them in the process argument list. - If a temporary import or template file is unavoidable: - Create it with permissions restricted to the current user. - Store it on an encrypted or memory-backed filesystem where practical. - Delete it immediately after use. - Ensure it is excluded from source control and backups. - Prevent commands containing sensitive values from being retained in shell history; do not rely on this measure alone because process arguments may remain observable. - Review process accounting, terminal recording, CI logs, and endpoint telemetry to confirm that secret-bearing inputs are not retained. - Rotate any session key that has already been entered using the documented command. - Preserve defense in depth by enforcing short expiration periods, low spending caps, narrowly scoped contract allowlists, monitoring, and rapid revocation. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:353
Finding
Valid-Format Ethereum Private Key Embedded in Documentation<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 353-357 **Vulnerability Type**: Publicly disclosed valid-format private key **Risk Level**: Medium ### Vulnerable Code ```markdown ### 1. Keys in Memory Files **Problem**: Agents store keys in `memory/*.md` for "persistence" ```markdown # memory/2026-02-07.md ## Test Wallet - Private key: 0x9f01dad551039daad3a8c4e43a32035bdd4da54e7b4292268be16e913b0b3e56 ``` ``` ### Technical Analysis The documentation includes a complete 64-hex-character value in the syntactic form of an Ethereum private key. It is presented as an unsafe example, and the audit did not establish that it protects an existing funded account. Nevertheless, anyone who reads the file can derive and control the corresponding account. Using a cryptographically valid-format private key as sample data creates several risks: - Users may mistake it for a safe test credential. - Users may import it into a wallet and transfer test or real assets to the resulting address. - Automated tooling may detect it as an exposed credential. - The example contradicts the document's own guidance against storing raw private keys in files. Labeling a key as a test value does not make an account derived from it private. Once published, it must be treated as permanently compromised. ### Attack Path 1. A user copies the documented value into wallet software, a test environment, or an agent configuration. 2. The user transfers tokens or native currency to the corresponding address or grants that address privileges. 3. An attacker obtains the same value from the public documentation and imports it into a compatible wallet. 4. The attacker signs transactions using the known key. 5. The attacker transfers available assets or exercises permissions granted to the compromised address. ### Impact Assessment An attacker can obtain full cryptographic control of the account derived from the published value. This permits signing arbitrary transactions ...[truncated 302 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Replace the value with a deliberately invalid placeholder, for example: ```text Private key: 0x<REDACTED-64-HEX-PRIVATE-KEY> ``` - Avoid sample values that can be interpreted as valid private keys, API tokens, passwords, seed phrases, or other credentials. - Add automated secret scanning to documentation and source-control workflows. - If the published key was ever used, treat it as compromised: - Transfer any remaining assets to a newly generated account. - Revoke approvals, delegated permissions, and application access. - Remove the address from administrative or contract roles. - Review its transaction history for unauthorized activity. - Use fictional identifiers that are structurally impossible as real credentials when demonstrating insecure storage patterns. ]]>
Vulnerability Patterns
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (2)

Credential Access

High
Category
Privilege Escalation
Content
```bash
# NEVER store keys in files
echo "PRIVATE_KEY=0x123..." > .env

# NEVER log or print keys
console.log("Key:", privateKey)
Confidence
60% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High
Category
Privilege Escalation
Content
```bash
# NEVER store keys in files
echo "PRIVATE_KEY=0x123..." > .env

# NEVER log or print keys
console.log("Key:", privateKey)
Confidence
60% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Static analysis

No suspicious patterns detected.