A developer detailed their week recently. They had requested an AI assistant’s help in downloading a transcription software, and got the download command in return. They entered it in a terminal. The website turned out to be a rip-off, the package was infected with malware and it executed right away.
The developer wiped the machine and started the build from scratch. However, reviewing the backup they found a SKILL.md file for their coding assistant. It looked just like the document with a style guide of theirs. And there were stealth commands to re-download the malware and send any credentials at the start of loading.
Restoration of the file alone would make sure the freshly built laptop gets re-infected with malware on the first day.
What is a poisoned agent skill? A skill is a set of natural language commands for an AI coding assistant, often in the form of a SKILL.md file. A poisoned skill is a set of commands that hides the malicious instructions among others.
The Account Is One Person’s, The Pattern Is Documented
This story came out as one public posting without any samples of malware nor any indicators, and there was no independent analysis of them either.
The two parts of it, nevertheless, describe types of attacks that have been thoroughly studied by security researches. This is why this story deserves attention.
How An Assistant Hands You A Bad Link
The language models make up package names. One research paper analyzing 2.23 million samples of code across 16 language models showed that 19.7% were referencing packages which don’t exist.
The attackers register the package names. The fictional dependency becomes a real and malicious one, and anyone who tries to install it using the recommended command will get this package. The method is named slopsquatting.
It’s possible due to the consistency of hallucinations. 58% of fake package names were recurring during multiple prompts, allowing the attack to turn from guesswork into a targeted one.
It became possible to use different channels for distributing the fake packages. The attackers purchased paid searches leading to transcripts of chats with AI. There, an accurate-looking setup guide asks the user to enter a certain command in their terminal, and the page itself is hosted on the website of the AI model provider. This is exactly the feature that prevents anyone from double-checking.
Sites imitating the official installers of AI and development software are a new category altogether. They infect people who trust instructions with infostealers.
The Text Was the Payload
The File That Survives A Rebuild
Cleaning the infected machine is good advice. This is based on the assumption that the infection exists in the binaries.
Agent skill makes this assumption invalid. This technique is plain text and does not invoke any signatures. The back up utility will preserve this technique like preserving notes and other documents. The instructions in there do not do anything until AI agents execute it.
This is a technique for achieving persistence in a file format that is not scanned at all. This is also one technique that survives one of the most trusted remediation techniques.
What The Skill Marketplaces Actually Contain
Of the 3,984 agent skills published in the two marketplaces, 13.4% had at least one security problem, while manual analysis revealed that 76 of them had malicious payloads.
The attacks were not hidden. These included downloading malware from protected archives and leaking data using base64 encoding. There were others that disabled security mechanisms or stole credentials for cloud and financial services.
All of this was enabled by the publishing barrier. Publishing a skill involved creating a Markdown file along with an account that had been created at least a week ago.
Instructions Stopped Being Documentation
This applies not only to skill files. Configuration files for AI code editors may contain instructions that are invisible to a human user. Hidden Unicode characters will take care of it, remaining invisible in the text editor while still readable by the model.
During the documented tests, the assistant received those hidden instructions and inserted the code controlled by the attacker. And it did not reveal the insertion in its natural language answer. After inserting the poisoned configuration into a public repository, it is distributed to all those who clone it.
One platform reacted to it by displaying a warning when the file contains hidden Unicode characters, demonstrating the invisibility of this attack.
The same can be done using README files. Location is irrelevant. If the agent reads it, it can be instructed by it.
We have investigated another failure mode when a single web page hijacks the browsing agent into code execution on the host.
The Reviewer Is Doing The Wrong Job
Reviewing all the skills and configuration files prior to the agent accessing them is what this developer claims to have been the saving grace for their rebuilt computer. This is sensible practice, but it doesn’t scale.
There is a simple structural reason for that. If a human looks at a Markdown file, they will see whether the contents make sense or not. The real danger is whether the contents make whatever a trusted process does as a result of them sensible, and the two things are not the same, especially when it comes to non-printing characters.
This is where Execution Governance comes in. Instead of determining whether an action or a file makes sense or not, Execution Governance asks whether the code is trusted. And the payload that is being executed because of the Markdown file is not yet determined to be trusted.
The execution path does not matter anymore. Whatever the user is told to execute through the chat, terminal line, config file, or a backup: untrusted code executes with restrictions rather than without any. Writes into files are virtualized and the registry edits isolated. The reinfection that the recovered skill file was supposed to do doesn’t happen.
Conclusion: The File Was Documentation. The Agent Made It Execution.
The defining lesson from poisoned agent skills is that persistence no longer has to live in a binary, service, registry key, or scheduled task. It can live in instructions that a trusted AI agent will later interpret and act upon.
A SKILL.md, README, or editor configuration file can look like ordinary project documentation while carrying commands that tell an agent to download software, execute shell commands, modify files, or exfiltrate credentials. The file itself may survive backup, synchronization, repository cloning, and even a clean system rebuild because traditional remediation processes treat it as text rather than executable state.
That changes the persistence model. The malicious behavior is not fully expressed until the agent reads the instruction and converts natural language into action. The payload may be absent during backup and appear only when the restored environment becomes active again. In that sense, the instruction becomes a latent execution trigger.
Why This Threat Matters
- Persistence can survive a clean rebuild. Restoring poisoned agent context can recreate the path to compromise even after binaries and operating-system artifacts have been removed.
- Natural language can become operational state. A Markdown file may influence shell execution, package installation, file modification, or credential access once an agent consumes it.
- Traditional file scanning has a blind spot. Text instructions, hidden Unicode, and repository context may carry intent without carrying a recognizable executable payload.
- Agent ecosystems create a new supply chain. Skills, configuration files, READMEs, and marketplace packages can distribute instructions across many developer environments.
- Slopsquatting adds another delivery path. Repeated hallucinated package names give attackers an opportunity to register packages that AI assistants may later recommend.
- Human review does not scale cleanly. A document can look reasonable to a person while still producing harmful behavior when interpreted by an autonomous tool.
Where Defensive Control Must Operate
Defensive control must move beyond deciding whether a skill file looks suspicious and focus on what execution follows from it.
Xcitium Advanced EDR, powered by Xcitium’s patented Zero-Dwell platform provides that runtime boundary. If a poisoned skill, README, configuration file, or AI recommendation results in an unknown payload being downloaded or executed, Execution Governance governs what that code may do before trust exists.
The instruction path can vary. The execution boundary should not.
Restore the Environment. Revalidate the Instructions.
Recovery from an AI-agent compromise should include the context the agent will read after the rebuild: skills, repository instructions, editor configuration, automation files, and restored backups. Reinstalling the operating system is not enough if the instruction that caused reinfection is restored with it.
The larger lesson is that AI agents have turned documentation into a potential control surface. Security therefore has to evaluate not only what files are present, but what trusted automation will do because those files exist.
