ClawHub plugin scope abuse: what it means for AI agent security

TL;DR: 23 code-executing ClawHub plugins published under official-looking @openclaw/ and @clawhub/ scopes by unrelated accounts were identified, according to Manifold Security, showing that a scope can signal provenance without actually enforcing it. The real failure is assumption collapse: trust badges and namespace rules only work if the registry verifies ownership before code can run inside an agent.

Editorial analysis by NHI Mgmt Group, based on content published by Manifold Security: “Scope Squatting: Those @openclaw and @clawhub Plugins Aren't Officially Theirs”.

By the numbers:

• 23 code-executing ClawHub plugins were published under official-looking @openclaw/ and @clawhub/ scopes by unrelated accounts.

Key questions

Q: What breaks when AI agent plugin namespaces are not ownership-verified?

A: The trust model breaks first.

Q: Why do official-looking scopes increase risk for code-executing plugins?

A: Because the scope can suppress scrutiny.

Q: How should teams evaluate trust signals for agent plugins?

A: Separate provenance, scan results, and runtime privilege into different checks.

Practitioner guidance

• Enforce namespace ownership at publish time Require registry checks that block any plugin whose scope does not match a verified owner before it can be listed or installed.
• Review high-privilege agent plugins first Prioritise plugins that can run commands, export configuration, or reach external APIs, because those are the ones that turn provenance failures into operational risk.
• Separate scan status from trust status Treat a clean scan as one signal, not a provenance verdict, and keep publisher verification and namespace claims as distinct approval gates.

Bottom line: The core failure is not just misleading plugin names, but the absence of enforced ownership at the namespace boundary.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →