Your AI agent just found an MCP server to help the business.
It also found the malware.
That is the supply-chain problem hiding inside “just let the agent install a skill.”
Island’s research uncovered more than 800 fake AI Skills and MCP servers posing as useful integrations for tools such as Gmail, Databricks, Jenkins, Docker, and WhatsApp. The repositories looked legitimate. The developer profiles looked legitimate. The READMEs looked legitimate.
In testing, Claude, Gemini, and ChatGPT could discover those malicious repositories on their own—and sometimes pass the attacker’s installation instructions to the user.
That is not traditional phishing. It is AgentBaiting.
The target is now the agent’s trust model
For years, phishing relied on tricking a person into trusting the wrong link, sender, or attachment. AgentBaiting changes the target. The attacker is no longer trying only to fool an employee. They are trying to fool the AI agent that helps the employee find, evaluate, and install a new capability.
That means attackers will optimize fake projects for discovery: credible names, familiar integrations, polished documentation, active-looking repositories, and installation instructions written to be easy for an agent to relay.
An agent does not need to be malicious to introduce risk. It only needs to be helpful without having enough evidence about what it is recommending.
An MCP server is not just a plugin
An MCP server can be a useful connection between an AI system and the systems where work actually happens. It can also be a path to production data, credentials, browser sessions, source code, customer records, and cloud infrastructure.
That makes the enterprise question less about which assistant to deploy and more about how an assistant is allowed to discover and introduce software into the environment.
Software supply-chain discipline already exists for a reason: a dependency with broad access can become a compromise with broad impact. Agent capabilities deserve the same treatment, especially when they can read sensitive data or take actions on behalf of a user.
Build a safe runway for autonomy
The answer is not to ban agents. It is to make their autonomy intentional and governed.
- Use a curated catalog. Make approved Skills and MCP servers easy to find so convenience does not become a reason to install unknown code.
- Verify the publisher. A polished repository and README are not evidence of a trusted maintainer.
- Test in isolation. Evaluate new capabilities in an environment with no production credentials or sensitive data.
- Reject unsafe installation patterns. “Download this ZIP and run it” is not a security review.
- Set explicit permission boundaries. Define what agents may discover, install, access, and execute—and where a human must approve.
- Log and review capability changes. Teams should be able to answer what was added, who approved it, what it can access, and how it is being used.
Governance is part of the software supply chain
AI governance is often discussed as a policy exercise. This is more concrete. Governance is now part of the software supply chain.
The companies that move fastest with agents will not be the ones that give them the most unrestricted autonomy. They will be the ones that build the safest runway for autonomy: trusted sources, controlled permissions, isolated testing, clear ownership, and a path to scale what proves safe and useful.
Helpful agents will keep finding new capabilities. The question is whether the organization has designed a system that lets them find the right ones.
