Between July 11 and August 2, someone uploaded trojanized AI agent skills to the skills.sh marketplace. By the time Zenity's research team flagged them, these malicious skills had been downloaded over 1.7 million times. The payload? A credential stealer targeting developer workstations, CI runners, and agent workspaces.
This was an active campaign exploiting a supply chain most security teams haven't started monitoring yet.
What Happened
An attacker uploaded what appeared to be legitimate AI agent skills to skills.sh, a marketplace where developers share and download pre-built capabilities for AI agents. These skills contained embedded credential-harvesting logic disguised within configuration files.
The malicious code specifically targeted:
- Developer workstations
- CI/CD runners
- Agent workspace environments
Once installed, the trojanized skills collected sensitive credentials from these environments and exfiltrated them to attacker-controlled infrastructure. The skills themselves looked functional enough to avoid immediate suspicion, which explains the download velocity.
Timeline
July 11: Initial upload of trojanized skills to skills.sh marketplace
July 11 - August 2: Skills accumulate 1.7 million downloads across the platform
August 2: Zenity research team identifies and reports the malicious skills
The three-week window between upload and detection represents exactly the kind of dwell time that makes supply chain attacks effective. Your developers weren't downloading obviously malicious code. They were pulling what looked like productivity tools from a public marketplace.
Which Controls Failed
This incident exposed gaps in multiple control areas:
Supply chain validation: No verification process existed to validate skills before they appeared in the marketplace. Unlike package repositories that implement maintainer verification or signing requirements, the skills marketplace operated without baseline trust mechanisms.
Configuration file scanning: Traditional security tools don't inspect AI agent configuration files for malicious logic. Your SAST tools scan application code. Your SCA tools track dependencies. But YAML files defining agent behaviors? Those slip through.
Behavioral monitoring: Organizations had no visibility into what their AI agents were actually doing at runtime. If an agent starts accessing credential stores or making unexpected network connections, that should trigger alerts. It didn't.
Dependency provenance: Teams had no way to track where their AI skills came from or verify their integrity after download. The same supply chain transparency you apply to npm packages or Docker images didn't exist for AI components.
What the Standards Require
The NIST Cybersecurity Framework v2.0 calls for supply chain risk management under the Identify function (ID.SC). Specifically, you need to establish criteria for supplier selection and maintain visibility into your supply chain components. AI skills from public marketplaces are supply chain components. They require the same scrutiny as any third-party code.
ISO/IEC 27001:2022 addresses this in Annex A.5.19 through A.5.23, which cover information security in supplier relationships. Control A.5.21 specifically requires managing information security within ICT supply chains. When your developers download AI skills, that's an ICT supply chain transaction. You need controls around it.
PCI DSS v4.0.1 Requirement 6.3.2 demands that you maintain an inventory of bespoke and custom software. If you're processing cardholder data in environments where AI agents operate, those agent skills are custom software components. They belong in your inventory, with version tracking and integrity verification.
NIST 800-53 Rev 5 gets more specific with control SA-12 (Supply Chain Protection). The control requires organizations to employ integrity verification mechanisms for software and firmware. Configuration files defining agent behavior qualify as firmware-equivalent components in this context.
None of these standards explicitly mention AI agents or skills marketplaces because they're newer than the standards. But the principles apply directly: know what's in your environment, verify its integrity, and monitor its behavior.
Lessons and Action Items
1. Treat AI skills as code dependencies
Add AI agent skills to your software bill of materials. Track what you've downloaded, from where, and when. Use the same hash verification you apply to container images. If you can't verify a skill's integrity, don't run it in production environments.
2. Implement configuration file scanning
Extend your security scanning to cover AI agent configuration files. Look for:
- Credential access patterns
- Network call definitions
- File system operations
- Environment variable references
Services like AI Total (mentioned by Zenity) offer specialized scanning for AI components, but you can start with basic pattern matching in your existing SAST pipeline.
3. Segment agent environments
Your AI agents don't need access to production credential stores or CI secrets. Create isolated workspaces with minimal privileges. If an agent gets compromised, limit what it can reach. This is basic least-privilege, applied to a new component type.
4. Monitor agent runtime behavior
Deploy behavioral monitoring for your AI agents. Track:
- What credentials they access
- Which network endpoints they contact
- What files they read or write
- What APIs they call
Deviations from expected behavior should trigger alerts, just like they would for any other application component.
5. Establish a skills approval process
Don't let developers download AI skills directly into production environments. Create an internal marketplace or approval workflow where security reviews new skills before they're available to your teams. Yes, this adds friction. That's the point.
6. Validate marketplace sources
If you're using public AI skills marketplaces, maintain an allowlist of trusted publishers. Better yet, fork approved skills into your own internal repository where you control updates and can apply your own integrity checks.
The 1.7 million downloads in this campaign prove that AI supply chain attacks aren't theoretical. Your developers are downloading these components right now. The question isn't whether you need controls around AI skills. It's whether you'll implement them before or after your credentials end up in an attacker's database.
