Poisoned Skills Are Targeting Developer Credentials
Learn how poisoned AI skills deliver the AMOS infostealer through fake setup steps, why they still earned high security grades, and how to spot red flags.

A poisoned AI skill can turn a routine development task into a security risk for the wider business. A developer working on a project may use an AI skill to improve results and productivity. A malicious skill can claim that an additional component must be installed first. Following that instruction can introduce credential-stealing malware onto a computer already connected to company code, cloud accounts, and internal systems. The attacker uses the legitimate task to make a harmful action appear necessary.
An employee simply trying to increase productivity can cause exposure that extends to the organizational access held on that endpoint. Cyera Research's investigation into poisoned AI skills shows how attackers exploit that decision. Across a wider study of more than one million skills, researchers found 516 exhibits associated with an operation distributing Atomic macOS Stealer, or AMOS.
Of the 516, Cyera Research confirmed 70 net-new malicious skills across six repositories and platforms in September 2026. All 70 carried high security scores from Skills Directory, a popular marketplace for finding and downloading skills, when collected. The chart below shows where those 70 exhibits were collected.
The campaign connected three aspects that companies often consider separately: employee productivity tools, reassuring marketplace labels, and the endpoint's access to the business.
How a Useful Capability Becomes an Infection Route
Skills are reusable instructions that teach an AI agent how to perform a particular task. They might promise help with a development tool, an integration, or updating records in a particular system. Employees adopt them to solve an immediate problem, often while already working inside company systems. This gives attackers a convincing context for an installation request: before the skill can start working, the documentation says another package must be installed.
This harmful step appeared to support the capability the user wanted. Depending on the workflow and the permissions involved, the agent or the employee could be persuaded to follow it and install malware.
The macOS payload in the operation was AMOS, a years-old infostealer designed to collect information such as saved passwords, browser sessions, and sensitive files. On a corporate computer, those resources may provide access to company accounts or information beyond the device itself. A stolen session may allow an attacker to reuse authenticated access, and stolen files may expose intellectual property or valuable operational information. Our research identifies a malicious delivery route, as there’s no way to measure successful enterprise compromises.
Why Favorable Security Grades Matter
The 70 high grades are important because they can influence whether someone chooses them. Many employees browsing a skills repository would interpret an A or B grade as evidence that a security assessment has meaningfully reduced the risk. That can lower scrutiny precisely when the employee is being asked to install something. The investigation shows that malicious instructions can remain available alongside strong security signals.
The meaning and coverage of those signals is worth a closer look. On Skills Directory, an A indicates few detected risk signals, while a B indicates some concerns. Its published grading methodology covers the main SKILL.md instruction file, rather than all bundled scripts and supporting files. Neither grade guarantees safety. The takeaway for leaders: a marketplace assessment cannot replace the company's informed decision about what behavior it will authorize and what resources it will expose.
Follow-up checks confirmed that all 70 skills were subsequently removed. That action reduces future exposure, but it cannot undo an installation that has already happened. Companies need to distinguish removal from recovery: the former addresses availability on a platform, while the latter requires understanding whether an employee or agent followed the instructions and what information may have been exposed. It’s not clear how many users installed these skills or how long every listing had been available before collection.
The Lures Point Toward Organizational Workflows
The nature of these skills also highlights why this should concern businesses. Developer tooling accounted for 35.7% of the exhibits, office productivity for 12.8%, and documents and knowledge for 3.5%. Together, these categories represented approximately 52% of exhibits. The subjects were just the type that people who use their computers to create, administer, or access organizational resources would be looking for.

The underlying Markdown instruction files also explicitly referenced CI/CD secrets and cloud accounts. CI/CD systems automate the building, testing, and release of software; their credentials connect directly to a company's development operations. These references strengthen the link to workplace environments. The breakdown of the type of work these skills target describe advertised capabilities, however, and should not be presented as a measured rate of attacks against enterprises.
Although AMOS targets Macs, the governance issue extends across corporate endpoints. The corpus included skills with separate installation instructions for Windows and macOS. More broadly, companies approve AI products while employees may subsequently add components that change their behavior. A skill can introduce a new dependency, request additional access, or direct activity toward an external service after the original product review. Similar trust decisions arise with plugins and connectors. The organization needs to understand the additions shaping an agent's actions throughout its use.
What Companies Should Change
The best way to stop AMOS and other malware-related attacks delivered through skills is to prevent agents from installing software without direct human approval. Any message that the skill cannot complete the desired task until something else is set up should be seen with skepticism and deserves additional scrutiny. So should text in the instructions such as “Prerequisites” or “Setup” and overly urgent messages such as “IMPORTANT” or “CRITICAL REQUIREMENT.” Grades from a third party should not replace these checks.
Employee education is also critical to thwarting this new threat. Security leaders need to communicate the common characteristics of malicious skills to the broader org. They also need to build a clear process for reporting any suspicious skills and other AI assets employees come across, whether they executed them or not. This can help catch incidents early and reduce the blast radius.
Finally, establish clear owners for any skills used in sensitive workflows who are responsible for tracking how they change and conducting regular reviews. So are tools that can scan the full skill package, including supporting scripts and referenced resources, to decode concealed instructions. All of these activities should happen alongside continuous monitoring of actual agent behavior.
Leadership should make ownership explicit. Someone must be responsible for the agents used in sensitive workflows, the extensions added to them, and the access they receive. An inventory and approved sources provide a starting point. Reviews should examine what a component asks the agent or user to do, including installation requests, credential handling, and connections to unfamiliar destinations. Favorable grades should inform that review but not be a substitute for examining the requested behavior.
Companies also need scanning capabilities suited to how AI skills operate. Assessments should examine the full skill package, including supporting scripts and referenced resources, decode concealed instructions, and evaluate the actions the skill asks an agent or user to perform. A scanner should identify suspicious installation requests, credential access, and external data transfers, while clearly reporting any content it could not inspect. These checks should inform approval decisions and work alongside monitoring of actual agent behavior, because a favorable scan result cannot establish that every subsequent action will be safe.
Permissions should remain proportionate to the task. An agent preparing a document should receive the files and access needed for that work. Requests to install unfamiliar software or reach software delivery credentials deserve additional scrutiny. Security teams also need enough visibility to connect suspicious activity to the component that requested it and determine whether the action was completed.
Poisoned skills show how an ordinary productivity decision can put an endpoint's wider organizational access in the hands of a bad actor. Companies can manage this risk by carrying their existing expectations for software review, limited permissions, and incident response into their use of AI extensions. The practical question is whether the business knows what its agents have been instructed to do, who supplied those instructions, and how much authority they can exercise.


