Do Not Mention This to the User: How an AI Agent Can Turn Into the Attacker’s Delivery Boy
In July 2026, Island published a study of a campaign called FakeGit: the researchers report that they found roughly 7,600 fake GitHub repositories from 6,600 fake profiles, with more than 14 million downloads. Over 800 of them posed as AI Skills and MCP servers. Inside were the SmartLoader downloader and the StealC infostealer.
Fake repositories are not a sensation, so what was the study supposed to show?
A new mark: it was not a person or a simple Google search, but in the test described in the report, Gemini and ChatGPT independently recommended the same fake walmart-mcp. The agents found the attacker’s repo and handed the user instructions for installing malware. The package borrowed Walmart’s name, and on the researcher’s account, Walmart had no involvement in it, and its own systems and services were not affected.
This is why we call it a new mark: before, malicious actors needed to trick a person. Today, they trick the assistant instead: you ask what tool to use, the agent answers in good faith, and you skip the check because your buddy the agent would never.
Now imagine someone put a ‘do not mention this to the user’ line inside that new skill or MCP, and the agent follows it obediently. Sounds like a creepy story, but it’s real, subject to the report below, and looks disturbing.
None of this means throwing your agent out, though. We went through the incidents seen in the wild and the proof-of-concept research behind them, and asked Sergey Martianov, CPO, ADEX, where the real dangers are and what reduces the risk.
Contents
- How Does an Agent End Up Recommending Malware?
- AgentBaiting: The Agent Recommends You Malware
- Tool Poisoning: The Agent Follows an Order Hidden in What It Reads
- The Agent Hides What It Did
- RugPull: When The Agent Becomes the Leak
- The Swap Can Happen Outside the Package
- Opening Someone's Project Can Run Their Code
- ClickFix: When A User Installs Malware Deliberately
- The Agent as the Weapon
- The Economics of Fake Reputation
- Why Simply Reading a Code Doesn’t Help?
- Summary: How to Protect Your Agent Before You Install Any Skills and Files
- Where This Leaves You
How Does an Agent End Up Recommending Malware?
Almost all the case studies we’ll describe below are possible for two reasons, and both of them are simply how agents are built:
Reason 1. Everything arrives as text
A regular program keeps the commands it runs separate from the files it opens. A document you open in Word will never become an order to Word, no matter what you type inside it.
AI models basically know the difference, can tell which words are yours and which came from a file it opened, and are trained to listen to you first. However, nothing stops a sentence in a README from working like an order, so if it is written well enough, the agent can follow it as well.
This trick is called prompt injection. When the instruction is hidden inside a file the agent reads for you, it is indirect prompt injection. It does not fire every time, but ‘bad’ instructions have all chances to look exactly like good ones once.
- Reason 2. The agent can actually do it
Any injected instruction is harmless on its own: it needs a combination. Simon Willison named the lethal trifecta: three conditions meeting inside one agent:
- It sees something valuable (your files, your keys, your mail)
- It reads something from outside that you do not control
- It can send something out
All three at once, and you can be robbed, but take away any one of them, and the instruction just sits in the file doing nothing.
That explains three of the cases below: Tool Poisoning, the skill that tells the agent not to mention what it did, and GTG-1002, where the model was talked into treating an attack as an authorized test.
The other five don’t need the model to be fooled at all – they need a human, or an agent doing a plain web search, to trust a fake signal: a repository built to look trusted, a package that was honest for fifteen versions, a link that only turns malicious once the install count climbs, a settings file nobody re-approves after the first look. Stars, forks, and download counts get faked in the same way any other popularity metric can be faked – the difference is that here, the reward for faking them is code execution, not a sale.
Now, eight ways your agent can hand you malware without ever meaning to.
Note: No vendor can fix both once and for all, and it’s not about incompetence. We have been here before with SQL injection, where an attacker typed a piece of a database command into a name field, and the database ran it. That one got fixed: instead of pasting whatever the user typed into the command, the program now sends the command and the data separately, so the data can never become part of the command. Nobody lost anything, because running data as code was never a feature.
Meanwhile, with an agent, it is exactly the feature: following instructions written in ordinary words is the whole job, so there is no way to switch that off for bad instructions, because they look exactly like good ones: same words, same language, same stream of text.
Where the Wall Is Missing
A normal program keeps commands and data apart by force. An agent has one input, and everything arrives as text.
| What Differs | Ordinary Program | AI Agent |
|---|---|---|
|
Input channels
|
Two Code it runs, and data it processes. | One Text. Your task and the file it was asked to read arrive the same way. |
|
Can data turn into a command
|
No A document you type into never becomes an order to Word. Executable content is a separate, deliberately gated thing. | Yes A line in a README can be followed like an instruction. |
|
How your instruction is told from someone else’s
|
By the channel it came in on. The separation is enforced. | The model can see where text came from and is trained to put you first. That is a habit, and a convincing enough line still wins. |
|
Does an attack fire every time
|
Yes Same input, same result, every run. | No Ignored once, obeyed the next time—so a clean test run is not evidence the next one will be. |
|
Is there a complete fix
|
Yes Parameterized queries send the command and the data separately, so the two can never merge. | No Plain language has no syntax you could split them by. An order and a piece of text are made of the same words. |
|
Can the behaviour be cut out
|
Yes, and nothing is lost Running data as code was never a feature. Nobody wanted it in the first place. | No, and this is the whole problem Following instructions written in plain words is what the agent was hired for. Switch it off for bad instructions and you switch it off for work. |
AgentBaiting: The Agent Recommends You Malware
How it works. A user asks the agent to find a tool for a task. The agent searches, finds a fake, reads the attacker’s README as genuine documentation, and hands the user installation instructions. No injection is required: the attacker just needs to create a fake repository that looks good enough to show it in search results. Island called this AgentBaiting: the goal is to mislead the agent rather than the user, which is simpler, as no AI bot adds human skepticism to the decision.
Case Study: FakeGit (July 2026). Island has documented roughly 7,600 fake repositories from 6,600 fake profiles on GitHub. More than 800 of them were posed as AI Skills and MCP servers, and around 1,400 more traded on AI themes. The wave built through March and peaked in April 2026, totaling more than 14 million downloads.
Each fake repository seemed like an ordinary open-source project, with plausible documentation, real code, and – on top of all that – an author profile that had a history of activity and overall looked trusted. However, in fact, it hid a two-stage payload:
1. SmartLoader. A small and unremarkable loader that lands on the machine and pulls down the real malware.
2. StealC. An infostealer, fetched by SmartLoader, that collects browser passwords, cookies, active sessions, screenshots, and digital asset wallets. Once ready, it then ships everything back to the attacker.
The user sees none of this: the tool installs and often even works exactly as advertised.
One example: walmart-mcp. There is no official Walmart connector, but there are several third-party ones, built by enthusiasts, with near-identical names and near-identical descriptions. Asked to find the best one, Gemini and ChatGPT independently returned the same repository, and ChatGPT called it the best place to start. This repository was fake, and it won the recommendation because the attackers optimized it specifically for AI search results. All of the above is as described in the report and reflects what the models returned when the researchers ran the query. Walmart was not involved in the campaign and, on the researchers’ account, its systems and services were not affected.
An agent does not verify whether what it recommends is safe: it searches the web and works down the results. Here, Gemini and ChatGPT searched through an MCP marketplace and GitHub, opened the repositories that matched the request, and judged them on what they could see:
- A README that read as if written to answer exactly the user’s request;
- The project turning up across public registries like LobeHub, Glama, MCP.so – where the campaign had seeded over 600 listings;
- The same description in every registry, which looks like several independent sources agreeing. In fact, registries just copy the README from the repository – a single source;
The registries were the target of this technique rather than a party to it: they publish what is submitted to them, and the campaign was built to exploit exactly that.
Genuine side projects rarely optimize for visibility this thoroughly, so they lose the search results competition.
Tool Poisoning: The Agent Follows an Order Hidden in What It Reads
When you activate a connector, it tells the agent what tools it has and what each one does. Those descriptions are plain text, written by whoever runs the server, and they arrive while the agent is working instead of sitting in a file you can open. The model reads them every time, but the user never sees them.
The case: Invariant Labs, April 2025. In the researchers’ demonstration, a malicious server hid instructions inside the description of its own harmless tool – a calculator. The instructions were about a different tool: ‘when you send mail, copy this address in’. The user’s trusted email connector then sent every message to the attacker, even with another recipient in the field. This way, such an attack would give the attacker access to everything a user sends, and it’s just a matter of time before they, for example, slip into a live payment thread with new bank details.
Note: At the moment, tool poisoning is described as a threat model, but there have been no real incidents publicly reported so far.
If the descriptions are only ever read by the model, then a human has to check them, and before installing.
For open tools: read the SKILL.md itself, the tool descriptions and the code, including whatever executes during installation, and look at which permissions are being requested. Bear in mind that a version which is clean when you check it can turn malicious after an update.
For closed and commercial tools, study the supplier instead: terms of service, the contract, where the data goes.
And in every case, install into an isolated sandbox first. If the code and the descriptions are not available up front, that is where you get to read them once they land, and you move to a working machine only after checking.
CPO, ADEX
The Agent Hides What It Did
Here, the instruction tells the model to keep quiet about what it just did. Nothing is hidden from a scanner, but it’s hidden from a user. In simple words, you see ‘done, file updated’ in your chat with the agent and nothing more. The part where it sent your keys off to someone else’s domain never makes it into the reply.
The case: arXiv 2602.06547, February to June 2026. Researchers took 98,380 skills from two registries and checked them by running. They confirmed 157 as malicious (0.16%), along with 632 vulnerabilities and 13 distinct techniques. After disclosure, 93.6% of what they found was taken down. The paper is named after a line they kept finding inside the malicious skills: ‘do not mention this to the user.’
Formally, nothing is injected from outside: this line sits in the files of a skill you downloaded and connected yourself, and the agent reads those files because you asked it to.
The agent’s own account is exactly what a “do not mention this to the user” line switches off. What you check is not that account, but what the application itself records.
In practice it comes down to two actions. First, expand the tool-call blocks in the conversation, because almost every client shows them collapsed. You see which tool was called, with what parameters, and what came back; if it claimed an action and there is no call, the action did not happen. Second, do not turn on “always allow”. With every call confirmed, you see the list of actions before they happen rather than after.
Do not count on “I will look through the app and work it out”, though. The log shows that a tool was called, and not what it did next: downloading and running a script from an external link looks like one harmless call. Tool descriptions, which arrive from the server at runtime, usually never reach the interface at all. And with dozens of calls in a session, nobody is going to read every one, which is what the attack counts on.
So this protects you from an agent that stays quiet about its actions, but not from a tool that hides its own. That second one is only solved at the entrance: a whitelist, a sandbox, minimal rights.
CPO, ADEX
RugPull: When The Agent Becomes the Leak
Nobody has to break in: the agent is already inside, working under your name and with your access, so the attacker only needs whatever passes through it to go one extra place. This is the third corner of the lethal trifecta: the way out.
The case: postmark-mcp, Koi Security, September 2025. Postmark is an email-sending service. An unaffiliated publisher released a connector that looked official: versions up to 1.0.15 were honest, building trust along the way. This wasn’t a Postmark product – it was impersonation. Importantly, Postmark later confirmed publicly that the package wasn’t theirs, that they had no involvement in it, and that their actual API and service were never affected.
Version 1.0.16 added a single line: a hidden BCC (blind carbon copy) that copied every outgoing message to the author’s own domain, invisible to everyone in the thread. From that version on, every automated email those companies sent to their users also went to the attacker. Those emails included password resets and confirmation codes, so, on Koi Security’s account, the attacker ended up holding live login links for the customers of around 300 companies. Nobody noticed, because a BCC is invisible by design: neither the sender nor the recipient sees it.
You cannot shut the channel completely: a tool that goes out to the network needs the network to do its job. What you take away is not the channel, but whatever can be carried out through it.
In practice, access no wider than the task. The project’s working folder, not your whole home directory. A separate browser profile, not the main one holding every session. Test keys instead of production ones, read-only and scoped to one project instead of a universal token. And do not mix private data and untrusted content in one session: going through someone else’s repository and working with your mail are two different sessions.
Plus confirmation on everything that leaves: an email, a commit, a write to an external service. This is exactly where “always allow” costs the most.
Where you can, run the agent in a container or on a separate machine with no SSH keys and no cloud credentials on it, and allow outgoing connections only to the domains it needs.
CPO, ADEX
Note: Those honest versions were the whole point. Your approval covers the version you looked at; nothing asks you again when an update arrives, and auto-update turns one confirmation into a standing confirmation for everything the author ships next. That trick has a name: rug pull.
The Swap Can Happen Outside the Package
Pinning versions and reading diffs both assume that what changes is the package, but sometimes it happens outside.
Case 1: MCPoison in Cursor, CVE-2025-54136 (Check Point, August 2025)
Cursor is a code editor with an AI assistant built in, and it takes its settings from a file inside the project so the whole team works the same way.
Once you approve that file, the editor did not re-check it in the affected versions. An attacker with commit rights to a shared repo could plant a harmless config, wait for the approval, then change the command inside, and get code running every time anyone opened the project, with nothing asked. Fixed in Cursor 1.3, where any edit at all, down to an added space, has to be approved again. Researchers found this and reported it, so no exploitation in the wild was reported.
Case 2: the skill that reached 26,000 agents (AIR, June 2026). Researchers sent a pull request for a skill called brand-landingpage to a popular marketplace with around 36,000 stars. It was merged, and from that moment the skill wore the repository’s reputation. Instagram ads aimed at marketers and designers did the rest, putting it on roughly 26,000 real users’ agents.
The swap happened outside the package. The domain the skill pointed at served genuine documentation at first, and once the installs had piled up, that page turned into instructions telling the agent to download and run a script. The scanners the researchers tested missed it, for a simple reason: they read the package that was submitted, and the other end of a link can change at any time.
Start from the assumption that approval attaches to a version, not to a tool. Versions of postmark-mcp up to 1.0.15 were honest, and the next one added a hidden BCC. Which makes auto-update a consent you handed over in advance, for everything that arrives later.
In practice: turn auto-update off for anything with broad permissions, and update deliberately, looking at what changed. Do not install the newest release on the day it ships without a reason. Treat it as a warning sign if a tool asks for more rights after an update, or starts reaching places it never reached before.
Updates to the client itself deserve separate attention. MCPoison in Cursor was fixed precisely by making any config change require fresh approval, which means older clients have no such protection.
Honestly, though, this does not close all the way. In the AIR case what was swapped was the content of a page behind an external link, and not the package: the skill’s version never changed at all, so there was nothing to update. Update control is only one part. The rest comes from the tool having few rights to begin with, and little of value around it.
CPO, ADEX
Opening Someone’s Project Can Run Their Code
Developers copy other people’s projects onto their machines dozens of times just to read them. It used to be harmless, because text sitting on your disk does nothing on its own.
Editors with an AI assistant changed that: they take settings from a file inside the project, so everyone on a team works the same way, and the person who published the project is the one who wrote that file. It can tell the assistant to run a command as soon as the project opens.
Check Point, February 2026. Claude Code reads its settings from a file in the repository, and anyone with access to the repository can edit it. There was a guard, though: when you open an unfamiliar folder, a window asks whether you trust this project. Check Point showed that the command in the settings ran before anyone finished reading the question. The three findings below were reported by Check Point and, per the vendor advisories, have all been fixed in the versions and on the dates noted.
Three findings, all fixed since:
- Opening a folder in a new location skipped the permission step altogether (fixed September 2025);
- Opening an untrusted folder could run any command on your machine, from deleting files to downloading a program to sending your data somewhere (CVE-2025-59536, fixed October 2025);
- The settings could point the assistant at the attacker’s server instead of the real one, and it handed over the API key on arrival, the key you are billed for (CVE-2026-21852, fixed January 2026).
Copying a project onto your machine and opening it used to be a neutral act. Now the editor reads its configuration out of the repository itself, and whoever has commit rights controls that configuration.
The first line of defense is already built in. Modern IDEs ask whether you trust an unfamiliar project, and in restricted mode they will not run its settings or its tasks. So do not click “I trust this” on reflex, and stay in restricted mode while you are only reading someone else’s code.
Do not lean on that alone, though. Some of the holes that were found bypassed that dialog exactly, firing before the user could read it, which is why the editor has to be kept updated.
Where you can, open unfamiliar projects in a container or on a separate machine that holds no keys and no tokens. And remember that a repository’s popularity guarantees nothing: a harmful config can arrive there through an accepted pull request.
CPO, ADEX
ClickFix: When A User Installs Malware Deliberately
The dullest but the most effective technique we’ll mention here: there is no injection, just an instruction written for a user. A README or a SKILL.md carries a ‘Prerequisites’ section, the part of any documentation that tells you what to set up first, and it asks you to paste a command into your terminal or grab a helper tool.
You copy and paste, then press Enter, and so install the malware with your own hands. This technique is called ClickFix.
The case: ClawHavoc (Koi Security and Antiy CERT, January to February 2026). ClawHub is a public skill registry for the OpenClaw agent, and anyone with a GitHub account older than one week could publish there. From January 27, attackers began bulk-uploading skills dressed as Blockchain and office utilities, peaking on the 31st, and Koi named the campaign on February 1.
The two organizations measured different things, so their numbers shouldn’t be added together or read as two estimates of the same total. Koi’s snapshot audit found 341 malicious skills among the 2,857 then live on ClawHub, 335 of them from a single campaign. Antiy CERT’s cumulative count, tracked over time, puts it at 1,184 malicious skills tied to just 12 accounts – one account alone uploaded 677.
What they took: Blockchain wallets, browser passwords, API keys, the macOS Keychain (every saved password at once), SSH keys, and Telegram sessions.
Technical controls are almost powerless here, and it is down to how the attack is built. There is no malicious code in the repository, so a scanner has nothing to find. What sits there is text addressed to a human.
The command is run by the user, voluntarily and by hand, which makes it a normal action as far as the system is concerned.
Something does work after the fact: antivirus or EDR may react to whatever was downloaded and launched. But that is catching the consequences rather than the trick itself, and it gets bypassed by routine means.
CPO, ADEX
The Agent as the Weapon
The other direction: the agent is the one doing the attacking. Penetration testing tools are standard security software for probing defenses, finding holes, guessing passwords, checking where somebody could get through.
Connect them to an assistant as MCP servers, the same way you would connect anything else, and the assistant starts running them itself.
The case: GTG-1002, reported by Anthropic, November 2025. Anthropic published an account of a campaign it calls the first documented case of AI-orchestrated cyber espionage. The attribution – an East Asian state-sponsored group – is Anthropic’s own assessment; it hasn’t been independently confirmed in public threat-intelligence repositories, so this is a vendor’s account of the incident, not a verified industry finding. In plain terms: normally a human operator decides the order of an attack, running a scanner, reading the result, picking the next step.
Here, the model took that role. The attackers wired open-source pentest tools into Claude Code as MCP servers, set the objective, and the model worked out what to run next and what to do with each result. Anthropic puts 80 to 90 percent of tactical operations at no human involvement, leaving the operator to set goals and choose the major forks.
The attack itself does not change. The same scanning, the same brute forcing, the same exploits, the same traces it leaves behind, so there is nothing in your defenses that needs rewriting.
What changes is speed and volume. A person is no longer the limit on the pace: many targets at once, round the clock, working through options faster than anyone can read an alert. The defenses that suffer are the ones that quietly relied on an attack costing time.
The conclusion is a boring one. Ordinary fundamentals start to count for more: automated response instead of manual triage, rate limiting, MFA, and unused entry points closed.
CPO, ADEX
The Economics of Fake Reputation
Half of what you have read rests on one assumption: that trust signals in open source – stars, forks, contributors, download counts, a listing in a registry – mean something.
However, an April 2026 Awesome Agents investigation found that GitHub stars are openly advertised in bulk, at prices low enough that the appearance of traction on a repository costs less than a day of an engineer’s time.
Researchers from CMU, Socket and NC State (ICSE 2026) counted some 6 million suspicious stars across 15,835 repositories, and at the July 2024 peak, 16% of all repositories with star activity were caught up in fake campaigns.
Two cases show how that converts into installs.
The Oura MCP clone (Straiker STAR Labs, February 2026). The operators behind SmartLoader cloned the real Oura connector, spent three months building it a reputation with at least five fake GitHub accounts producing fake forks and commit history, then submitted the trojanized version to genuine MCP registries. Anyone searching for Oura MCP saw it in the list beside the original, with nothing to tell them apart. This was an impersonation, the clone was not an Oura product, and on the researcher’s account Oura itself was neither involved nor breached.
$500,000 through a malicious extension installed in Cursor (Kaspersky, July 2025). A Solidity Language extension on Open VSX showed 54,000 downloads, all inflated by bots. The point of the inflation was ranking: you type ‘solidity’, the fake comes up first, you install it. A day after the takedown the authors reposted it under a near-identical name and drove the counter to about 2 million. One blockchain developer, Kaspersky reports, lost around $500,000. Both Open VSX and Cursor were the distribution route here, the malicious code was published by a third party.
The conclusion: download and star counts are discovery metrics: they tell you a tool is easy to find, but don’t mean it’s safe.
Why Simply Reading a Code Doesn’t Help?
For anything open source that is the right first move: read the SKILL.md, read the tool descriptions, read the code including whatever runs during installation, and look at the permissions being requested. It catches the obvious, and against one vector it is a reliable defense, since ClickFix only works if you go along with it.
It will not catch the rest though for 4 reasons:
- The entry file is a cover page. SKILL.md points at scripts, packages and outside addresses, and the Oura clone kept its payload in an obfuscated script two steps further down. Malicious code also does not look malicious: a line adding a BCC, sitting inside a package built for sending email, reads as code that sends email, and roughly 300 organizations read past it.
- Some of the text is never shown to you at all, because MCP tool descriptions arrive from the server while the agent is working. There is a way around that one: install into a sandbox first, read the descriptions and the code once they land there, and move to your real machine only after.
- One reading covers one version. postmark-mcp 1.0.15 was clean and 1.0.16 was not. With the AIR skill the files never changed at all, because what changed was the page at the far end of a link.
- Scanners hit the same ceiling. In June 2026, Trail of Bits pushed four malicious skills past ClawHub, Cisco’s scanner, and skills.sh as those checks stood at the time of the test, using tricks as crude as 100,000 blank lines before the payload. Three of the four took under an hour to build, because a scanner works to fixed rules and an attacker gets unlimited tries.
Summary: How to Protect Your Agent Before You Install Any Skills and Files
These steps reduce risk, but none of them removes it. This is a general checklist for a marketing or ad ops audience, not a security standard, and it does not replace your own organisation’s security review or its policy on what may be connected to work accounts.
What Actually Moves the Risk
Seventeen measures, grouped by where each one bites. None of them removes the problem, and together they take away most of what an injected instruction needs.
-
Reading the code comes first, and it is not enough.
The entry file is a cover page, malicious code looks like ordinary code, tool descriptions never reach your screen, and one reading only covers one version. Scanners hit the same ceiling: Trail of Bits pushed four malicious skills past three of them in June 2026, three of the four built in under an hour.
Swipe or use the arrows to go through the measures
-
Do not trust the metrics
Stars, forks and download counters are for sale. Look at what is expensive to fake: account history, real issues with real answers, a release record, years of activity.
Keeps untrusted tools out
-
Read it, and read all of it
SKILL.md, the tool descriptions, the code, whatever executes during installation, and the permissions it asks for.
Keeps untrusted tools out
-
For closed tools, vet the vendor
Terms, contract, where the data goes. You cannot read the code, so read the company instead.
Keeps untrusted tools out
-
Put it in a sandbox first
An isolated machine with none of your real files, keys or access. It is also where you finally get to read what was invisible before installing.
Keeps untrusted tools out
-
Keep a whitelist, starting with an inventory
A vetted catalog beats free installation, and you cannot protect what you cannot see. Finding out what is already installed is usually the unpleasant part.
Keeps untrusted tools out
-
Pin versions, and update deliberately
Approval covers the version you saw. Auto-update off for anything with broad permissions, and treat it as a warning sign when a tool asks for more access after an update or starts reaching places it never reached before.
Closes the rug pull window
-
Keep the client itself updated
MCPoison was fixed by making any config change require fresh approval. Older clients simply do not have that protection.
Closes the rug pull window
-
Scan configurations
mcp-scan pins tool descriptions by hashing them, so a rewritten one shows up immediately. The feature is called Tool Pinning. Cisco AI Defense has skill-scanner, and there are Semgrep rules. A filter rather than a guarantee.
Closes the rug pull window
-
Least privilege
Read-only access to databases, repo-scoped tokens instead of broad ones, a limited slice of the filesystem, and a container with no SSH keys or cloud credentials sitting next to it.
Breaks the lethal trifecta
-
A separate browser profile and test keys
The project folder, not your whole home directory. A fresh profile, not the one holding every logged-in session. Test credentials, not production ones.
Breaks the lethal trifecta
-
Let it out only where it needs to go
Allow outgoing connections to the domains the job requires, and to nothing else.
Breaks the lethal trifecta
-
Never turn on “always allow”
Confirm anything that leaves: an email, a commit, a write to an external service. And keep sessions apart, so reviewing someone’s repository and working with your own mail never share one.
Breaks the lethal trifecta
-
Expand the tool-call blocks
Almost every client shows them collapsed. Opened up, they name the tool, the arguments and the result, so a claimed action with no matching call never happened. The limit: a log shows a tool ran, not what it did next.
Covers what the agent will not tell you
-
Do not click “trust this folder” on reflex
Editors ask before running anything from an unfamiliar project, and restricted mode exists for exactly this. Stay in it while you are only reading someone else’s code.
Covers what the agent will not tell you
-
Never copy a command out of a README
The ClickFix vector, and going by ClawHavoc, the most productive one in this article. Also the only one you beat by simply not playing along.
Covers what the agent will not tell you
-
Run the boring baseline
A model-driven attack is the same attack at higher speed and volume, so ordinary hygiene counts for more: MFA, rate limiting, automated response instead of manual triage, unused entry points closed.
Covers what the agent will not tell you
-
Lean on the frameworks
OWASP Top 10 for LLM Applications, OWASP Top 10 for Agentic Applications (December 2025), OWASP Agentic Skills Top 10 / AST10 (draft, in public review).
Covers what the agent will not tell you
Where This Leaves You
All of this has happened before. npm is the catalog developers install ready-made code from, the reason most apps today are assembled rather than written from scratch, and ten years ago it worked the way skill registries work now. What fixed it came from the platforms rather than from users reading more carefully: mandatory two-factor for maintainers, trusted publishing, signed provenance.
Malicious package detections across the open-source ecosystem rose 73% in 2025 overall – while on PyPI and NuGet, the two registries that rolled out mandatory 2FA, detections fell 43% and 60% over the same period, according to the same report.
Two things are different now. Skill registries are covering in months what npm covered in years, so we are sitting in the gap between a visible problem and the controls that answer it. And an npm library runs inside one program, while a skill runs with the permissions of whoever installed it: mail, repositories, databases, keys.
Ad tech is catching the same trust problem that just hit GitHub and npm. Media buyers and ad ops teams are now plugging AI agents, reporting copilots, and campaign tools into their reporting and campaign workflows using the same kind of third-party skills and MCP connectors described above. If someone on a marketing team installs a poisoned campaign reporting or creative generation skill, that's a supply-chain risk to ad spend and advertiser data, the same way postmark-mcp put password resets at risk. The only difference is whose credentials leak – an ad account instead of an email inbox. When a number decides what gets installed, the number has to be verified by the platform rather than trusted by the user. That is the standard we hold our own supply to, and it is the question worth asking of any tool that is about to be given access to an ad account.
This article summarises security research published by third parties and is provided for general information only. It is not security advice, not a legal opinion, and not an assessment of any product, vendor, package or registry named in it. All findings, figures and vulnerability statuses are as reported by the cited sources on their publication dates and may have changed. Third-party names and trademarks are used for identification only. Consult your own security team before installing or connecting third-party skills or MCP servers.