Agent Skills — Anthropic's standard for packaging instructions and executable scripts an AI agent loads dynamically — are not inherently unsafe, but the trust model behind them is easy to misjudge. A Skill's bundled script runs with whatever privileges the agent already has, and the agent only ever sees the script's output, never its source. That combination is why "just read the SKILL.md before enabling it" is necessary but not sufficient. This post explains what a Skill can actually do, a named incident that shows the failure mode in practice, and a checklist for vetting one before you turn it on — the same discipline covered generally in the AI agent security guide.

What an Agent Skill is, and how fast the standard spread

A Skill is a folder containing a SKILL.md file — YAML frontmatter plus markdown instructions — optionally alongside scripts, binaries, or installer directives. When a user's request matches a Skill's description, the agent follows that Skill's instructions instead of improvising from scratch. Anthropic introduced Agent Skills on October 16, 2025, and released the format as an open standard on December 18, 2025, donating it toward the Agentic AI Foundation under the Linux Foundation.

At launch (December 2025), coverage named Microsoft, OpenAI, Atlassian, Figma, Cursor, and GitHub as adopters, with partner Skills contributed by Canva, Stripe, Notion, and Zapier. Treat that specific vendor list as a snapshot of launch week rather than a current fact — re-verify current adoption before repeating it as present tense, since ecosystem participation in a fast-moving open standard changes quickly.

The trust model: bundled scripts execute with high privilege, invisibly

The part of Skills security that matters most is structural, not a bug in any particular implementation. A Skill's script is not sandboxed by a discrete permission grant the way a mobile app's camera access is — it runs inside the agent's existing execution context, inheriting whatever shell, filesystem, network, and credential access the agent already has. If your agent can read email and execute shell commands, every Skill you enable inherits both.

Compounding that, the agent only sees the script's output, never its source. A malicious or compromised script can read environment variables, harvest credentials from configuration files, or make an outbound network call, and the agent has no way to notice — it only receives whatever text the script chooses to return. This is the specific property that separates Skills risk from ordinary "arbitrary code execution": the execution is not just privileged, it is opaque to the very system deciding whether to trust the result.

Most Skills runtimes ship without sandboxing enabled by default. Optional container-based isolation typically exists, but it requires explicit configuration that most installs never turn on — the default assumption is that the user reviewed the Skill's content and accepts the risk. Two academic security-analysis papers published in 2026 formalize this as a distinct threat taxonomy for agent-loaded, dynamically-executed extensions, separate from the threat models built for traditional dependency management or browser extensions.

Named incident: the ClawHub Skills supply-chain compromise

On February 1, 2026, security research firm Koi Security published findings from auditing every Skill then listed on ClawHub — the public Skills registry for OpenClaw, a popular self-hosted AI assistant built around the SKILL.md pattern. Out of 2,857 Skills audited, researchers found 341 malicious, roughly 12% of the entire registry, with 335 of them sharing tactics consistent enough to be tracked as a single campaign the researchers named ClawHavoc. A February 16, 2026 update reported the problem had grown alongside the registry itself: as ClawHub scaled from 2,857 to over 10,700 Skills, the malicious count more than doubled to 824, spreading into roughly 25 additional attack categories.

The malicious Skills used names matching common searches — a Solana wallet tracker, a YouTube summarizer, a Polymarket trading bot — with professional-looking documentation. The actual payload delivery ran through a "Prerequisites" section instructing users to either download an archive (Windows) or paste a shell command sourced from a code-snippet hosting site (macOS) before the Skill would "work" — a social-engineering step rather than a technical exploit of the Skills format itself. Koi Security's analysis identified the payload as Atomic Stealer (AMOS), a Malware-as-a-Service macOS infostealer sold on Telegram for $500 to $1,000 a month, capable of harvesting keychain passwords, browser data, cryptocurrency wallets, and SSH keys.

The incident happened on a third-party community registry, not Anthropic's own distribution channel — worth keeping distinct when you evaluate risk. But the underlying mechanism it exploited — unsandboxed execution, no cryptographic signing on registry entries, and a review step that assumes the user reads scripts they mostly don't — applies to any Skills ecosystem built the same way, and is the reason a vetting process matters regardless of which registry a Skill comes from.

The threat surface, in five categories

Security teams evaluating Skills should threat-model across these dimensions, adapted from the published Skills-specific taxonomies:

  • Data at rest. Skills and any persistent memory files an agent maintains can hold credentials or embedded API keys; an attacker who can read them gains access, and one who can write to them gains a persistence mechanism.
  • Resource access. There is no per-Skill permission dialog — a Skill inherits every capability the agent's runtime already has (shell, filesystem, network, email).
  • Execution context. Scripts run with full access to environment variables and installed tools; patterns like invoking a package runner directly, without an explicit install step, put the agent's whole environment in scope.
  • External communication. The agent's own legitimate channels — sending an email, posting to a webhook, calling an API — are also the exfiltration channel; there is no separate network boundary to monitor.
  • Trust boundaries. A Skill's instructions become part of the agent's prompt context, and so does anything that Skill later fetches from a URL — every piece of text the agent reads is a potential prompt injection vector, not just the initial SKILL.md.

