Agent Skills Security Guide: Vetting, Scoping and Monitoring Skill Packages

An Agent Skill is a folder of instructions and code that an AI agent loads on demand and then acts on with all of the agent's own access. The open Agent Skills format, originally developed by Anthropic and published at agentskills.io, packages a SKILL.md file with optional scripts, references and assets, and is now supported by many agent products. That portability makes skills a new software supply chain unit: a skill pulled from a public registry can tell an agent to run shell commands, read credentials or call external services, and the agent will usually comply. This guide explains how skills gain access, which settings control them, how to vet and monitor them, and the mistakes behind real incidents. It is for platform owners, security engineers and developers who allow skills in coding agents, desktop agents or API deployments, and complements the broader AI Agent Tool and Plugin Security Guide. Facts were checked against the specification and vendor documentation on 27 October 2026.

Key takeaways

• A skill has no identity of its own. It runs as the agent, with the agent's files, tools, network and credentials, so installing a skill is closer to granting access than to installing a document.
• The risky parts are scripts and instructions. Bundled scripts/, shell commands embedded in instructions, network fetches and directions to hide actions all deserve high concern during review.
• allowed-tools is a pre-approval, not a sandbox. The specification marks it experimental, and in at least one major client it grants listed tools without prompting while leaving other tools to normal permissions.
• Public registries have already been abused. Hundreds of malicious skills on ClawHub in early 2026 used "prerequisite" commands to install credential stealers, and scanning later missed evasive variants.
• Govern skills like code. Owners, separate reviewers, pinned versions, checksums, evaluation before promotion and a managed allowlist are the controls that hold up.

How identity and access work in Agent Skills

The specification defines a skill as a directory containing at minimum a SKILL.md file: YAML frontmatter followed by Markdown instructions. Optional directories are scripts/ (executable code), references/ (documentation loaded on demand) and assets/ (templates, images, data). Agents load skills by progressive disclosure: the name and description of every installed skill (about 100 tokens each) at start-up, the full body when a task matches, and bundled files only when needed.

Nothing in the format authenticates the author or limits what instructions may ask for. When a skill activates, its instructions enter the agent's context with the same authority as other trusted instructions, and its scripts run in whatever environment the agent has. Anthropic's documentation warns that a malicious skill "can direct Claude to call tools or run code in ways that don't match the Skill's stated purpose", and advises using skills only from trusted sources.

The effective blast radius therefore depends on the surface. Anthropic's overview gives three very different environments for the same format:

Decision guidance: the same skill is low risk in a network-less API container and high risk on a developer laptop holding cloud credentials and SSH keys. Allow third-party skills first in sandboxed, credential-free environments; require full review before they reach local coding agents or production integrations. Other products that adopt the format have their own storage paths and permission models, so check each vendor's documentation rather than assuming the same behaviour.

Admin roles and privileged access

Skill governance needs two kinds of privilege to be controlled: who can publish or install skills for others, and which settings let a skill bypass prompts. In Claude Code, documented on 27 October 2026, skills are discovered from several locations with a precedence order of enterprise over personal over project, and plugin skills are namespaced as plugin-name:skill-name.

• Repository skills are the sharpest edge: the documentation warns that a skill checked into a repository runs with the user's permissions, can grant itself tool access through allowed-tools, and can inject shell commands; workspace trust does not gate a project skill's allowed-tools in non-interactive runs. Anyone who can merge to a repository can therefore change what agents do on every clone.
• Dynamic context injection: commands written as !`command` run before the model sees the skill, and the documentation calls this "a higher-trust path" than the model's own tool calls. They are checked against permission rules and a deny match aborts the skill.
• Managed settings are the admin lever: disableSkillShellExecution blocks injected commands for non-managed skills; allowManagedPermissionRulesOnly makes the client ignore allowed-tools in project and personal skills; strictPluginOnlyCustomization can restrict skills to plugin sources; skillOverrides can turn named skills off; disableBundledSkills and syncClaudeAiSkills control built-in and synced skills.
• Permission rules: Skill denies the skill tool entirely, while Skill(name) and Skill(name *) allow or deny specific skills.
• Organisation libraries: on claude.ai, Enterprise organisations can turn on skill and plugin security scanning; owners and members whose role can manage Libraries can allow skills that failed the scan. Treat that override right as a privileged role and log its use.

