TL;DR: Official-looking ClawHub scopes can mislead users even when ownership is missing, according to Manifold Security. Agent registries need verified namespace ownership before code-executing plugins can inherit trust inside an agent environment.
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: 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.
Q: What breaks when AI agent plugin namespaces are not ownership-verified?
A: The trust model breaks first.
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.
Glossary terms: Scope Squatting, Namespace Ownership, Provenance Signal, Runtime Privilege
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Namespace trust without enforced ownership is a broken control, not a documentation issue. ClawHub documented the rule that scope should match owner, but the registry still allowed unauthorized use of official-looking namespaces. That means the control existed on paper while the enforcement boundary remained porous, which is exactly how impersonation enters a supply chain. The practitioner lesson is to audit where your own registries rely on naming as a trust signal instead of validated publisher authority.
A few things that frame the scale:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Who should be able to claim or reclaim a reserved namespace?
A: Only the verified owner of the org, brand, or namespace should be able to claim it, and the registry should provide a formal dispute path for rightful recovery. That process needs public proof requirements, revocation handling, and clear ownership records so squatting cannot persist.
👉 Read our full editorial: Official-looking plugin scopes create trust risk in AI agent supply chains