Exposed secret literal
- Finding
- File appears to expose a hardcoded API secret or token.
Security checks across static analysis, malware telemetry, and agentic risk
Prompt-injection indicators were detected in the submitted artifacts (ignore-previous-instructions); human review is required before treating this skill as clean.
Use this as an advisory skill. Before running any 1Password, wallet, or git-hook snippets, verify the target vaults and files, prefer limited session keys over raw private keys, and ensure secrets are never printed, logged, or copied into examples. ClawScan detected prompt-injection indicators (ignore-previous-instructions), so this skill requires review even though the model response was benign.
No VirusTotal findings for this skill version.
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If a user runs these snippets against a real vault, the agent or process could access sensitive wallet or API credentials.
The skill demonstrates reading wallet-related secrets through the 1Password CLI. This is disclosed and central to its security-management purpose, but it touches high-impact credentials.
PRIVATE_KEY=$(op read "op://Agents/my-agent-wallet/private-key")
Use dedicated vaults, prefer limited session keys over master private keys, verify each 1Password item before reading it, and do not let the agent print or log retrieved secrets.
Running example commands without review could create, change, or delete credential items.
The documentation includes shell commands that can mutate a 1Password vault. They are relevant to session-key lifecycle management, but they affect real credential records if executed.
op item delete "agent-session-compromised" --vault "Agent-Wallets"
Treat shell snippets as examples, confirm vault and item names, and require explicit user approval before any create/delete or wallet-related operation.
Users or scanners may mistake the sample for a real secret, and copying it into code would be unsafe.
A complete private-key-shaped value appears in a BAD example. It is framed as something not to do, but it contradicts the ideal of avoiding full secret literals in documentation.
TEST_KEY = "0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80"
Replace full secret-shaped examples with unmistakably fake placeholders such as 0x<redacted> or test-only non-secret markers.