TL;DR: A trojanized OpenClaw marketplace skill disguises itself as a reminder utility while silently installing a second package to collect API keys and .env files, base64-encode them, and exfiltrate them through a public dead-drop channel, according to ActiveFence. The case shows how emerging AI skill ecosystems can turn trusted packages into a credential theft path when runtime behaviour is not inspected before execution.
At a glance
What this is: ActiveFence documents a trojanized OpenClaw marketplace skill that hides credential-stealing behaviour behind a benign reminder workflow.
Why it matters: It matters to IAM and NHI teams because AI skills can behave like non-human identities with privileged access to files, secrets, and automation paths if marketplace trust is not governed.
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
👉 Read ActiveFence's analysis of the trojanized OpenClaw marketplace skill
Context
OpenClaw AI agent skills sit in a risky middle ground between software supply chain risk and identity governance. A package that can read files, install dependencies, and trigger background actions is not just code, it is an execution identity with access that needs lifecycle control, inspection, and revocation. The core issue in this article is not the reminder feature itself, but the hidden trust boundary around marketplace-distributed AI skills.
That boundary becomes more fragile when the skill can spawn a second package, run silently, and touch secrets files without user awareness. For IAM and NHI programmes, the lesson is that agent tooling introduces a new class of governed runtime access, while for broader application security teams it is a supply-chain and data-exfiltration problem. This pattern is increasingly typical in fast-moving AI ecosystems, not an edge case.
Key questions
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. That creates an invisible trust expansion. Security teams should require post-install inspection, dependency provenance checks, and runtime containment for any skill that can modify its own execution path.
Q: Why do AI-assisted development workflows increase secret exposure risk?
A: They increase exposure because developers move faster, paste more context into prompts, and review output for function before security. That combination makes secrets more likely to appear in code, logs, or old commits, and those secrets can remain valid long after discovery.
Q: How do organisations know if an AI marketplace package is behaving maliciously?
A: Look for mismatches between declared function and observed runtime behaviour. Warning signs include silent second-package installs, background jobs, unexpected file reads, Base64 encoding of sensitive data, and outbound calls to unfamiliar destinations. If the package needs hidden logic to work, assume the trust model is already compromised.
Q: What should teams do when an AI skill touches credentials or .env files?
A: Treat it as a credential-handling workload and apply containment immediately. Restrict file access, inspect process egress, rotate any exposed secrets, and review whether the skill can persist across restarts or schedule background activity. The key is to limit blast radius before the workflow can reuse the stolen data.
Technical breakdown
How trojanised AI skills turn trust into execution
A trojanised AI skill works by presenting benign functionality while embedding a second-stage payload in its installation or initialisation path. In this case, the package uses marketplace trust, dependency installation, and silent execution flags to move from user-approved installation into hidden runtime activity. That is effectively a supply-chain compromise inside an agent workflow. The important technical point is that the skill is not merely code loaded into an app; it is a privileged execution surface with file-system reach, background scheduling, and the ability to invoke other packages.
Practical implication: treat AI skills as governed executables and inspect their init logic before first run.
Why secret harvesting in agent workflows is hard to detect
Secret harvesting here relies on simple primitives: file discovery, content reading, Base64 encoding, and outbound HTTP POST requests. None of those individually look exotic, which is why signature-based review often misses the intent. The malicious logic blends into normal automation language such as backup, sync, and persistence. In identity terms, this matters because the workflow can access secrets outside the usual human login boundary, meaning the agent runtime becomes the effective bearer of trust. Once that runtime can see .env files or API keys, secrets governance becomes part of application execution, not just vault management.
Practical implication: instrument runtime file and egress monitoring for agent and skill processes, not only repository scans.
Dead-drop resolvers create low-friction exfiltration paths
Using a public notification topic or similar dead-drop channel lets attackers avoid a dedicated C2 infrastructure pattern that defenders expect. The exfiltrated data is encoded to reduce obvious inspection value, then posted over ordinary HTTPS traffic with local output suppressed. This creates a blended threat model where the theft path looks like benign telemetry or sync activity. For AI and NHI governance, the deeper issue is delegation without verification: the workflow is allowed to discover, package, and transmit secrets without any policy checkpoint tied to scope, destination, or purpose.
Practical implication: apply egress allowlisting and destination validation to agent workflows that can touch credentials.
Threat narrative
Attacker objective: The attacker aims to harvest reusable credentials and session secrets from AI-enabled workspaces for downstream account takeover and broader environment compromise.
- Entry occurs when a user installs a seemingly legitimate AI skill from the marketplace, giving the package initial execution trust inside the OpenClaw environment.
- Credential access happens when the hidden payload scans common workspace and config paths for .env and .mykey files, then reads and encodes their contents.
- Escalation follows when the initial package silently installs a second-stage module and establishes persistence through scheduled background execution.
- Impact is credential theft and silent exfiltration of sensitive secrets to a public dead-drop endpoint that can be monitored in real time.
Breaches seen in the wild
- Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
- Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Trojanised AI skills are becoming an NHI governance problem, not just a supply-chain problem. A skill that can install dependencies, read files, and schedule background work is operating as a non-human execution identity. That means its permissions, trust boundary, and revocation path need the same lifecycle thinking applied to service accounts and automation accounts. The governance failure is assuming a marketplace package is only software when it can actually act like a privileged runtime principal.
Secret theft in agent workflows exposes the gap between code review and runtime governance. Static inspection can miss hidden initialisation behaviour, especially when the malicious path is gated behind conditions, silent flags, or second-stage installs. That is why OWASP NHI controls and the broader supply-chain threat model need to be applied together. Practitioners should treat the runtime as the source of truth, because the harmful action happens after installation, not in the visible feature set.
Public dead-drop exfiltration is a named concept practitioners should recognise as dead-drop credential laundering. The attacker does not need a bespoke infrastructure stack when a legitimate public service can carry encoded secrets out of the environment. This complicates both detection and attribution because the data leaving the network appears to be ordinary HTTPS traffic. The practical conclusion is that destination trust must be policy-driven whenever an agent or skill can reach sensitive files.
AI marketplaces need lifecycle controls for packages that can behave like autonomous operators. The control gap is not whether a package is published, but whether its install-time and runtime behaviour is continuously verifiable after approval. This case suggests emerging AI ecosystems need stronger policy gates around package provenance, hidden dependency installs, and post-install permission changes. Practitioners should assume marketplace trust can be weaponised until runtime verification is in place.
From our research:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- From our research: DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys, according to the same report.
- For a wider pattern: Review The 52 NHI breaches Report for recurring credential exposure and misuse patterns across real incidents.
What this signals
Dead-drop credential laundering is the pattern security teams need to watch for in agent ecosystems: encoded secrets sent to legitimate public services can look like normal HTTPS activity unless process, destination, and content inspection are tied together. That makes runtime telemetry far more important than marketplace trust alone.
The practical signal is that AI skills are no longer a novelty layer on top of existing controls. They expand the set of software components that can read secrets, schedule tasks, and move data outward, so IAM, NHI, and application security teams need a shared policy model before adoption scales.
For teams building governance around agentic workflows, the right reference point is the OWASP NHI Top 10 and the Top 10 NHI Issues, because hidden execution, secret exposure, and uncontrolled delegation are converging into one operational risk class.
For practitioners
- Inspect skill initialisation paths before first execution Review SKILL.md, installer scripts, and any post-install hooks for hidden dependency downloads, silent flags, or secondary package execution. Focus on actions that can change trust boundaries after approval, not just visible features.
- Monitor agent runtimes for secret file access Alert on reads of .env, .mykey, token stores, and workspace memory paths from AI skill processes, especially when followed by Base64 encoding or outbound POST requests. This catches credential harvesting that bypasses source-code review.
- Restrict outbound destinations from AI workflows Apply allowlisting and egress validation so skills and agents cannot post to arbitrary public endpoints or dead-drop services. Tie the rule to the process identity and the file scope it is allowed to touch.
- Separate marketplace trust from runtime trust Approve distribution sources without granting unrestricted file-system or background execution permissions. Revalidate privilege whenever a skill adds dependencies, schedules jobs, or changes its behaviour after installation.
Key takeaways
- A trojanised AI skill can behave like a privileged non-human identity, which means marketplace trust alone is not a sufficient control boundary.
- The core failure mode is hidden runtime behaviour, where second-stage installs, secret reads, and silent exfiltration evade ordinary review workflows.
- Teams should combine runtime containment, secret file monitoring, and egress validation before AI skills are allowed to touch production credentials.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | The article centres on hidden secret exposure and malicious runtime behaviour in AI skills. |
| OWASP Agentic AI Top 10 | Agentic workflows are being used to disguise credential theft and covert execution. | |
| MITRE ATT&CK | TA0006 , Credential Access; TA0010 , Exfiltration; TA0003 , Persistence | The observed behaviour follows credential collection, persistence, and exfiltration tactics. |
| NIST CSF 2.0 | PR.AC-4 | The issue is uncontrolled access to files, secrets, and outbound communication paths. |
| NIST SP 800-53 Rev 5 | IA-5 | The package steals reusable credentials and must be governed as authenticator material. |
Map the skill's actions to ATT&CK and prioritise controls for credential access, persistence, and exfiltration.
Key terms
- Trojanised AI Skill: A trojanised AI skill is a package that presents legitimate functionality while embedding hidden malicious behaviour. In practice, it can install secondary payloads, read sensitive files, or alter runtime behaviour after approval, making it both a software supply-chain risk and an identity governance problem.
- Dead Drop Resolver: A dead drop resolver is a technique where malware stores its command or destination in an external location that can be updated without changing the malware itself. That makes the control plane harder to detect and block because the payload is decoupled from a fixed server address.
- Agent Runtime: The agent runtime is the execution environment where an AI agent reads data, calls tools, and carries out actions. It matters because the runtime is where identity, policy, and filesystem boundaries either hold or fail. If those boundaries are weak, the agent becomes a high-privilege path into the environment.
- Secret Harvesting: Secret harvesting is the extraction of credentials, tokens, or keys from an execution environment rather than from an authentication flow. It often targets files, memory, environment variables, and local configuration, which makes trusted developer and CI contexts high-value targets.
What's in the full report
ActiveFence's full blog covers the operational detail this post intentionally leaves for the source:
- The full malicious package structure and initialisation logic that enabled the hidden second-stage install.
- The proof-of-concept chain showing how secrets were encoded and sent to the dead-drop endpoint.
- The canary test method used to validate that the exfiltration path was active.
- The specific file paths and script behaviour that made the trojan hard to spot during review.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build the control model needed for AI skills, service accounts, and other non-human access paths.
Published by the NHIMG editorial team on August 21, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org