10 Aug 2026 11 min read Cybercrime

Trojanized AI Skills Hit 1.7M Installs: Securing the Agent Supply Chain

Zenity Labs revealed at Black Hat USA 2026 that trojanized AI agent skills accumulated over 1.7 million installs via a public registry, exfiltrating SSH keys, cloud credentials, and CI/CD secrets. Here is what happened, why traditional security tooling missed it, and the concrete controls you can...

The AI agent ecosystem has just received its first major supply chain wake-up call — and the security community's response reveals how unprepared most organisations actually are.

On 6 August 2026, Zenity Labs walked onto the Black Hat USA stage with evidence of an active credential-stealing campaign that had quietly accumulated over 1.7 million installs through a public AI agent skills registry. The attack was not sophisticated in the traditional sense — it relied on a technique as old as open-source package registries themselves. What made it alarming was where it landed: inside the emerging, largely unguarded infrastructure that developers use to extend AI agents. It is arguably the clearest proof yet that attackers are not waiting for AI to mature before exploiting it.

This article examines what happened, how the attack worked mechanically, what the credential-stealer actually harvested, and — critically — what risk controls from the latest agentic security and AI governance frameworks you can apply right now to reduce your exposure.

What Happened: The Skills.sh Campaign

Zenity Labs discovered that threat actors had uploaded trojanized "skills" — shareable instruction files that extend the capabilities of AI agents — to skills.sh, a public registry operated by Vercel. The malicious uploads began on 11 July 2026, and by early August the tainted skill family had accumulated more than 1.7 million aggregate installs before discovery and disruption.

The attack technique was typosquatting (publishing packages with subtly misspelled names to impersonate legitimate ones) — a method that has plagued npm and PyPI for years, now migrated into the AI agent layer. Attackers cloned legitimate, trusted skills from two real AI services — Paperclip and Browse (also reported as "Browser Use") — and published near-identical look-alikes. Developers and automated pipelines grabbing skills by name could easily pull the malicious version instead of the genuine one.

Critically, Zenity notes that the skills initially appeared clean, accumulating a credible download count before the malicious payload was introduced — a "bait-and-switch" timing strategy designed to evade early scrutiny.

Once installed, the trojanized skills instructed AI agents to download and execute credential-stealer payloads hosted on GitHub. The targets were deliberate: developer workstations and CI/CD systems, precisely the environments where high-value secrets are most likely to be present and least likely to be monitored for agent-driven exfiltration.

According to TechRadar's reporting on the Zenity research, the credential-stealer was specifically engineered to harvest:

SSH keys
Cloud credentials (AWS, Azure, GCP)
Git and package manager tokens
Kubernetes and Docker configurations
Database credentials
Infrastructure-as-code (IaC) credentials
Environment files (.env)
Service account files

The stolen data was packaged with host metadata and exfiltrated to attacker-controlled infrastructure. This is not a generic credential grab — it is a precision strike against the secrets that control cloud infrastructure, deployment pipelines, and software supply chains downstream.

Zenity also reported finding dozens of additional malicious AI agent skills beyond the headline family in public registries. As the company stated in its Black Hat disclosure: "The research also uncovered dozens of additional malicious or dangerous skills in public registries… designed to deliver malware, manipulate agent configurations, exfiltrate data and execute attacker-controlled instructions." This was not a one-off experiment — it was a systematic campaign probing the ecosystem.

The campaign was disrupted by Zenity and Vercel upon discovery, and the malicious skills were removed. However, any organisation that installed the tainted skills between 11 July and early August 2026 should treat their developer and CI/CD credentials as compromised.

The Attack Surface: Why AI Agent Skills Are Different

To understand why this matters beyond a standard supply chain incident, it helps to understand what an AI agent "skill" actually is — and why it represents a more dangerous dependency than a traditional code package.

