AgentBaiting and the Polygon Backdoor: What 14 Million Downloads Reveal About AI's Trust Deficit

The test was almost embarrassingly simple. The Island security team created repositories that contained nothing more than placeholder payloads, published them to platforms where AI agents routinely search for tools, and then asked three of the most widely deployed coding assistants — Claude Code, Gemini, and ChatGPT — to help with ordinary development tasks. All three assistants recommended the planted repositories. All three presented them as credible, useful, and worth executing. The findings, released in February 2026, frame what security researchers now call AgentBaiting: a production-scale campaign that has planted more than 7,600 malicious repositories across GitHub, registered more than 600 poisoned listings on public MCP distribution platforms, and accumulated over 14 million downloads for roughly 200 of its most aggressively promoted packages. Behind that infrastructure sits a command-and-control system that routes stolen credentials through Polygon smart contracts — a blockchain-based C2 channel that network defenders cannot see through conventional traffic analysis. This is not a simulated attack and this is not a hypothetical risk assessment. It is a live campaign that has been operating against developers, enterprises, and the AI agent ecosystem for months, and its success did not require breaking a single security boundary. It required something far more unsettling. It required being invited in by the very tools built to help. To understand why this matters, you have to understand what the AI agent ecosystem has become. Over the past two years, Model Context Protocol — MCP — has emerged as the connective tissue of agent-driven development. Instead of asking a developer to manually configure every tool, an agent discovers what it needs. It searches public registries like LobeHub, Glama, MCP.so, and MCP Market. It searches GitHub directories. It evaluates what it finds and recommends the most suitable tool for the task at hand. In many configurations, the agent does not stop at recommending. It downloads the code, installs it, and executes it within the development environment. The promise is breathtaking: software that configures itself, tools that find themselves, workflows that assemble themselves. The flaw is equally breathtaking: the agent cannot tell the difference between a tool that works and a tool that has been engineered to look like it works. That distinction, which used to be the job of a skeptical human developer, has been delegated to an algorithmic recommendation engine optimized for utility, discoverability, and speed. It is the perfect target for an adversary who understands how reputation signals are generated. This is where my own history with this industry becomes relevant. In 2017, while most of my colleagues chased ICO headlines, I spent months auditing whitepapers for security flaws. I documented three critical token distribution vulnerabilities in the EOS and Golem offerings that could have led to centralization risks, and I reported them in detail because I believed factual rigor mattered more than narrative speed. In 2020, during DeFi Summer, I produced a series of guides that translated Uniswap's automated market maker mechanics for non-technical finance professionals. My readers did not need to know every line of Solidity. They needed to know whether the systems they were entrusting with capital could be trusted at all. That service-oriented instinct — verify first, then translate — is exactly what the AI agent ecosystem is missing. The agent does not audit the repository it recommends. It does not check whether the publisher's account was created three days ago. It does not verify whether the download counts were inflated by bots or whether the stars were purchased. It reads the ambient signals of the open-source community and makes a judgment in milliseconds. And the user, trained by the same ecosystem to defer to their tools, clicks execute. Let me walk through the attack chain in detail, because the technical architecture is what separates this campaign from the noise of the broader security landscape. The attacker creates a GitHub repository designed to appear useful. It might present itself as an AI skill pack, an MCP server, a productivity plugin, or a developer utility. The repository contains a reference to a remote ZIP archive. That archive, once downloaded, contains a LuaJIT-based loader — SmartLoader, in the naming convention the research community has adopted. SmartLoader is responsible for two things: establishing communication with a Polygon smart contract, and delivering the final payload. The Polygon contract acts as a command-and-control dead drop. The attacker updates the contract's state with instructions. SmartLoader reads those instructions. Because the communication rides on public blockchain infrastructure, no firewall rule recognizes it, no DNS sinkhole catches it, no URL reputation service flags it. The network layer simply sees another interaction with the Polygon chain — a chain that processes millions of transactions daily. The final payload in this campaign is StealC, a commodity information stealer that has been circulating in the cybercrime economy. StealC harvests session cookies, OAuth tokens, SSH private keys, saved browser credentials, and other sensitive material. The harvested data gets exfiltrated back to the attacker, who can then use those session tokens to bypass password resets and, in many cases, multifactor authentication. The phrase that should concern every security professional reading this is simple: a session token is a key that does not require the user's password. If you have been compromised, changing your password does not invalidate the stolen token. You have to revoke every session, rotate every API credential, and rebuild trust with every service. Most organizations are not equipped to do that in the hours that matter, and that gap between compromise and response is where the attacker operates. The Polygon choice is worth dwelling on, because it is not accidental. Let me analyze the economics and the tradecraft together. First, cost. Polygon gas fees are negligible. Deploying contract infrastructure, updating C2 state, and managing even hundreds of contracts can be done for a few hundred dollars. Second, camouflage. Polygon has high transaction volume, so the C2 interactions are statistically invisible to anyone not specifically monitoring for them. Third, programmability. The attacker can encode instructions, update them, and revoke them — all through public contract state that the loader can query. Ethereum would give the same programmability at higher cost. Bitcoin would give privacy but no contract layer. Solana would give speed but a less familiar toolchain for the average malware developer. Polygon sits in the sweet spot: cheap, EVM-compatible, high-volume, and emotionally associated with legitimate DeFi activity. It is the perfect utility chain for an adversary who wants to hide in plain sight. But here is what I want to emphasize, because it comes from my experience analyzing on-chain activity. A blockchain C2 is simultaneously more invisible and more exposed than a traditional HTTP C2 server. It is more invisible because conventional network defense — URL filtering, traffic inspection, IP blocklists — cannot see it. It is more exposed because everything the attacker does is permanently recorded on a public ledger. Every command is a transaction. Every funding payment to the C2 contract is traceable. Every piece of state that the loader ever read is part of the chain history. Once a security team identifies the malicious contract address, the entire operational history becomes available for forensic analysis. This is the paradox of the campaign: the attacker chose a decentralized, censorship-resistant channel to avoid takedowns, and in doing so handed the security and law enforcement community an immutable record of the entire kill chain. Now let me address scale, because the numbers deserve scrutiny rather than panic. Seven thousand six hundred repositories is an enormous volume of infrastructure — it cannot be dismissed as a solo operator experimenting. More than 800 MCP server disguises tells us the attacker understands the AI tool ecosystem deeply. More than 600 registry listings across multiple platforms tells us the attacker invested in multi-platform propagation. And the 14 million download figure — that number deserves the kind of analytical honesty my editorial colleagues have come to expect from me. Truth over hype. Always. The 14 million downloads almost certainly include automated systems: CI pipelines fetching packages, registries mirroring content, bots pulling files at scale. It does not mean 14 million individual developers were infected. But even a conservative interpretation is sobering. If even 1 percent of those downloads reached a human engineer — 140,000 machines — the campaign has achieved a spread that most malware operations can only dream of. The number tells us less about victims and more about reach. And reach, in an AI agent ecosystem, is the metric that determines how fast an attack moves. The amplification mechanism is worth its own analysis. When a malicious listing appears on one MCP registry, that listing often propagates to other registries that mirror or aggregate content. LobeHub, Glama, MCP.so, and MCP Market do not all independently vet each entry. Some pull from shared sources. Some replicate listings for user convenience. The result is a feedback loop: a poisoned repository gains visibility on one platform, gets mirrored to another, and the AI agent that searches across multiple sources sees the malicious package repeated in multiple places — which, in a recommendation engine's scoring, looks like validation. The attack is not just exploiting GitHub; it is exploiting the entire syndication architecture of the modern AI tool ecosystem. Deleting the original repository does nothing to the mirrors. The content persists, re-emerges, and continues to be recommended. There is also a social engineering layer that I find deeply familiar, because I watched the same tactic work in the 2021 NFT boom. The attacker is not selling software. The attacker is selling identity. The malicious repositories borrow the names and visual identities of real developers, real projects, real tools. This is the Bored Ape lesson applied to code: people do not buy the asset, they buy the belonging. Developers install a tool because it looks like the kind of thing their trusted peers would use. The attacker understands that trust flows from presentation, not provenance. In the NFT market, the presentation was the profile picture. Here, the presentation is a GitHub profile with history, a believable README, and enough social proof to pass a recommendation engine's filtering heuristic. Let me also address the attribution question, because the security community has been debating it since the report landed. Trend Micro has previously tracked a campaign known as Water Kurita that distributed the Lumma Stealer through trojanized MCP servers. The AgentBaiting campaign uses SmartLoader and StealC, a different loader and a different stealer. But the pattern — LuaJIT loaders, MCP targeting, repository impersonation — suggests either the same operation evolving or a well-resourced imitator. I am less interested in the name than in the capability. Operating thousands of repositories across multiple platforms with synchronized malicious content requires an organized workflow: content generation, account management, C2 infrastructure, and exfiltration handling. This is not a weekend project. This is a business operation, and the business model is self-sustaining. The stolen credentials and session tokens are likely sold or repurposed, generating revenue that funds the next wave of infrastructure. The campaign is not just an attack vector; it is an economic engine. So what does this mean for the security posture of organizations building on AI agents? The mitigations are clear, and the security researchers have been admirably precise about them. Establish an approved integration directory within your organization. Sandbox all downloaded agent packages before executing them in production. Monitor installation paths and block unapproved repositories. Rotate session tokens, OAuth credentials, and SSH keys aggressively — because StealC harvests the kind of credentials that password reset alone cannot protect. Deploy behavioral monitoring rather than signature-based detection, because LuaJIT loaders are designed to evade static analysis. And, critically for the blockchain side of this conversation, begin monitoring the chains where your tools interact. If you discover that a C2 contract has been used, you can trace its funding wallet, its interaction patterns, and its full command history on a public explorer. That is an advantage no traditional C2 server offers, and security teams should use it. I keep coming back to a principle that has guided my work since the ICO era: trust is the only currency that matters. In crypto, we say this about markets. We say it about bridges, about exchanges, about layer-2 networks. But it applies just as powerfully to the AI agent stack. The agent trusts the repository. The repository trusts the publisher. The publisher trusts the recommendation engine. And the user trusts all of them. Every layer of that chain is an assumption, and this campaign demonstrates what happens when an attacker decides to assume the personas that the chain treats as credible. Now let me turn to the contrarian view, because the easy takeaway — that this proves AI agents are dangerous — is itself a trap. The first counter-argument: this is not a blockchain attack. It is a supply chain attack that happens to use a blockchain. Swap the Polygon contract for a Telegram bot, a Discord webhook, or a Pastebin dead drop, and most of the kill chain still works. I acknowledge this. The chain adds stealth, persistence, and censorship resistance, but the fundamental vulnerability — an agent that trusts social proof as a proxy for security — exists independently of the C2 mechanism. Anyone who misreads this as a Polygon-specific problem will deploy the wrong defenses. The second counter-argument: the AI companies will close the gap. Claude Code, Gemini, and ChatGPT have enormous engineering teams, strong incentives, and growing regulatory pressure. Platform-level filtering, approved-package lists, and model-level safety training will reduce the risk over time. I believe this. I also believe the interim period — before those fixes are deployed and mature — is precisely when the attacker is most active. This is the window where an organization can be compromised not despite its AI tooling, but because of it. The third counter-argument is the one that keeps me up at night. Even if every major AI platform hardens its recommendation layer tomorrow, the attacker will simply evolve. They will create new identities, generate new repositories, spoof new signals, and adapt to whatever the recommendation engines learn to distrust. The security community is solving a static optimization problem — filter these known bad actors. The adversary is solving a dynamic one — maximize the probability of being recommended while meeting the new filters. Every mitigations layer adds friction. None of them resolve the underlying issue: agent decision-making is optimized for utility, not security. And the incentive gradient of the open-source ecosystem — social proof, downloads, engagement — is inherently gameable by someone with enough infrastructure. There is an uncomfortable symmetry here with the broader blockchain security landscape. I have spent years watching cross-chain bridges get exploited. We have seen over two and a half billion dollars flow out of bridge contracts in cumulative losses, and yet the industry still depends on bridges. We are watching a similar dynamic in the AI agent ecosystem. There is no economically viable way to run an agent without letting it discover and execute third-party tools, just as there is no economically viable way to move assets across chains without bridging. And in both cases, the trust deficit is being papered over by narrative momentum. That is why I keep coming back to my own risk-first framework. The prudent analyst does not ask whether the attack is likely. The prudent analyst asks what the attack makes possible, who is exposed, and how long the exposure lasts. What the AgentBaiting campaign makes possible is credential theft at machine speed. It is one thing for a phishing email to fool a human; it is another thing for a recommendation engine to present the poisoned package as the best available option. The AI agent does not have a suspicion reflex. It does not recognize that a repository about "productivity boosters" is actually a delivery system for a Polygon-controlled C2 network. It evaluates and recommends. And that is precisely what makes this campaign a turning point rather than just another malware event. The next generation of malware will not need to lure users into clicking suspicious links. It will need to be sufficiently popular, sufficiently professional, and sufficiently discoverable that the user's own tools will do the persuading. The question I want to leave readers with is not whether AI agents will be compromised again — they will. The relevant question is how fast the response cycle becomes. Can the industry build provenance verification that runs at the same speed as agent discovery? Can we build an equivalent of a software bill of materials for agent tooling — a machine-readable record of where each package came from, who signed it, and what its behavior is permitted to be? Can the blockchain side of this conversation evolve from being the adversary's C2 channel of choice to becoming the backbone of public software provenance — a ledger where every signed artifact's lineage is broadly visible? The infrastructure is already there. The question is whether the industry has the will to use it that way. During the 2022 crash, when everyone around me was panicking, I kept publishing measured, grounded analysis. It was not clickbait, and it did not perform well in the short term. But my readers, the ones who stayed, learned to trust that the signal would survive the noise. Noise filtered. Signal preserved. That is the discipline we need now. The signal from the Island research is clear: AI agents have inherited the internet's trust model, and that model is not ready for the responsibility. The tools we build are our mirror. If we let them trust recklessly, they will be exploited recklessly. If we teach them to verify the way a careful analyst verifies — slowly, skeptically, with audit trails — they can become the most trustworthy systems we have ever built. The choice is ours. The adversary is watching.