Topic starter
18/08/2026 3:02 pm
TL;DR: Snyk’s ToxicSkills audit found 1,467 flawed skills across 3,984 scans, while Antiy CERT’s ClawHavoc analysis showed malicious supply chain poisoning at registry scale, per Obot’s reporting. The core issue is governance lag: agent skills inherit agent permissions, so prompt injection, memory poisoning, and credential theft become a single control problem rather than separate risks.
Editorial analysis by NHI Mgmt Group, based on content published by Obot: “The New Supply Chain Frontier: Securing MCP Security and Agent Skills”.
By the numbers:
- Snyk’s ToxicSkills audit found 1,467 malicious payloads across 3,984 scanned skills.
- Snyk said 36.82% of all skills, 1,467 total, contained at least one security flaw.
- Antiy CERT documented ClawHavoc, which poisoned 1,184 skills on ClawHub.
Key questions
Q: What breaks when MCP skills are allowed into production without registry governance?
A: The control failure is that a skill can enter through a trusted-looking registry entry and immediately inherit the agent’s permissions.
Q: Why do malicious skills create a bigger risk than ordinary code dependencies?
A: Malicious skills can influence what an agent does after load time, including tool selection, command execution, and data handling.
Q: How do you know if MCP security controls are actually working?
A: You know MCP controls are working when untrusted endpoints are blocked, privileged tool calls are minimal, and audit logs show only approved commands and data flows.
Practitioner guidance
- Govern skill publishing as a trusted access event Require provenance checks, review, and approval before a skill enters any registry used by production agents.
- Scope agent permissions at the skill level Map every skill to the minimum file, network, cloud, and memory access it actually needs, then block installation when the declared scope is broader than the task requires.
- Detect hybrid prompt and malware patterns Scan for natural-language instructions that manipulate tool choice, archives that evade inspection, and obfuscated credential-harvest commands in the same skill package.
Bottom line: Agent skill registries now behave like a security boundary, because trusted selection can lead directly to privileged execution.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:41 pm
Agent skill registries have become a governance boundary, not a documentation layer. Once a skill can shape tool choice, prompt flow, and runtime permissions, the registry becomes part of the control plane. That shifts responsibility from developer convenience to access governance, provenance, and approval discipline. For identity teams, the lesson is that non-human actors now consume trust through packaging as much as through authentication.
A few things that frame the scale:
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
- 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 is accountable when a poisoned agent skill steals credentials or changes memory?
A: Accountability should sit with the team that owns registry governance, agent permission design, and incident recovery, not only with the developers who wrote the skill. The article shows these are coupled controls. If approval, runtime access, and persistence are managed separately, no one owns the full risk path.
👉 Read our full editorial: MCP skills are now a mature attack surface, not an edge case