A traditional malicious npm package executes code on installation or import. Detection tooling — static analysis, SCA scanners (software composition analysis tools that identify known-vulnerable dependencies), runtime monitoring — has years of maturity in catching this. An AI agent skill, by contrast, is an instruction file that shapes what the agent decides to do. It does not necessarily execute code directly; it manipulates the agent's reasoning and action selection. This distinction has three important consequences.

Firstly, traditional SAST/DAST tools do not inspect it. A skill file may contain no code at all — just natural language instructions or structured configuration that directs agent behaviour. Secondly, the agent becomes the execution engine. The malicious actor does not need to smuggle an executable past your defences; they instruct a trusted, already-running AI agent to perform the malicious action on their behalf. Finally, the blast radius is determined by the agent's permissions. If your CI/CD agent has access to your entire secrets vault, a malicious skill can direct it to exfiltrate everything the agent can reach.

As Zenity stated in their disclosure: "For AI agents, the supply chain extends beyond traditional code dependencies to include skills, tools, MCP servers, packages, files and any content on the internet. Each can influence agent behavior."

This framing is important for risk teams: the AI agent supply chain is not a subset of the software supply chain — it is an extension of it, with different threat vectors and currently far weaker controls.

Why It Matters: CI/CD Pipelines and the Downstream Blast Radius

The credential-stealer's focus on CI/CD pipelines deserves particular attention. A compromised developer machine is serious; a compromised build pipeline is catastrophic. When an AI agent operating inside a CI system silently exfiltrates credentials, the blast radius extends to every service, repository, and cloud environment that pipeline touches.

Consider the chain of impact:

Stolen AWS credentials from a CI pipeline can grant access to production infrastructure, S3 buckets containing customer data, and Lambda functions.
Stolen GitHub tokens can enable code injection into repositories, poisoning future software releases.
Stolen Kubernetes configs can expose container orchestration, enabling lateral movement across microservices.
Stolen IaC credentials (Terraform, Pulumi) can allow attackers to provision or destroy cloud infrastructure at will.

This is the supply chain attack scenario that security teams have feared for years — now delivered not through a compromised npm package, but through an AI agent that was trusted to act autonomously on behalf of the developer.

The broader implication, flagged by CSO Online's 4 August analysis of malicious AI instruction files, is that "AI agents are increasingly being deployed across the enterprise, a rapid adoption that has significantly broadened the organization's attack surface, turning sharable AI agent resources and configuration files into backdoors." The skills.sh campaign is the live-fire proof of that warning.

Risk Control Framework: Applying Agentic Security Standards

This is where the conversation must shift from incident analysis to risk governance. The good news is that the security and AI governance communities have been developing frameworks specifically for agentic AI risks. The skills.sh campaign maps cleanly onto several emerging control categories.

1. AI Agent Software Bill of Materials (AI-SBOM)

The most direct parallel to established supply chain security practice is the Software Bill of Materials (SBOM) — a machine-readable inventory of every component in a software system. SBOM mandates for traditional software were accelerated by the US Executive Order on Cybersecurity (EO 14028, 2021) and CISA's subsequent guidance. The skills.sh campaign makes the case for an AI-SBOM that extends this inventory to include:

Every skill, tool, and MCP server an agent can invoke
The registry source and version hash of each skill
The permissions and data access scope each skill can trigger
The provenance chain (who published it, when, and with what signing)

Without an AI-SBOM, organisations cannot answer the most basic post-incident question: "Do we have any agents that installed skills from skills.sh between 11 July and 2 August 2026?" The organisations that can answer that question quickly are the ones that have already built this inventory. The ones that cannot are still searching.

The NIST AI Risk Management Framework (AI RMF 1.0, published January 2023) identifies supply chain risk management as a core governance function under its "GOVERN" category. Whilst the framework predates the current wave of agentic deployments, its principles apply directly: treating each skill as a third-party component subject to the same vendor risk assessment you would apply to a software library.

2. Skill Provenance and Signing

