Yes — the FakeGit campaign shows that an AI agent can independently find a fraudulent GitHub repository, treat its documentation as trustworthy, and pass malware installation instructions to a user. Companies deploy Claude Code, ChatGPT, Gemini, MCP servers, and workflow agents to build faster, integrate systems, and reduce operational effort — but an AI-generated tool recommendation is not a security validation of the publisher or the code.

This is not only a developer-security issue. It affects every organization where AI agents can access a browser, terminal, VPS, business data, API tokens, email, or production systems.

The key rule: an AI-generated tool recommendation is not a security validation of the publisher or the code.

What Are FakeGit and AgentBaiting?

FakeGit is a reported campaign that uses thousands of malicious GitHub repositories impersonating legitimate projects. Some of these repositories present themselves as AI skills, integrations, or Model Context Protocol (MCP) servers.

Researchers identified nearly 7,600 malicious repositories, including more than 800 masquerading as AI skills or MCP servers. In tests, AI systems and coding assistants were reported to discover such projects on their own while carrying out a user request, without receiving a direct malicious link first.

Researchers call this technique AgentBaiting. Attackers optimize a fake repository, profile, README file, and release assets so an AI agent treats the project as a useful answer to a request such as: “find a free MCP server for this service” or “find a skill to automate this task.”

Why a README Is Not Proof of Trust

A README can look professional, include screenshots, installation instructions, a known company name, and links to downloadable files. It is not independent proof of the code’s origin or safety.

With AgentBaiting, a malicious instruction does not need to reach an employee through phishing or a deceptive email. A company’s own AI assistant can deliver it as a seemingly useful operational recommendation.

What Is the Business Risk?

The most serious issue is not simply downloading an unknown repository. The risk comes from combining unverified code with the permissions, secrets, and access that the organization has already given to users and AI-enabled tools.

A malicious component may attempt to obtain:

• API tokens for AI services, CRM, automation, and cloud platforms;
• SSH keys used to access VPS infrastructure or repositories;
• .env files, configuration data, and locally stored credentials;
• active browser sessions, cookies, and SSO sessions;
• access to mailboxes, file systems, and administration panels;
• customer data, sales leads, and operational information.

In the reported campaign, SmartLoader malware was used to establish persistence and then deliver StealC, an information-stealing tool. After this type of incident, changing a password alone may be insufficient if active sessions, API tokens, or access keys have also been compromised.

Where Businesses Go Wrong

A common mistake is treating AI as a trusted security layer between employees and the open internet. An AI model can summarize information and perform tasks, but it does not replace a software supplier qualification process.

Risk rises when a company:

• allows agents to download files or execute README instructions automatically;
• uses one shared administrator account for testing, automation, and production;
• stores secrets in local files accessible to AI tools;
• installs MCP servers, extensions, and scripts without source controls;
• treats public tool directories as a list of approved solutions;
• has no inventory of active integrations, tokens, and service accounts;
• does not separate test environments from production.

In practice, an agent can be only the first step in an attack chain. Installing one seemingly convenient add-on may lead to credential theft, infrastructure access, and further movement within the organization.

How to Reduce AgentBaiting Risk

Effective protection does not mean banning AI. It means separating research from installation and limiting the impact of an incorrect recommendation.

1. Create an approved tool catalog. Maintain an internal allowlist of approved repositories, publishers, MCP servers, libraries, and extensions. Every new tool should have a business owner, a defined purpose, and a documented access scope. Do not treat GitHub stars, forks, directory placement, or a polished README as standalone security controls.
2. Verify the source before installation. Verify the repository owner and account history, whether the project name matches the vendor’s official website, commit history, releases, and contributor activity, the distribution method — especially when a README points to ZIP files or executable installers — dependencies and requested permissions, as well as signatures, checksums, and official publication channels where available.
3. Test new components outside production. A new MCP server, skill, or script should first run in an isolated test environment and should not receive access to production tokens, mailboxes, shared storage, or administrative panels. Use separate service accounts and least-privilege tokens. Read, write, email-sending, command-execution, and customer-system access should be granted separately, deliberately, and preferably for a limited time.
4. Require human approval. An AI agent may propose a tool, but it should not independently download and run executable files, install packages outside an approved catalog, modify infrastructure configuration, add tokens, keys, or credentials to a new tool, or execute commands copied from an external README. A practical operational rule is: AI may recommend, a human approves, and a test environment verifies.

What to Do After a Suspicious Installation

If an employee or AI agent has run an unverified component, treat the situation as a potential security incident. Do not assume uninstalling the tool removes every consequence.

Initial actions should include:

1. Isolate the device, container, or VPS from the network where appropriate.
2. Preserve evidence for analysis, including logs, command history, processes, scheduled tasks, and network activity.
3. Revoke and rotate API tokens, SSH keys, application passwords, and service-account credentials accessible from the affected environment.
4. Terminate active sessions, including SSO and SaaS sessions, rather than only changing passwords.
5. Review new accounts, scheduled tasks, email-forwarding rules, integrations, repository changes, and configuration changes.
6. Determine whether customer data, documents, credentials, or trade secrets may have been copied.

Expert Perspective

“Deploying AI agents without rules for acquiring tools is like allowing an unverified supplier direct access to company infrastructure. The problem does not begin when a model gives the wrong answer. It begins when that answer can automatically download code, use secrets, and act inside the business environment.”

— Eng. Marcin Białczyk, Founder and Cybersecurity Operator at CHORS.NET

At CHORS.NET, we treat AI agent security as part of a company’s real attack surface. This includes not only domains and servers, but also integrations, service accounts, tokens, access permissions, and the decision-making process behind installing new tools.

Frequently asked questions

Can ChatGPT, Gemini, or Claude Code recommend a malicious repository?

Yes. When a model or agent searches for publicly available tools, it may encounter an attacker-controlled repository and treat its README as a valid source of installation instructions. An AI recommendation should never replace verification of the publisher, code, and distribution method.

Is an MCP server safe because it is hosted on GitHub?

GitHub hosting alone does not establish trust. An MCP server should be treated as a software supply-chain component: verify the publisher, project history, dependencies, requested permissions, installation method, and its access to data and tools.

Do GitHub stars and forks prove that a project is trustworthy?

No. Popularity signals can be artificially inflated, and a fraudulent project can imitate the name and appearance of a legitimate repository. Verification should rely on official vendor channels, project history, and technical controls before deployment.

Is changing a password enough after running a suspicious tool?

Not always. Information-stealing malware can obtain API tokens, SSH keys, browser cookies, and active sessions. After an incident, assess the environment’s exposure and consider revoking all credentials and sessions available to the affected system.

How does CHORS.NET help reduce AI-agent risk?

Continuous Monitoring helps organizations continuously observe changes in their digital attack surface, detect new exposures, configuration issues, and security-relevant changes that require action. The engagement can also help structure safer practices for AI tools, service accounts, and integrations.

Keep AI-Agent Access Under Control

If your business uses AI agents, MCP servers, automation, VPS infrastructure, or SaaS integrations, treat code sources and agent permissions as part of the attack surface. Identify which exposures, integrations, and environment changes need continuous oversight.

See the Internet Exposure Scan service → or Vulnerability Audit →

Sources

1. Island: AgentBaiting — How 800 Fake AI Skills and MCP Servers Delivered Malware
2. The Hacker News: FakeGit Campaign Uses 7,600 GitHub Repositories to Spread SmartLoader Malware
3. BleepingComputer: FakeGit campaign uses 7,600 GitHub repos to push SmartLoader malware