Notifications
Clear all
Topic starter
02/08/2026 12:02 pm
TL;DR: OpenClaw’s fast-growing ecosystem is attracting security risk through malicious marketplace skills, typosquatted packages, prompt injection exposure and insecure deployments, according to Veracode Threat Research. The issue is less the assistant itself than the trust collapse around code, skills, endpoints and credentials that conventional controls do not yet govern well.
NHIMG editorial — based on content published by Veracode: Clawing For Scraps: Risks of OpenClaw AKA ClawdBot
By the numbers:
- at the time of writing has 166k followers on GitHub
- In the Python ecosystem we have 5 packages so far claws , soupclaw , claw-cli , pinkyclawd and clawpack , and in NPM there are at least 98
Questions worth separating out
Q: What breaks when AI assistants are allowed shell access on unmanaged devices?
A: The enterprise loses the usual boundary between user activity and system activity.
Q: Why do AI browsers create new identity and access risk?
A: Because they turn the browser from a passive display layer into a system that can interpret content and execute actions.
Q: What do security teams get wrong about skill marketplaces?
A: They often treat marketplaces as convenience layers rather than supply chain entry points.
Practitioner guidance
- Quarantine AI assistant experiments from managed endpoints Require dedicated, freshly built or reset devices for testing assistants, with no corporate browser profile, no production sync and no access to work mail, chat or files.
- Block production credentials from early-stage assistant testing Do not attach API keys, SSO sessions or service account tokens until the assistant’s tool use, logging and permission boundaries have been reviewed.
- Vet skills and packages as supply-chain inputs Apply provenance checks, maintain an allowlist for approved skills and watch for typosquatted package names that mimic legitimate extensions.
What's in the full article
Veracode's full analysis covers the operational detail this post intentionally leaves for the source:
- The package-name ecosystem scan across claw-related Python and NPM artifacts, including how quickly the namespace expanded.
- The specific examples of suspicious or malicious marketplace skills and why they are difficult to triage at scale.
- Practical guidance on what to avoid when testing OpenClaw on real machines, including device, account and credential choices.
- The vendor’s observations on how people are standing up supporting infrastructure and where exposed ports or loose setup choices create risk.
👉 Read Veracode’s analysis of OpenClaw’s security risks and ecosystem abuse →
OpenClaw and ClawHub: what security teams should watch now?
Explore further
02/08/2026 1:08 pm
OpenClaw exposes a verification trust gap: the security failure is not only malicious code, but the speed at which users adopt assistants before provenance, behaviour and privilege boundaries are established. That creates a familiar identity problem in new clothing: access is granted before the trust chain is proven. In NHI terms, every skill and integration behaves like a delegated identity that needs lifecycle control, not just install-time review.
A question worth separating out:
Q: Who is accountable when an AI assistant overshares sensitive content?
A: Accountability sits with the team that owns the policy, the attribute feeds, and the enforcement points, because ABAC only works when all three are managed together. If any one of them is missing, the organisation has not built a defensible control path, even if the model itself appears constrained.
👉 Read our full editorial: OpenClaw's rapid ecosystem growth creates new AI security risk