The typosquatting attack succeeded in part because skills.sh did not enforce cryptographic signing of published skills. In the traditional package ecosystem, tools like Sigstore (used in npm and PyPI signing initiatives) allow consumers to verify that a package was published by the claimed author and has not been tampered with since publication.

The AI agent ecosystem needs equivalent controls. Specifically:

Publisher identity verification before a skill can be listed in a public registry
Cryptographic signing of skill packages at publication time
Hash pinning in agent configuration files, so an agent only loads a skill if its content matches a known-good hash
Timestamp transparency logs (similar to Certificate Transparency) that make it auditable when a skill's content changes after initial publication — directly countering the bait-and-switch timing strategy used in this campaign

3. Least-Privilege Agent Architecture

The credential-stealer's effectiveness was amplified by agents running with broad permissions. The principle of least privilege — a foundational control in every major security framework including NIST SP 800-53, ISO 27001, and the OWASP Top 10 for LLM Applications — applies directly to AI agents.

The OWASP Top 10 for LLM Applications explicitly lists "Excessive Agency" (LLM08 in the 2025 edition) as a top risk, defining it as: "An LLM-based system is granted the ability to call functions or interact with other systems via tools/plugins, and the excessive permissions granted to the LLM enable undesirable actions with unintended consequences."

In the context of the skills.sh attack, an agent with read-only access to a specific secrets scope cannot exfiltrate SSH keys it was never permitted to read. As discussed in the attack surface section above, the blast radius is determined entirely by the agent's permissions. Practical controls include:

Scoped secrets access: agents should only have access to the specific credentials they need for their defined task, not the entire secrets vault
No persistent credential storage in agent working memory
Separate agent identities for different pipeline stages, limiting lateral movement if one agent is compromised
Human-in-the-loop approval for any agent action that involves credential access or external network calls

4. Agentic Behaviour Monitoring and Anomaly Detection

The skills.sh campaign persisted from 11 July to early August — nearly three weeks — before discovery. This window exists because most organisations have no behavioural monitoring for AI agent actions. Traditional endpoint detection and response (EDR) tools monitor process execution and file system access; they are not instrumented to flag an AI agent making an unusual outbound HTTP call to package credentials and send them to an external endpoint.

Emerging agentic security platforms are beginning to address this gap. Zenity's own AI Total tool, announced alongside this research, is one example. However, the underlying control requirements are vendor-agnostic:

Agent action logging: every tool call, skill invocation, and external request made by an agent should be logged with sufficient detail to reconstruct what happened
Anomaly baselines: establish what "normal" agent behaviour looks like for a given workflow, and alert on deviations (e.g., an agent that normally calls three tools suddenly making outbound calls to GitHub raw content URLs)
Exfiltration detection: monitor for agents packaging and transmitting data to external endpoints, particularly when that data matches patterns for credentials or configuration files
Registry call monitoring: alert when an agent installs or updates a skill outside of an approved change window

5. Private Registries and Allowlisting

The most direct mitigation for typosquatting attacks is to not use public registries in production. The same principle that led security-conscious organisations to mirror npm packages in private Artifactory or Nexus repositories applies here:

Maintain a private, curated skills registry for production agent deployments
Allowlist approved skills by name, version, and hash — agents should not be able to install arbitrary skills from public registries at runtime
Apply a review and approval process before any new skill is added to the approved registry, including manual inspection of the skill's instruction content
Freeze skill versions in production, requiring an explicit change process to update

6. Incident Response Playbook for AI Agent Compromise

Most organisations have incident response playbooks for malware on endpoints and credential theft from applications. Very few have playbooks for AI agent compromise. The skills.sh campaign defines the minimum playbook requirements:

Detection trigger: alert on agent skill installation from public registries outside approved change windows
Containment: ability to immediately revoke an agent's credentials and disable its registry access without stopping the underlying pipeline
Inventory query: ability to answer within 30 minutes which agents have which skills installed, and from which registry version
Credential rotation: pre-defined runbooks for rotating every credential class the agent had access to (SSH keys, cloud credentials, tokens, etc.)
Forensic logging: sufficient agent action logs to reconstruct what the agent did between skill installation and containment

