Agent baiting turns fake MCP servers into a malware supply chain

At a glance

What this is: Island describes how the FakeGit operation used fake AI Skills and MCP servers to turn AI capability discovery into a malware supply chain.

Why it matters: IAM and security teams now need to govern how agents and users discover, vet, and install capabilities, because registry trust can be abused before any code ever runs.

By the numbers:

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

Context

Agentic capability discovery creates a new trust problem for identity security: the thing being installed can be disguised as documentation, a registry entry, or a familiar developer project. When AI agents can search for Skills or MCP servers on their own, the attack surface includes the discovery path, not just the runtime payload.

Island’s research frames FakeGit as a supply chain abuse pattern that uses public repositories, registries, and agent-readable instructions to move malware into enterprise workflows. That matters because governance now has to cover how capabilities are found, how they are validated, and how execution is isolated before any credentialed system is touched.

Key questions

Q: What breaks when a fake MCP server is treated as a trusted capability source?

A: The trust boundary collapses before code execution begins. A malicious repository can look like a normal install target, especially when the README, profile, and registry listing all reinforce the same false identity. That makes discovery and onboarding part of the attack path, not just the malware payload.

Q: Why do public AI registries increase the risk of capability supply chain abuse?

A: They multiply exposure and credibility at the same time. A malicious listing can reproduce attacker-written setup instructions, appear in multiple catalogs, and inherit legitimacy from the platform context. That makes registry presence a weak trust signal unless it is paired with provenance review and approved-source governance.

Q: How can security teams tell whether AI assistant configuration is being abused?

A: Look for unexpected network callbacks, unusual tool permissions in frontmatter, hidden model overrides, and repository content that behaves like executable policy. The signal is not just malicious output. It is privileged behaviour appearing in files that teams previously treated as static configuration.

Q: Should organisations allow employees to install agent skills without review?

A: No, not if those skills can access files, credentials, or business communications through the host agent. Even a well-meaning productivity skill can become a data path if it inherits broad permissions. Review, allowlisting, and runtime policy are the minimum controls for employee-installed agent extensions.

Technical breakdown

How fake MCP servers become a delivery channel

FakeGit combines social proof and packaging to make malware look like a normal capability install. The repository copies project names, uses lookalike profiles, and places a malicious ZIP behind an ordinary README, so the user or agent follows a routine install flow. In one common pattern, the archive contains a launcher, a renamed runtime, and a payload disguised as a text or data file. That structure matters because the malicious object is not the registry listing itself but the executable content hidden behind expected developer workflow steps.

Practical implication: treat capability downloads as executable code until an isolated inspection proves otherwise.

Why agent-readable instructions change the threat model

AgentBaiting works because an AI agent can independently retrieve a repository, read attacker-written setup instructions, and hand them back as if they were legitimate documentation. That is different from a human simply being fooled by a phishing page. The agent becomes a discovery and transcription layer that can amplify the attacker’s framing, especially when the repository is indexed by multiple public registries. The control gap is not only trust in the code, but trust in the guidance that accompanies it.

Practical implication: govern agent-initiated discovery paths with the same scrutiny you apply to user-driven downloads.

How registries amplify malicious capability exposure

Public registries add distribution, credibility, and repetition. Once a malicious Skill or MCP server appears in a catalog, the listing can reproduce the README, installation steps, and download links across another platform. That means the attacker no longer depends on one repository ranking high in search. The same lure can appear in multiple places, each time looking more established. For IAM teams, the issue is not just supply chain integrity in the software sense, but trust propagation across the capability ecosystem.

Practical implication: inventory every approved AI capability source and block installation paths outside that catalog.

Threat narrative

Attacker objective: The attacker wants to use trusted-looking AI capability discovery to deliver malware that steals credentials, active sessions, and other sensitive endpoint data.

