Agent baiting turns fake MCP servers into a malware supply chain

At a glance

What this is: This research shows how fake AI Skills and MCP servers were used to distribute malware through GitHub repositories, public registries, and agent-readable instructions.

Why it matters: It matters because IAM, NHI, and emerging AI agent governance teams now have to control not just credentials and permissions, but also the discovery and installation paths that let malicious capabilities enter the enterprise.

By the numbers:

• The FakeGit operation recorded more than 14 million measured downloads.
• Island security research uncovered about 7,600 malicious GitHub repositories.
• 800 of them posed as AI Skills or, Skills or MCP servers.
• The campaign appeared more than 600 times across public AI registries and catalogs.

👉 Read Island's analysis of the FakeGit operation and AgentBaiting

Context

AI capability supply chain risk is what happens when repositories, registries, and installation instructions become the path into the enterprise instead of formal software approval. In this case, the primary identity problem is not a human clicking a bad link, but an AI agent or user being steered toward a malicious capability that looks legitimate enough to install.

For IAM and NHI practitioners, the governance gap is broader than secrets exposure alone. AI Skills, MCP servers, and agent plugins create a new discovery layer where trust is inferred from README text, profile similarity, stars, and registry visibility, none of which establish legitimacy.

Island's findings are typical of how modern supply-chain abuse evolves: attackers do not need to break into a target when they can publish into the target's discovery workflow and let the workflow pull the malware in itself.

Key questions

Q: How should security teams govern MCP servers used by AI coding assistants?

A: Treat MCP servers as privileged trust boundaries, not simple data sources. Security teams should classify each server by the authority it can influence, sanitize any user-generated or third-party content before delivery, and limit the agent’s tool access so malicious context cannot easily become destructive action.

Q: Why do public registries make malicious AI capabilities more dangerous?

A: Public registries can amplify trust by reproducing attacker-written README instructions and making a repository easier to find. That means discovery through a registry is not proof of legitimacy. Security teams should treat registry presence as a distribution channel, then verify publisher identity, package contents, and setup behaviour separately.

Q: What do teams get wrong about AI agent discovery?

A: Teams often treat discovery as a one-time inventory exercise, but AI-connected access changes as users add apps, permissions, and workflows. Discovery only has lasting value when it feeds ownership, classification, and recertification. Otherwise the inventory becomes a static list of already outdated identities and permissions.

Q: Who is accountable when AI tools are abused to support malware operations?

A: Accountability sits across AI governance, security operations, and identity ownership. Teams that approve models, expose them to users, or connect them to tools need documented controls for abuse detection, access restriction, and incident response. Where AI assistants are integrated into workflows, governance must cover both the model and the permissions around it.

Technical breakdown

How fake MCP servers become trusted installation paths

The attack works by making a malicious repository look like a normal capability. FakeGit copied or fabricated projects, used lookalike developer identities, and wrote READMEs that framed malware execution as standard setup. For MCP servers and AI Skills, that matters because the installation path often begins with repository discovery, then shifts into a manual or agent-assisted download, extraction, and execution sequence. The repository does not need to be technically sophisticated if the surrounding trust signals are convincing enough to move a user or agent into execution.

Practical implication: treat repository discovery and capability approval as security controls, not just developer convenience.

Why agent-readable instructions change the threat model

Agent-readable instructions are text that an AI agent can parse, follow, and repeat on behalf of a user. In this campaign, the README itself became the delivery mechanism, because Claude Code, Gemini, and ChatGPT could surface malicious repositories without a direct malicious link being provided. That shifts the attack surface from browser navigation to agent-mediated retrieval and recommendation. The security issue is not that the model is compromised, but that it can be persuaded to operationalise an attacker-written installation path.

Practical implication: govern what agents are allowed to discover, recommend, and hand back as installation guidance.

How SmartLoader turns a capability download into endpoint compromise

The payload chain is a familiar malware sequence hidden inside an AI capability wrapper. The malicious ZIP packages contained a launcher, a renamed runtime, and an obfuscated payload disguised as a harmless file. Once executed, SmartLoader established persistence, resolved command infrastructure, and installed StealC to harvest passwords, cookies, active sessions, extension data, and credentials. The AI angle does not change the malware mechanics, but it widens the path to execution by making the initial download seem operationally relevant.

Practical implication: inspect downloaded capability packages for executable launchers, disguised payloads, and post-execution persistence behaviour.

Threat narrative

Attacker objective: The attacker wants to turn AI capability discovery into endpoint compromise that yields credentials, active sessions, and other sensitive data.

