ClawHub
Back to skill

Security audit

Poe Usage

Security checks for vulnerabilities and agentic risk

Overview

This skill coherently monitors Poe API usage, but it depends on a third-party CLI that will receive the user's Poe API key.

Install only if you trust the rgstephens Homebrew tap and poeusage CLI with your Poe API key. Prefer setting POE_API_KEY in a controlled environment, avoid putting the key on the command line or in config files, and be aware that JSON/CSV/table outputs can reveal account usage and spend metadata.

A.I.G

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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
Findings (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:8
Finding

Unaudited Third-Party CLI Is Granted Access to the Poe API Credential

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 8–18 and 27–31
Vulnerability Type: T08: Insecure Dependencies
Risk Level: Medium

Vulnerable Code

yaml
metadata:
  openclaw:
    emoji: "📊"
    homepage: https://github.com/rgstephens/poeusage-skill
    requires:
      bins:
        - poeusage
      env:
        - POE_API_KEY
    install:
      - kind: brew
        tap: rgstephens/tap
        formula: poeusage
        bins:
          - poeusage

The documented installation commands are:

bash
brew tap rgstephens/tap
brew install poeusage

Technical Analysis

The Skill delegates its entire runtime behavior to the external poeusage executable, installed from the publisher-controlled rgstephens/tap Homebrew tap. The executable is granted access to the sensitive POE_API_KEY environment variable and is expected to perform network requests.

The audited project contains only SKILL.md; it does not include the CLI implementation. It therefore provides no locally reviewable assurance regarding:

  • The network destinations receiving the credential.
  • The scope and content of transmitted usage data.
  • Credential logging or persistence behavior.
  • The integrity of the installed executable.
  • The behavior of future versions supplied through the tap.

The installation does not pin an immutable release, commit, artifact digest, or checksum. This does not prove that the dependency is malicious, but it creates a supply-chain trust boundary through which the effective executable can change after the Skill has been reviewed.

Network access and Poe authentication are necessary for the declared balance and usage-monitoring functionality. However, granting a mutable, unaudited third-party executable access to the credential without integrity controls exceeds what the Skill package itself can safely verify.

Attack Path

  1. An attacker compromises the t ...[truncated 1220 chars]
Remediation
View remediation

Remediation Suggestions

  1. Pin installation to a reviewed, immutable CLI release rather than an automatically changing formula.
  2. Verify the downloaded artifact using a cryptographic checksum or trusted signature.
  3. Publish or bundle the CLI source so its credential handling and network behavior can be audited with the Skill.
  4. Document the exact Poe API hostnames and network operations required by each command.
  5. Enforce an outbound destination allowlist where the execution environment supports it.
  6. Use reproducible builds and release provenance attestations to connect reviewed source to distributed binaries.
  7. Run the CLI with only the required credential and a minimal environment; do not expose unrelated secrets.
  8. Document upgrade review procedures so dependency changes are evaluated before deployment.

T09 · Insecure Skill Coding Practices

Note
Location
SKILL.md:42
Finding

API Credential May Be Exposed Through Command-Line Arguments

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, line 42
Vulnerability Type: T09: Insecure Skill Coding Practices
Risk Level: Low

Vulnerable Code

markdown
- `--api-key` string (default from `$POE_API_KEY`)

Related configuration documentation at lines 181–185 states:

markdown
Config file: `~/.config/poeusage/config.toml`

```toml
# api_key = "..." # not recommended
timeout = 30
page_size = 100
text

### Technical Analysis

The CLI permits users to supply the Poe API credential through the `--api-key` command-line option. Secrets passed as command-line arguments may be retained in shell history and may be visible in process metadata while the command is running. Exposure depends on the operating system, process-inspection permissions, shell configuration, and how the option is used.

The environment-variable default is safer than directly typing the secret as an argument, although environment variables also require careful handling. The documentation appropriately discourages plaintext storage in the configuration file, but it does not provide a corresponding warning against placing the credential on the command line.

### Attack Path

1. A user runs a command such as `poeusage --api-key <secret> balance`.
2. The shell records the complete command in its history, or the argument remains temporarily visible through process-inspection facilities.
3. Another local user, support tool, telemetry collector, backup process, or later attacker gains access to that history or process metadata.
4. The observer extracts the Poe API credential.
5. The credential is reused against the Poe API within its assigned permissions.

### Impact Assessment

Exploitation could disclose the Poe API credential to users or processes able to inspect command history or process arguments. The resulting access is limited to the permissions and quota associated with the compromised key, but may incl
...[truncated 345 chars]
Remediation
View remediation

Remediation Suggestions

  1. Remove the --api-key option where compatibility permits, or clearly mark it as unsafe for interactive use.
  2. Prefer a protected operating-system credential store or keychain integration.
  3. If environment variables remain supported, document secure injection practices and avoid printing the environment in verbose diagnostics.
  4. Support reading the credential from a permission-restricted file descriptor or interactive prompt that disables terminal echo.
  5. Add an explicit warning that command-line secrets may appear in shell history and process listings.
  6. Ensure verbose and error output never includes the full API key; redact credential-shaped values in diagnostics.
  7. If configuration-file storage is supported, require restrictive file permissions and reject insecure permissions where practical.

SkillSpector

Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (1)

Missing User Warnings

Low
Category
Not specified by scanner
Confidence
78% confidence
Finding

This markdown file describes commands that fetch balance, history, and summary data from a remote API using POE_API_KEY, which is a privacy-relevant network operation. While the functionality is described, there is no explicit user-facing warning that the tool sends authenticated requests and may expose account usage metadata in outputs.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.