AI agents that can run commands on a Mac are now being used to install malware, although the simplest way to avoid it is not installing software that takes actions on your behalf.

The OpenClaw agent framework’s widely shared add-ons spread macOS infostealing malware through seemingly routine setup instructions. Users followed links and ran commands they thought were necessary for normal operation.

The worry is how modern agent frameworks are getting more powerful by giving deep access to files, browsers, and terminals.

OpenClaw is an experimental agent framework designed to act directly on a user’s behalf. Agents built on OpenClaw can access local files, operate browsers, run terminal commands, and retain long-term memory about how a user works.

If something goes wrong, the access can lead to an unusually large blast radius. Malicious code run through an agent gets the same privileges as the user, which means it can access credentials, active sessions, and development tools.

OpenClaw agents get new abilities through "skills," which are usually simple markdown files. These files explain how to do specialized tasks and often include links, setup steps, and terminal commands you can copy and paste, acting like an installer.

Developers are trained to move quickly through setup documentation, especially when a tool appears popular or well-reviewed. Agent systems amplify that behavior by summarizing instructions and presenting them with confidence, reducing hesitation and scrutiny.

How the malware campaign worked

Security researchers discovered that a widely downloaded OpenClaw skill was being used as a malware delivery vehicle. The skill appeared legitimate and described itself as a normal integration.

Early in the setup process, it introduced a required dependency and provided links to install it. The links directed users to sites controlled by attackers.

The setup process asked users to run a shell command that decoded a hidden payload, ran it, and then downloaded a second script. Finally, it installed a macOS binary and removed quarantine settings so the built-in malware checks wouldn’t detect it.

The attack followed a familiar pattern seen in other supply-chain compromises. Documentation acted as the wrapper, convenience acted as the lure, and execution happened with user consent under false pretenses.

What the malware steals

The installed payload was identified as macOS infostealing malware. Infostealers focus on quietly harvesting valuable data rather than disrupting systems in obvious ways.

Targets typically include browser cookies and active login sessions, saved passwords and autofill data, developer API tokens, SSH keys, and cloud credentials. Any asset that can be reused for account takeover is fair game.

For developers, the damage from compromised credentials can go way beyond just one machine. It can lead to access to source repositories, cloud infrastructure, CI systems, and administrative dashboards.

Malware detection. Image credit: 1Password

The campaign targeted macOS, but the technique is platform-agnostic. Any agent framework that encourages users to execute setup commands can be abused.

Apple’s role is limited to the environment where the malware ran. The attackers knew macOS defenses and worked to bypass them, showing sophistication rather than a unique platform flaw.

Why Model Context Protocol does not solve this

Some developers think that structured tool interfaces like the Model Context Protocol can stop abuse by controlling what agents can do. However, that assumption doesn’t really work out in real life.

Agent skills can bypass structured tool calls entirely. Markdown instructions can navigate around any protocol boundaries using social engineering, direct shell commands, or bundled scripts.

A security model that depends only on tool gating is still at risk when execution is hidden as documentation.

What users should do now

Security guidance around OpenClaw-style tools is blunt. These agents should not be run on company devices, machines with access to production systems, or computers that store personal identifying information. In short, until there are guardrails that work, avoid this class of application.

Any device used to install agent skills should be assumed compromised until proven otherwise.

Users who already ran such tools should rotate credentials, invalidate active sessions, review account sign-ins, and involve security teams where appropriate. Further experimentation should move to isolated machines with no saved credentials and no corporate access.

When developing an agent framework, it’s important to start by denying shell execution and tightly controlling access to credentials. You should also enforce permissions that are specific, temporary, and can be revoked easily.

Make sure logging and attribution are integrated from the beginning, rather than adding them after something goes wrong.