1. Entry occurs when a user or AI agent discovers a malicious GitHub repository or registry listing that appears to be a legitimate Skill or MCP server.
2. Credential or code execution access is obtained when the README instructs the target to download, extract, and run a ZIP package that contains SmartLoader.
3. Escalation follows when SmartLoader establishes persistence, retrieves additional stages, and injects StealC into another process.
4. Impact is credential theft, session hijacking, and broader compromise of browser, developer, and cloud accounts.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agent baiting is the right named concept for this campaign pattern: the attack does not start with exploitation, it starts with capability discovery. A malicious repository is written so that a user or agent believes the README is documentation and the download is routine. That means the governance issue is not only repository trust, but the trust delegated to discovery surfaces, registries, and installation instructions. Practitioners should recognise agent baiting as a supply-chain control problem, not just a malware problem.

AI capability registries have become trust amplifiers, not trust validators: when public registries reproduce attacker-written READMEs, they move the same malicious instructions onto a second platform with additional legitimacy. This breaks the assumption that distribution through a registry implies review or vetting. For identity teams, the lesson is that visibility can create false assurance when the underlying object is still an unverified package or repository.

AI agent governance now intersects directly with NHI governance: the same enterprise controls that protect service account usage, secrets exposure, and privileged execution must now extend to agent-assisted software acquisition. An agent that recommends a package is not the same as an agent that executes code, but both can widen the path to compromise if the surrounding approval model is weak. The practical conclusion is that capability discovery needs the same scrutiny as credential issuance.

Lookalike developer identity is an identity security failure, not a branding trick: the campaign relied on profile similarity, copied names, and modest stars to substitute for actual assurance. That is a reminder that identity fraud applies to publishers as well as users. In an environment where AI agents can act on what they find, publisher identity becomes part of the access decision, and that decision should be treated as a governed control point.

From our research:

• the average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• That same research shows companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, which underlines how much of the control problem still sits in the build and release path, according to The State of Secrets in AppSec.

What this signals

Agent baiting should now be treated as a governance pattern, not an isolated malware case. If AI tools can independently surface and recommend third-party capabilities, then the enterprise needs review controls for discovery paths, not only for code execution. The control boundary has moved upstream into search, registry trust, and publisher identity.

Capability inventory is becoming an identity problem as much as a software problem. When a package can be discovered by an agent, endorsed by a README, and installed by a user, the missing control is not just malware detection but provenance enforcement across the acquisition path.

As NHI and agentic AI use expands, teams should expect more attacks that target the trust chain around tools rather than the tools themselves. That makes curated catalogs, isolated evaluation, and revocation-ready response processes the practical baseline for reducing exposure.

For practitioners

• Build a curated capability catalog Allow AI Skills, MCP servers, and agent plugins only from reviewed sources with known provenance, maintained versioning, and explicit approval for use in enterprise environments.
• Block executable capability packages by default Reject installations that rely on downloaded executables, ZIP launchers, or disguised payloads instead of source code, manifests, and auditable setup steps.
• Review agent discovery paths Log and constrain the repositories, registries, and search results that agents can surface for users, especially when the agent returns installation guidance.
• Track every AI capability in inventory Record source repository, commit, package hash, approval status, and owner so malicious repositories can be matched quickly against your environment.
• Contain suspected SmartLoader execution fast Isolate the endpoint and revoke active browser sessions, OAuth grants, API tokens, and cloud or developer credentials before further lateral use can occur.

Key takeaways

• Fake AI Skills and MCP servers can be used as a malware delivery path when discovery, trust, and installation are weak.
• The campaign's scale matters because more than 800 malicious repositories were framed as AI capabilities and spread across public registries.
• Security teams need governance over capability discovery, publisher identity, and package execution before agents or users can install untrusted software.

Key terms

• Agent Baiting: Agent baiting is the use of attacker-crafted content that persuades an AI agent to surface, recommend, or operationalise a malicious capability. It extends classic social engineering into agent-mediated discovery, where the instruction text itself becomes part of the delivery path.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• AI supply chain: The AI supply chain is the full chain of models, datasets, prompts, tools, and vendors that influence a deployed AI system. It matters because trust cannot be assigned to the application alone. Practitioners need provenance, ownership, and dependency visibility to govern risk.
• Lookalike Developer Identity: Lookalike developer identity is the practice of copying or nearly copying a legitimate publisher name or profile to borrow trust. In software and NHI contexts, the risk is that identity similarity is mistaken for provenance, especially when agents or busy users make quick approval decisions.

What's in the full article

Island's full research covers the operational detail this post intentionally leaves for the source:

• Per-repository examples of malicious AI Skills and MCP servers with their ZIP filenames and hashes.
• Detailed screenshots and walkthroughs of the AgentBaiting discovery flow across Claude Code, Gemini, and ChatGPT.
• Campaign infrastructure patterns, including lookalike developer identities and registry propagation behaviour.
• Representative IOCs and the full GitHub repository list for matching against internal inventories.

👉 Island's full post covers the repository examples, attack flow, and IOC list in detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.