AI Agents Have a Supply-Chain Phishing Problem

The threat model for AI agents shifted last week. Researchers at Island published their analysis of FakeGit, a campaign that seeded roughly 7,600 malicious repositories on GitHub. More than 800 of those repositories masqueraded as legitimate agent skills or Model Context Protocol servers.

The attack vector has a name now: AgentBaiting. Instead of sending a developer a malicious link, attackers publish a convincing repository and wait for an AI agent to discover it. The README looks like normal documentation. The code structure follows conventions. But the implementation points to malware.

How the campaign worked

FakeGit was not a single repository. It was an industrial operation. Attackers created thousands of repositories with names like mcp-server-aws, claude-skill-github, agent-toolkit-slack — plausible names that developers or their agents would naturally search for.

The repositories included:

• Well-structured READMEs with installation instructions, usage examples, and configuration guides
• Legitimate-looking package.json or pyproject.toml files with realistic dependencies
• Entry points that executed obfuscated payloads on install or first run
• Some repositories were also submitted to public MCP and skill catalogs, giving them an additional veneer of credibility

In controlled tests, Island researchers found that Claude Code, Gemini, and ChatGPT all surfaced malicious campaign repositories without being given their URLs. The agents discovered these repos through normal search and discovery workflows.

Why this matters for MCP and agent developers

The Model Context Protocol ecosystem is young. The official registry at modelcontextprotocol/servers lists community servers, but there is no centralized, vetted distribution mechanism comparable to npm or PyPI. Discovery happens through GitHub search, community lists, and increasingly through the agents themselves.

Three factors make this especially dangerous for MCP:

1. Agents install and run code autonomously. When you ask Claude Code to "add GitHub integration," it may search for an MCP server, find one that looks legitimate, and propose installing it. The human review step is often a quick skim of the README.
2. MCP servers run with your credentials. A compromised server has access to whatever tokens you configured — GitHub PATs, API keys, database credentials. The blast radius is your entire connected infrastructure.
3. No trust signals exist in the protocol. An MCP server listing is discovery metadata, not a trust signal. The protocol does not include publisher verification, signature validation, or a reputation system.

The numbers that should change your workflow

Island's analysis puts scale on the problem:

• 7,600+ malicious repositories total in the FakeGit campaign
• 800+ specifically targeting AI agents and MCP
• 14+ million GitHub Release downloads recorded across the campaign (includes automation and repeated requests, not unique infections)
• Multiple public catalogs contained campaign repositories

The download count is inflated by automation, but the repository count is not. Eight hundred purpose-built traps for agent workflows is a meaningful surface area.

Practical defenses you can implement today

You do not need a security team to raise the bar. The researchers and the broader community converge on a short list:

1. Use an approved capability catalog

Maintain an internal allowlist of MCP servers and skills your team is permitted to use. Treat it like a package-lock file — reviewed, version-pinned, and updated deliberately. Do not let agents freely discover and install new capabilities in production workflows.

2. Verify publishers independently

Before adding a server to your catalog, confirm the publisher identity. Check the GitHub organization, look for verified badges, cross-reference with the official MCP organization or known vendors. A repository owned by a user created three weeks ago with two stars is not a publisher signal.

3. Pin versions and lock dependencies

Never run latest or unpinned references in production agent workflows. Pin to specific commit SHAs or tagged releases. Use dependency lock files. Treat MCP server installations with the same rigor you apply to production dependencies.

4. Test new skills in a credential-free sandbox

Before a new MCP server or skill touches your real credentials, run it in an isolated environment with no network access to your infrastructure. Verify its behavior — what files it reads, what network calls it makes, what commands it executes. Island's researchers did exactly this in their controlled tests.

5. Treat registry listings as discovery, not trust

A listing in a community catalog means someone submitted it. It does not mean anyone audited it. The FakeGit campaign proved that malicious repositories can and do appear in public catalogs.

The structural problem

AgentBaiting works because the current agent ecosystem optimizes for discovery speed over verification. Agents are designed to find tools, not evaluate them. The protocol layer (MCP) provides transport and capability negotiation — it does not provide supply-chain integrity.

This is not a flaw in MCP. It is a gap in the distribution layer that sits above it. The same gap exists for LangChain tools, CrewAI skills, OpenAI function definitions, and every other agent capability format.

Until a verification layer exists — signed packages, publisher attestation, reputation scoring, or a curated registry with admission controls — the burden falls on the developer. You are the gatekeeper.

What to watch next

Island's research notes that the FakeGit campaign is likely still active. The repositories they analyzed were created over several months. New ones appear regularly.

Expect to see:

• More sophisticated obfuscation — payloads that activate only in specific environments or after time delays
• Typosquatting on popular MCP server names (e.g., mcp-server-githhub)
• Compromised legitimate maintainer accounts used to publish malicious updates to previously trusted servers
• Attacks targeting the agent's own configuration files to persist across sessions

The mitigation is not to stop using agents or MCP. The mitigation is to treat agent-discovered code with the same skepticism you apply to a random npm package from an unknown maintainer — because that is effectively what it is.