Are Agent Skills Safe? A SKILL.md Security Checklist

An Agent Skill is safe to enable only within a reviewed execution environment and an understood set of permissions. Read its instructions, inspect its executable code, identify everything it downloads, and test the boundaries that matter to your workflow. A convincing description is insufficient evidence of what the package will do. Start with the editable Agent Skill review worksheet, which records the artifact, requested access, observed behavior, and approval conditions. For the broader control model, see the AI agent security guide.

What belongs in the review

A Skill is a folder containing a SKILL.md file — YAML frontmatter plus markdown instructions — optionally alongside scripts, references, assets, or other files. Anthropic introduced Agent Skills on October 16, 2025, and published the format as an open standard on December 18, 2025. The format specification defines the package structure; effective execution permissions depend on the runtime that loads it.

Review the whole package and any instructions that fetch additional content. Record the publisher, version or commit, dependencies, installation steps, referenced domains, and license. A document that asks an agent to run an external installer deserves the same attention as a bundled executable.

Source inspection and effective permissions

Determine the effective permissions of the runtime you will actually use: filesystem roots, network destinations, visible credentials, subprocesses, and separately enabled tools. Do not infer isolation from the fact that a feature is called a Skill, or assume every runtime grants full host access. The specification's experimental allowed-tools field has implementation-dependent support; a written declaration is not proof of enforcement.

An agent can inspect a bundled script when its tools and filesystem permissions allow it. It can also execute that script without loading the source into its context. Anthropic explicitly distinguishes these paths and recommends auditing bundled files before using less-trusted Skills. Make source inspection an explicit review step; do not assume it happens merely because the agent can execute the file. Anthropic's Skills design and security guidance.

Test the deployed policy with synthetic data and disposable credentials. Check denied file reads, writes, and destinations, including attempts through child processes and alternate tools. A timeout does not prove that an egress policy blocked a request; retain the enforcement evidence that distinguishes a denied action from an unrelated failure.

Installer and download risks

Treat a prerequisite that downloads an archive, runs a remote shell command, or installs an unpinned dependency as another artifact to review. A publisher's instructions are not independent evidence that an installation step is necessary or safe.

Obtain a stable review copy through your normal trusted download process. Inspect the files and dependencies before running setup. If a script fetches more code at runtime, record the destination, how the downloaded artifact is verified, and what happens when its contents change.

Use a disposable environment with synthetic data for initial execution. A file hash identifies reviewed bytes; it does not establish publisher identity or prove that those bytes are harmless. Preserve provenance separately and use an immutable execution artifact where possible.

The threat surface, in five categories

Security teams can structure a deployment review around five boundaries:

• 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. Record the actual runtime grants for shell, filesystem, network, and external tools. Verify whether any per-Skill restriction is enforced.
• Execution context. Identify visible environment variables, installed tools, subprocess permissions, and dependency installation steps.
• External communication. Evaluate egress restrictions and separately enabled channels such as email, webhooks, or application connectors.
• 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. Review any prerequisite that downloads or executes additional code, including remote installers and package runners.
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.

Record the reviewed files without executing them

List symlinks separately, then inspect the instructions and each script:

find ./reviewed-skill -type l -print
find ./reviewed-skill -type f -print
sed -n '1,200p' ./reviewed-skill/SKILL.md

This Python example records file digests without executing the Skill's code or following directory symlinks. Use a stable review copy; changing files during inspection defeats the purpose of that record.

from hashlib import sha256
from pathlib import Path

root = Path("reviewed-skill")
if root.is_symlink():
    raise SystemExit("Review the symlink target separately")

def inventory(directory):
    for item in sorted(directory.iterdir()):
        if item.is_symlink():
            print("REVIEW SYMLINK", item.relative_to(root))
        elif item.is_dir():
            inventory(item)
        elif item.is_file():
            print(sha256(item.read_bytes()).hexdigest(), item.relative_to(root))

inventory(root)

Retain the inventory with the review worksheet. Record an allowed task and denied boundary tests, their expected outcomes, observed outcomes, and enforcement evidence. Confirm that rejecting an approval prevents the corresponding action.

How this differs from MCP server risk

A Skill packages instructions and optional code for an agent runtime. MCP defines a client-server interface to tools and resources. A remote MCP deployment may have a separate process and authentication boundary, but the protocol name does not prove that either is configured correctly or that the server is trustworthy. An authenticated connection can still expose an overly powerful tool; a Skill can have narrow effective access when its runtime enforces isolation. Evaluate the actual identity, permissions, reachable resources, outputs, and consequential actions. Use the MCP server security checklist for that complementary review.

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. Compare actual deployment boundaries and permissions, rather than inferring safety from either package format or protocol name.

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.

Does a permissions worksheet enforce access? No. It records the review. Enforcement requires a runtime policy that you configure and test, including subprocesses and alternate tools.

Does sandboxing solve the Skills trust problem? It can reduce reachable resources and the impact of mistakes. Its value depends on the policy actually enforced: network access, mounted files, credentials, subprocesses, and alternate tools. Source review and monitoring remain useful alongside those restrictions.

Should an update require another review? Yes when it changes the reviewed artifact or its behavior and access. Pin the approved version and retain the evidence needed to compare the update.