Topic starter
21/08/2026 4:49 pm
TL;DR: OpenClaw's trojanised skill used a marketplace install path to expand trust into secret theft, according to ActiveFence. Skill runtimes need limits on file access and outbound traffic, or a hidden payload can read credentials after approval.
Editorial analysis by NHI Mgmt Group, based on content published by ActiveFence: “We Audited the OpenClaw Marketplace. We Found a Trojan.”.
Key questions
Q: Why do trojanized AI skills create supply-chain risk for credentials?
A: They turn a trusted distribution channel into a secret-harvesting path.
Q: What are the signs that shadow AI is leaking secrets?
A: Look for prompts containing API keys, tokens, connection strings, customer data, or regulated information, especially when the same workstation also runs local models or AI plugins.
Q: What breaks when an AI skill can install hidden dependencies after approval?
A: The approval model breaks because users think they are authorising one package, but the runtime can pull in a second payload with different behaviour.
Practitioner guidance
- Inspect skill installation paths for hidden dependency pulls Review marketplace skills for secondary installs, nested packages, or startup hooks that can introduce unapproved code after the initial approval step.
- Block access to high-risk secret file locations Constrain AI workloads so they cannot freely enumerate .env files, workspace memory, or other secret-bearing paths unless a specific task requires it.
- Detect outbound exfiltration to public dead-drop services Alert on encoded payloads, unusual POSTs, and repeat use of public notification or paste services from AI runtime processes.
Bottom line: This case shows that an AI skill marketplace can be used to distribute a trojanised package that turns ordinary installation trust into secret theft.
Glossary terms: Trojanised AI Skill, Dead-Drop Exfiltration, Skill-Chain Credential Exposure, Runtime Behaviour Monitoring
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
21/08/2026 5:07 pm
Trojanized skill ecosystems create a governance problem, not just a malware problem. Once a skill can install a second payload and read workspace secrets, the issue moves from package trust to runtime authority. That is especially true in agentic environments where execution may be triggered by a user action but continue invisibly in the background. Practitioners should treat skill execution rights as a governed identity boundary, not a convenience feature.
A few things that frame the scale:
- 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: How should security teams govern marketplace skills that can reach local files?
A: Apply a least-privilege model to skill execution, then add process and network monitoring that is specific to AI runtimes. The goal is to stop a skill from reading credential files or launching hidden dependencies unless that access has been explicitly justified and constrained by policy.
👉 Read our full editorial: Trojanized AI skills expose a supply-chain path to credential theft