Over 400 malicious "Skills" have been found lurking in AI agent plugin marketplaces, and nearly 10% of available plugins in one major hub contained two-stage malware - code that looks legitimate on first inspection, then quietly downloads the real payload.
That finding, from security firm SlowMist, lands at a moment when companies are rushing to give AI agents access to production systems, financial accounts, and customer data. The gap between how much access these agents have and how well that access is secured is growing fast.
What the Attacks Actually Look Like
The malware SlowMist discovered doesn't announce itself. Malicious plugins pass initial review because their harmful code only activates in a second stage, after installation. Once running, these plugins scrape local machine info, browser cookies, SSH keys, and API credentials - exactly the kind of data an AI agent needs broad access to in order to function.
This isn't theoretical. A Solana-based AI agent lost $441,000 worth of tokens after a social engineering attack. A Polymarket breach in December 2025 resulted in over $500,000 in losses. In one experiment by Nov1.ai, an AI agent given trading authority lost over 60% of its capital in two weeks.
A separate vulnerability dubbed "ClawJacked," rated CVSS 8.0+ (that's "high severity" on the standard vulnerability scoring scale), allows attackers to hijack locally running AI agents simply by tricking a user into visiting a webpage. No downloaded file, no phishing email - just a browser visit.
The Core Problem Is Permissions
Most AI agents today operate under what security professionals call an "overprivileged" model. To be useful, an agent needs access to your calendar, email, files, maybe your CRM or code repository. But the tools connecting agents to these systems rarely implement fine-grained permissions. It's all-or-nothing.
SlowMist's CISO, who goes by the handle 23pds, pointed to several practical defenses: dedicated sub-accounts for AI agents instead of sharing your main credentials, IP whitelisting so agents can only operate from known networks, and .agentignore files (similar to .gitignore) that explicitly block agents from accessing sensitive directories.
The recommendation that matters most is also the simplest: least-privilege access. Give agents only the specific permissions they need for each task, not blanket access to everything. And keep a human in the loop for anything involving money or sensitive data.
Where This Hits AI Tool Users
For anyone using tools like Claude Code, Cursor, or any AI coding assistant that runs plugins or extensions, the takeaway is concrete. That marketplace of community-built plugins is a trust problem. A 10% malware rate in one plugin hub means the "install and try it" approach that works fine for VS Code extensions is actively dangerous when the extension has agent-level access to your system.
The same logic applies to no-code automation platforms connecting AI agents to business tools. Every Zapier zap, Make scenario, or n8n workflow that gives an AI agent write access to your systems is a link in a chain that's only as strong as its weakest plugin.
Passkeys (the FIDO2/WebAuthn standard that replaces passwords with device-based authentication) were specifically recommended as a primary login method for any account an AI agent can access. They're phishing-resistant by design, which matters when the attack vector is a malicious plugin rather than a suspicious email.
None of this means you should stop using AI agents. But the security posture most people and companies are running - default permissions, shared credentials, no access auditing - was built for a world where software did exactly what you told it. Agents that interpret instructions, choose their own actions, and access multiple systems in sequence need a different security model. That model mostly doesn't exist yet.