What You Should Do Right Now

Immediate Actions (This Week)

Audit your agent skill inventory. Identify every AI agent in your organisation that uses skills.sh or any other public skills registry. Determine which skills are installed and from which versions. If any agent installed skills between 11 July and 2 August 2026, treat all credentials accessible to that agent as compromised and rotate them immediately.
Check for the specific typosquatted skill families. The campaign targeted look-alikes of Paperclip and Browse/Browser Use skills. Verify your agents are using the legitimate, official versions from verified publishers.
Revoke and rotate broadly if in doubt. SSH keys, cloud credentials, Git tokens, Kubernetes configs, and .env files accessible to any potentially exposed agent should be rotated. The cost of rotation is far lower than the cost of a cloud infrastructure breach.
Disable public registry access for production agents. Until you have a private registry and allowlist in place, consider blocking agent access to skills.sh and other public registries in production environments.

Short-Term Actions (Next 30 Days)

Build an AI-SBOM. Inventory every skill, tool, and MCP server in use across your agent deployments. Include publisher, version, hash, and permission scope. As noted above, this is the foundational control that enables all subsequent supply chain risk management.
Apply least-privilege to all agents. Audit agent permission scopes and reduce to the minimum required for each defined task. Pay particular attention to CI/CD agents with broad secrets access.
Implement agent action logging. Ensure every agent tool call and external request is logged with enough detail to support forensic investigation.
Establish a private skills registry. Mirror approved skills internally and enforce allowlisting in agent configurations.
Review OWASP LLM Top 10 (2025). Map your current agent deployments against the Excessive Agency (LLM08) and Supply Chain (LLM05) risk categories and identify gaps.

Strategic Actions (Next 90 Days)

Integrate AI supply chain risk into your existing vendor risk management programme. Treat public AI registries as third-party vendors and apply appropriate due diligence.
Develop an AI agent incident response playbook. Define detection triggers, containment procedures, credential rotation runbooks, and forensic requirements specific to agent compromise scenarios.
Engage with emerging AI security standards. Monitor CISA's AI security guidance, NIST AI RMF updates, and the OWASP LLM project for evolving control recommendations as the agentic ecosystem matures.
Evaluate agentic security tooling. Purpose-built platforms for AI agent security monitoring are emerging rapidly. Evaluate whether your current security stack has the visibility needed to detect agent-driven exfiltration.

The Bigger Picture: A Supply Chain Category That Did Not Exist Two Years Ago

The skills.sh campaign is not an isolated incident — it is the opening chapter of what will be a sustained campaign against AI agent infrastructure. The pattern is familiar to anyone who has watched the evolution of supply chain attacks against npm, PyPI, and container registries: attackers identify a new, fast-growing ecosystem with weak governance, establish a foothold with low-effort techniques (typosquatting, bait-and-switch timing), and iterate toward more sophisticated methods as defenders catch up.

What makes the AI agent supply chain uniquely dangerous is the autonomy multiplier. A malicious npm package requires a developer to import it and run the affected code. A malicious AI agent skill can direct an already-trusted, already-running agent to take actions that no human explicitly authorised — and to do so in ways that existing security tooling is not instrumented to detect. The agent is not the attacker; it is the unwitting accomplice.

The security frameworks needed to address this exist in nascent form — AI-SBOM concepts, OWASP LLM Top 10, NIST AI RMF, emerging agentic security platforms — but adoption is lagging far behind deployment. The organisations that close that gap now, before the next campaign, are the ones that will not be rotating credentials and explaining pipeline breaches to their boards in 2027.

It is worth noting that the 1.7 million figure represents aggregate downloads, not unique victims. Despite this, the signal is unambiguous: the AI agent supply chain is an active attack surface, and treating it as anything less is a risk decision that has already cost some organisations dearly.