A vetting checklist before you enable a Skill

  1. Read the actual bundled script source, not just the SKILL.md description — the description is marketing copy the Skill's author wrote about itself.
  2. Verify publisher identity and provenance — who maintains this Skill, how long has the account existed, is it the same publisher across versions.
  3. Flag any "Prerequisites" step that asks you to run an installer or paste a shell command from an external location — this was the exact delivery mechanism in the ClawHavoc campaign.
  4. Pin Skills to a specific reviewed version rather than auto-updating; a Skill that was safe last week is not guaranteed to still be safe today.
  5. Run Skills execution in an isolated, least-privilege environment where that option exists, rather than accepting the default of full host access.
  6. Treat the SKILL.md content itself as untrusted input to the model, the same way you would treat any external document the agent reads — see detecting prompt injection for the general pattern.
  7. Maintain an inventory of every Skill enabled per agent, with who approved it and when — you cannot audit what you have not catalogued, a discipline covered generally in building an AI agent inventory.
  8. Monitor for unexpected outbound network activity after enabling a new Skill, since the agent's normal communication channels are also the exfiltration path — the same reasoning behind data exfiltration risk in agentic AI.
  9. Run untrusted scripts through the same sandboxing discipline you'd apply to any agent-executed code, per tool-use safety and sandboxing agent actions, rather than granting a Skill blanket host access by default.

How this differs from MCP server risk

Skills and MCP solve adjacent but structurally different problems, and the risk profile differs accordingly. An MCP server runs behind a protocol boundary with its own authentication and scoped tool definitions — see what the Model Context Protocol is — so a compromised MCP server is still constrained to whatever tools it was scoped to expose. A Skill runs inside the agent's own execution context with no equivalent boundary by default; its blast radius is bounded only by whatever the agent itself can already do. The MCP 2026-07-28 spec revision formalizes Enterprise Managed Authorization for centrally governing MCP tool access — Skills currently have no equivalent standardized governance extension, which is exactly why vetting has to happen manually, per Skill, before enabling it.

Where a governance layer fits

None of the checklist above is a one-time task — Skills get updated, new ones get published, and an agent's enabled-Skills list drifts over time the same way any software inventory does. The pattern that holds up is treating Skills the way you'd treat any third-party dependency: catalogued, versioned, reviewed on update, and revocable without redeploying the agent. Praesidia is an AI agent security and governance control plane — agent identity and access, guardrails, audit evidence, and cost controls in one place — and inventory-and-revocation discipline of this kind is squarely the problem that category of platform exists to solve, whichever vendor you choose.

Common questions

Are Anthropic's Agent Skills inherently less safe than MCP servers? Not inherently — they solve different problems. But by default, a Skill's bundled script runs with the agent's full existing privileges and no separate authentication boundary, while an MCP server runs behind its own scoped, authenticated protocol layer. The practical effect is that Skills currently demand more manual vetting per addition than a well-scoped MCP tool does.

Can a malicious Skill be detected just by reading the SKILL.md file? Not reliably. SKILL.md is the human-readable description and instructions; the actual risk usually lives in a bundled script or an installer step the description references but doesn't fully disclose. Reading the SKILL.md is necessary, but you also need to read (or have someone read) any script it bundles or downloads.

What happened in the ClawHavoc incident, specifically? Security research firm Koi Security audited OpenClaw's public ClawHub Skills registry and, in findings published February 1, 2026, found 341 malicious Skills among 2,857 audited (roughly 12%), with 335 tied to a single campaign delivering a commodity macOS infostealer called Atomic Stealer via social-engineering-style "Prerequisites" instructions. A February 16, 2026 update reported the malicious count had grown to 824 as the registry scaled past 10,700 Skills.

Does sandboxing solve the Skills trust problem? It meaningfully reduces the blast radius, but adoption is the bottleneck, not availability — most Skills runtimes support optional sandboxed execution, but it requires explicit configuration that most installations skip, leaving the default behavior unsandboxed.

Who is actually building and maintaining the Agent Skills standard now? Anthropic released it as an open standard on December 18, 2025 and donated it toward the Agentic AI Foundation, a Linux Foundation project — meaning stewardship is intended to move beyond a single vendor over time, similar to the trajectory of other agentic-AI standards like MCP.