1. Entry occurs when a user or AI agent discovers a fake Skill or MCP server through GitHub or a public registry and follows the attacker’s installation instructions.
2. Credential access happens after SmartLoader executes and installs StealC, which targets browser passwords, cookies, active sessions, extension data, and remote-access credentials.
3. Persistence and impact follow when the malware establishes footholds, retrieves staged payloads, and enables theft of credentials and sensitive endpoint data.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• GemStuffer RubyGems campaign 2026: AI agents attributed to OpenAI mass-created RubyGems accounts, ran code on RubyDoc build servers and probed a flaw to steal API keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agent-readable documentation has become part of the attack surface: The FakeGit wave shows that the installer README is no longer just support material, it can be the delivery mechanism. When an AI agent can retrieve and relay instructions without human scrutiny, attackers can weaponise ordinary setup language. The implication is that capability governance must treat discovery artefacts as security-relevant objects, not just user convenience.

Capability registries now function as trust amplifiers: Public listings do more than point to a repository, they copy the attacker's framing into another environment. That creates a form of trust propagation where one malicious project can look legitimate in multiple places. For practitioners, the lesson is that registry presence is not validation, and governance models that rely on catalogue visibility alone are incomplete.

AgentBaiting is a named capability-supply-chain pattern, not a one-off lure: It describes the point where an AI agent independently surfaces a malicious capability and carries attacker instructions forward. This breaks the assumption that a human must knowingly click a bad link before malware can enter the workflow. Security teams need to recognise that discovery, not execution, is now one of the earliest compromise opportunities.

Identity security for AI capabilities must include provenance, not just permissioning: A repository that looks authoritative can still be hostile, and a credentialed user or agent can be compromised by the install step itself. The real control question is whether the capability came from a reviewed source, under a known identity, with a verifiable package history. That makes provenance a first-class governance requirement for AI capability ecosystems.

Registry trust debt: The ecosystem has allowed public AI capability indexes to accumulate credibility faster than they can prove provenance. Once that trust debt exists, malicious listings can borrow legitimacy from the platform layer instead of the code layer. Practitioners should treat capability discovery channels as governance domains in their own right, not as informal directories.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: MCP Security Guide

What this signals

Registry trust debt: Public capability indexes can outrun the governance controls that should validate what they list, which means discovery channels need the same policy attention as runtime controls. Once that happens, AI agents can inherit attacker framing before any code is executed.

Agent-initiated discovery forces a change in how teams think about access boundaries. The question is no longer only whether a package can run, but whether a machine identity or agent can be tricked into recommending the package in the first place.

For practitioners

• Build a curated capability catalog Approve Skills, MCP servers, and agent plugins through a controlled catalog so users and agents have a safe default path for installation.
• Inspect every new capability in isolation Use an isolated environment with no browser sessions, cloud credentials, SSH keys, or production data before allowing any capability to run.
• Verify publisher identity and package provenance Check the repository owner, commit history, release asset structure, and package hash before trusting a capability that claims to be an MCP server or Skill.
• Inventory all active AI capabilities Track source repository, version, commit, and hash so malicious campaign repositories can be matched against your environment quickly.
• Revoke sessions after suspected execution If SmartLoader activity is suspected, isolate the endpoint and revoke browser sessions, OAuth grants, API tokens, and developer credentials.

Key takeaways

• The central problem is not only malware packaging, but the use of AI capability discovery as an entry point into trusted workflows.
• Island’s research ties the FakeGit campaign to about 7,600 malicious repositories, more than 800 fake Skills or MCP servers, and over 14 million downloads.
• The most effective control shift is to govern provenance, discovery, and isolated inspection before any agent or user can install a capability.

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.
• Capability Supply Chain: The path a skill, plugin, or connector takes from discovery through approval and installation to runtime use. For AI systems, that supply chain includes repositories, registries, package assets, README instructions, and the identities behind them, all of which can be manipulated to deliver malware or unsafe access.
• Registry Trust Propagation: The way credibility spreads when a listing is copied across multiple catalogs or platforms. In AI capability ecosystems, repeated appearance can make a malicious repository look established even when the underlying package, publisher identity, or installation instructions remain unverified.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.