For other agents, map the equivalent controls: where skills are loaded from, whether project-level skills load automatically, whether skills can pre-approve tools, and which administrator can change those settings. Keep the people who approve skills separate from those who write them: Anthropic's enterprise guidance says skill authors "should not be their own reviewers".

Integrations, API tokens and service accounts

Skills reach outside the agent in three ways: scripts making network calls, instructions telling the agent to use MCP tools or other connectors, and credentials found in the environment. Anthropic's enterprise guidance rates as high concern any MCP server references (they "extend access beyond the Skill itself"), network patterns such as URLs, curl, fetch or requests, and hardcoded credentials, which end up "exposed in Git history and context window".

• No secrets in skills: skills are copied, synced and shared. A token in SKILL.md or a script is a leaked token. Fetch credentials at run time from a vault with a scope limited to the skill's task. See the Credential Vaulting for AI Agents Guide.
• Scope the agent, not the skill: because a skill inherits the agent's identity, the only reliable limit is the agent's own credentials. Run skill-heavy agents under a dedicated non-human identity with least privilege rather than a developer's full cloud profile.
• Keep secrets out of reach: exclude .env files, SSH keys, browser profiles and wallet files from the agent's readable paths. These were the targets of the ClawHub stealers.
• External content is untrusted input: a skill that fetches instructions or data from a URL can be changed after review. Anthropic notes that "even trustworthy Skills can be compromised if their external dependencies change over time". Pin dependencies and block runtime downloads where possible.
• Service deployments: on the API, custom skills uploaded to a workspace are available to all its members, so treat the workspace API key that uploads skills as a publishing credential. Pin skill versions in production requests rather than using the latest.

Logging and detection

Skill activity is visible only if you log at the agent layer, because from the operating system's view everything runs as the agent process. Collect:

• Inventory events: skills added, changed or removed in each location (managed, personal, project, plugin, synced), with hash, source and approving reviewer.
• Activation events: which skill activated, for which user and session, and whether it was invoked by the user or chosen by the model.
• Tool calls during a skill: commands run, files read outside the skill directory, network destinations and MCP tools invoked. Alert on access to credential paths and on egress to new domains while a third-party skill is active.
• Policy events: scan failures, admin overrides of failed scans, denied Skill(...) rules, injected commands blocked by policy.
• Repository changes: pull requests that add or edit .claude/skills/ or equivalent folders, especially allowed-tools lines and ! commands. Require code owner review for these paths.

Metrics:

1. Percentage of installed skills that match an approved hash in the internal registry (target 100% for managed fleets).
2. Number of skills from unreviewed public sources found per month by endpoint or repository scanning.
3. Share of skills declaring allowed-tools or embedding shell commands that have a recorded security review.
4. Time from a new skill version being published internally to completed review and evaluation.
5. Alerts per month for credential path access or new egress during skill activation, and the share confirmed as true positives.

Hardening baseline

A phased rollout lets you keep useful skills while closing the high risk paths.

1. Discover (weeks 1 to 2): scan endpoints and repositories for SKILL.md files in all known skill locations; record source, hash, owner and whether each contains scripts, network calls, allowed-tools or injected commands.
2. Set policy in audit mode: deploy managed settings that log rather than block where the client allows it, and use permission rules to deny skills known to be unwanted. Watch which skills users depend on.
3. Review and register: run every retained skill through the eight point review below, assign an owner, store an approved hash and pin the version.
4. Enforce on a pilot ring: for one team, block shell injection for non-managed skills, ignore allowed-tools outside managed skills, and restrict skill sources to managed or plugin channels. Measure breakage for two weeks.
5. Roll out and keep a rollback: extend to all users. Keep the previous managed settings and the previous version of each skill so you can revert immediately if a change breaks critical work.
6. Evaluate before every promotion: Anthropic recommends three to five representative queries per skill covering should-trigger, should-not-trigger and edge cases, tested on each model you use, and treating every update as a new deployment requiring full security review. Add a security case to that suite. See the AI Security Evaluations Guide.

