Agent Skill Security

Agent skills are operational instructions. They can tell an AI coding agent how to choose files, what checks to run, which tools to call, what output to trust, and when to stop. On some platforms, skills can also bundle helper scripts or reference files that change how the agent behaves.

That makes a skill closer to a dependency or runbook than a normal markdown note. A well-written skill can make agent work repeatable. A careless or malicious skill can steer an agent toward unsafe commands, secret exposure, unreviewed code changes, or policy violations.

Skill risk comes from the combination of natural-language instructions, referenced files, executable helpers, and agent permissions. The same skill can be low risk in a sandboxed toy repo and high risk in a production workspace with secrets and deployment access.

The first security question is where the skill came from. Marketplace pages, public repositories, internal snippets, and generated skills all need traceability. Teams should know the source URL, author, maintainer, version, license, install command, and update policy before enabling a skill for shared use.

Provenance also includes the files the skill points to. A clean-looking SKILL.md can reference scripts, examples, or documentation that carry risky instructions. Review the whole package, not just the top-level markdown.

A skill's blast radius is determined by the agent runtime around it. If the agent can run shell commands, edit files, reach the network, or read environment variables, the skill can steer the agent toward those capabilities. If a skill includes scripts, those scripts deserve the same review as any automation checked into the repository.

• Use file allowlists for high-risk repositories.
• Run untrusted skills in a sandbox before enabling them in real workspaces.
• Separate read-only review skills from skills that mutate code or call external systems.
• Require approval before scripts install dependencies, write outside the repo, or call production APIs.
• Keep platform-specific permission details anchored to official docs.

Skills can leak data without containing any secret themselves. A skill might instruct an agent to print environment variables, inspect config files, summarize logs, or paste command output into a conversation. If those outputs contain API keys, customer data, or unreleased product details, the skill has created an exposure path.

Enterprise teams need secret redaction at the gateway or runtime layer, explicit data-classification rules, and a policy that keeps credentials out of prompts, examples, generated reports, screenshots, and execution logs.

Skills are most useful when they reduce repeated prompting. They are dangerous when they normalize repeated high-impact actions without review. Any skill that touches deploys, migrations, billing, security controls, user data, or external writes needs approval gates.

Auditability is the difference between a reusable skill and an invisible behavior layer. When an incident happens, the team should be able to answer which skill loaded, what prompt or task triggered it, what files it read, what commands ran, what tools were called, what changed, and who approved the result.

Logging should connect skill activity to a work item and commit, not just to a chat transcript. Chat history is useful context; it is not a compliance-grade control by itself.

A mature program treats skills as part of the AI software supply chain. The checklist below is a practical baseline for platform, security, and engineering teams.

Skill security is not just a linting problem. It is a workflow problem: who requested the work, which context was loaded, which skill guided the agent, which commands ran, which commit resulted, and which reviewers accepted it.