Skillv1.0.2

ClawScan security

Tokenbroker · ClawHub's context-aware review of the artifact, metadata, and declared behavior.

Scanner verdict

SuspiciousFeb 11, 2026, 11:51 AM

Verdict: suspicious
Confidence: medium
Model: gpt-5-mini
Summary: The skill's code and docs broadly match a token-generation-and-launch purpose, but there are multiple inconsistencies around requested credentials, where secrets are stored/transmitted, and how delegation to other skills is done — these gaps warrant caution before installing or running with private credentials.
Guidance: Key things to check before installing or running TokenBroker: 1. Clarify credential needs: The registry shows no required env vars but the SKILL.md/METADATA.md request GITHUB_TOKEN, PRIVATE_KEY, BUILDER_ID and NAD_FUN_API_KEY. Ask the author which credentials are actually required and why. Do not provide your PRIVATE_KEY unless you fully understand where and how it will be used and stored. 2. Prefer A2A injection over storing secrets on disk: The docs mention both writing a .env and using A2A secure injection. Use A2A or short-lived tokens where possible; avoid putting private keys in a .env file on disk. 3. Limit GitHub token scope: If you supply GITHUB_TOKEN for monitoring, restrict it to read-only (public_repo) and consider using OAuth with minimal scopes and rotation. 4. Confirm approval flow for launches: The skill describes automated GitHub monitoring and delegation to nadfun. Verify whether launches require a human approval step before any on-chain action or signing occurs. 5. Audit delegation targets: TokenBroker delegates to a 'nadfun' skill and invokes other A2A identity services. Verify those dependency skills' sources and trustworthiness before allowing automatic delegation. 6. Test in safe environment: Run in testnet mode and with burner keys first. Review generated metadata and all network requests (e.g., POSTs to nad.fun endpoints) to confirm they match expectations. 7. Ask author for registry corrections: The registry metadata should list the environment variables the skill needs. The mismatch is an actionable red flag. If you cannot get clear answers about credential handling and the human approval gating, treat the skill as risky and avoid providing high-privilege secrets (especially PRIVATE_KEY).

Review Dimensions

Purpose & Capability: concernThe skill claims to analyze GitHub repos and orchestrate nad.fun launches — that purpose explains most included files (scan, metadata, promo, nadfun). However registry metadata declares no required environment variables while SKILL.md / METADATA.md / SETUP.md state the skill needs GITHUB_TOKEN, PRIVATE_KEY, BUILDER_ID, NAD_FUN_API_KEY and NETWORK. That mismatch (no env listed in registry but many sensitive envs documented) is incoherent and should be clarified. Requiring a PRIVATE_KEY is plausible for on-chain deployment, but TokenBroker's docs also claim on-chain ops are delegated to a separate 'nadfun' skill (which should manage keys) — asking for PRIVATE_KEY at the TokenBroker level is unclear and may be unnecessary.
Instruction Scope: concernInstructions include read-only local project scanning (expected) and clearly describe generating a .env and various credential handling modes (A2A, OAuth, PAT). They also instruct the agent to monitor GitHub activity and (after prompting) delegate launches to nadfun. Conflicting guidance appears: some docs say credentials are always injected and never persisted, others describe the Install Wizard writing a .env. The skill also describes automated triggers and A2A calls (invokeSkill) which could cause remote delegation; the degree of automation and when user approval is required is inconsistent across documents.
Install Mechanism: okNo install spec is provided (instruction-only), and the package contains source files only. No external downloads or installation scripts were included in the manifest. This reduces installation-surface risk compared with remote installers.
Credentials: concernThe code and docs reference multiple sensitive environment values (GITHUB_TOKEN, PRIVATE_KEY, NAD_FUN_API_KEY, BUILDER_ID) while the registry metadata lists none — this mismatch is concerning. PRIVATE_KEY in particular grants signing power; TokenBroker claims it delegates signing to nadfun, yet some docs require the private key locally. The skill asks users to create a .env and also promotes A2A secret injection — conflicting recommendations increase the chance of improper key storage/exfiltration. Requesting a full PRIVATE_KEY without a clear, necessary reason at this skill boundary is disproportionate.
Persistence & Privilege: okThe skill does not request always:true and is user-invocable; autonomous invocation is allowed (platform default). It does describe writing a local .env and maintaining local history files (e.g., .tokenbroker/history.json) — those are normal for this type of meta-skill but should be highlighted to users. There is no indication the skill modifies other skills or system-wide settings beyond invoking other agent skills (A2A), which is expected for orchestration.