Eight point review

Anthropic's enterprise checklist, usable for any agent: read all skill content; verify script behaviour matches the stated purpose; check for adversarial instructions; check for external URL fetches or network calls; verify there are no hardcoded credentials; identify the tools and commands the skill tells the agent to run; confirm redirect destinations; verify there are no data exfiltration patterns. Add two of our own: compare the skill against its upstream source to detect tampering, and record checksums with signed commits for provenance.

Framework mapping

Common misconfigurations

• Auto-loading project skills from any repository: developers clone an untrusted repository and its skills load with their permissions, including allowed-tools grants and injected commands.
• Treating allowed-tools as a restriction: teams assume the field limits a skill to the listed tools. In Claude Code it pre-approves those tools for the turn and does not restrict others, which still follow normal permission settings.
• Installing from public registries without review: popularity and download counts are not vetting. The ClawHub campaign showed one publisher's skills reaching thousands of downloads.
• Relying on scanning alone: vendor scanning helps, but Anthropic notes its scanning does not cover API uploads or skills already present when scanning was enabled, and OpenClaw's maintainers called their own scanning "not a silver bullet".
• Floating versions in production: omitting a version means requests use the latest, so an unreviewed update goes live immediately.
• Running skills on credential-rich machines: developer laptops with long lived cloud keys, SSH keys and browser sessions give any malicious skill a valuable haul. Move risky work into sandboxes; see the AI Agent Sandboxing and Code Execution Guide.

Lessons from the ClawHub campaign

The ClawHub Malicious Skills 2026 campaign is the clearest example so far. From late January 2026 attackers published hundreds of skills to ClawHub, the public registry for the OpenClaw agent, posing as crypto trackers, trading bots and media tools. Koi Security's audit of 2,857 skills found 341 malicious ones. Each carried a "Prerequisites" section telling the user or the agent to run an encoded shell command or open a password protected archive, which installed stealers such as Atomic macOS Stealer aimed at exchange API keys, wallet keys, SSH keys, browser passwords and agent credentials. Publishing required only a GitHub account at least a week old, with no review. OpenClaw added VirusTotal scanning in February, but Unit 42 later reported evasive skills that slipped through.

MITRE ATLAS records an earlier proof of concept as case study AML.CS0049, Supply Chain Compromise via Poisoned ClawdBot Skill: a skill with an embedded prompt injection made the agent run a shell command contacting the researcher's server, and 16 users ran it within eight hours. The relevant ATLAS techniques are AML.T0104 Publish Poisoned AI Agent Tool, AML.T0011.002 Poisoned AI Agent Tool and AML.T0051 LLM Prompt Injection. Lessons: a registry is not a review process, scanning is one layer, and "prerequisite" steps in a skill are code that must be reviewed.

Practitioner checklist

• Inventory every skill location on endpoints, repositories, plugins and API workspaces, with source and hash.
• Allow skills only from managed or approved plugin channels on corporate devices; deny the rest with permission rules.
• Review every skill with the eight point checklist, with an owner and a reviewer who is not the author.
• Pin versions in production, keep the previous version for rollback and re-review every update.
• Block injected shell commands and ignore allowed-tools in non-managed skills where the client supports it.
• Require code owner review for changes to skill folders in repositories.
• Run agents that use third-party skills under a least privilege identity with no access to SSH keys, .env files or browser profiles.
• Remove all hardcoded secrets from skills and fetch scoped credentials from a vault at run time.
• Log skill activation, tool calls and egress during skill use, and alert on credential path access.
• Never run a skill's "prerequisite" commands without reading and approving them first.

Standards and references

• Agent Skills: Specification
• Agent Skills: Overview
• Anthropic: Agent Skills overview and security considerations
• Anthropic: Skills for enterprise
• Anthropic: Claude Code skills
• MITRE ATLAS: Publish Poisoned AI Agent Tool
• OWASP: Top 10 for LLM Applications 2025
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: AI Agent Tool and Plugin Security Guide · AI Coding Agents Security Guide · MCP Security Guide · OWASP Agentic Top 10 ASI04 Guide · A2A Protocol Security Guide