T08 · Insecure Dependencies
- Location
scripts/verity.py:60- Finding
Unpinned Third-Party SDK Receives a Spend-Capable Wallet Private Key
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is coherent and mostly transparent, but it asks users to expose a spend-capable wallet key to unpinned external code and recommends an unpinned privileged plugin.
Install only if you are comfortable sending checked content to VerityLayer and using a dedicated low-balance Base wallet. Pin and review the `verity-guard[x402]` package before exposing `VERITY_WALLET_KEY`, and do not install the optional OpenClaw plugin unless you can pin or verify the exact plugin version and understand its hook permissions.
scripts/verity.py:60Unpinned Third-Party SDK Receives a Spend-Capable Wallet Private Key
references/enforcement.md:64Unpinned External Enforcement Plugin Is Recommended for Privileged Tool Interception
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
**Before anything irreversible** — use `check` (allow / review / block):
- moving money, signing a transaction, approving a spend
- sending something a human will see: email, DM, post, reply
- destructive or state-changing commands: `rm -rf`, `DROP`, `git push --force`, deploy, terminate
- credential / permission / access-control changes, adding forwarding rules or webhooks
- publishing, or making something public
The skill explicitly relies on environment access via VERITY_WALLET_KEY but does not declare any tool scope or permission boundary for that capability. This creates an under-specified trust boundary: a host agent may expose sensitive environment data to the skill without clear operator consent or sandboxing expectations, increasing the risk of secret misuse or accidental overexposure.
The catalog instructs users to directly POST arbitrary inputs such as claims, content, policies, payloads, and evidence to external endpoints, but it does not clearly warn that this data will leave the local system and be transmitted to third-party services. In a security-oriented skill, this omission is especially risky because the very data being checked may contain sensitive prompts, internal context, PII, secrets, or confidential business information.
Dynamic getattr() with a non-literal attribute name can access arbitrary object attributes, potentially bypassing access controls.
elif a.policy:
_die(1, "--policy applies to `check` only")
res = getattr(_client(paid=True), method)(a.text, **kwargs)
# Fail-closed reporting, driven off the SDK's chokepoint rather than a hand-rolled list.
# Hand-rolling it here missed a whole class: a 200 that parses but carries no decision