AI Agent Skills Security — How to Audit Skills Before Installing

Skills run with the same permissions as your AI agent. A malicious skill can read files, make network requests and execute commands on your behalf. Here is the audit process every developer should run before installing skills from sources they do not fully trust.

The power of skills — giving AI agents new capabilities through instructions and code — is also their risk. A skill is not a passive document. When triggered, the agent reads its instructions and may execute its bundled scripts. Those scripts run with whatever permissions the agent has on your machine.

For verified-organisation skills from Anthropic, Vercel and similar trusted sources, the risk is minimal. For random community skills you found on GitHub, the audit is not optional.

The Three Categories of Risk

Three things a malicious skill can do that should concern you:

Data exfiltration. The skill could read files containing credentials, API keys or personal information and send them to an external server. Look for any network calls in scripts.

Destructive actions. The skill could delete files, modify system configuration or perform other unauthorised actions. Look for any file system writes or shell commands that affect the system.

Prompt injection. The skill could direct the agent to perform actions in subsequent unrelated conversations, including ignoring your normal safety constraints. Look for instructions that try to manipulate the agent behaviour beyond the stated purpose.

The Five-Minute Audit Process

Before installing any skill from an unverified source, run this audit. It takes 2-5 minutes for a well-documented skill and catches most red flags.

Step 1: Read the SKILL.md description. Does it match what the skill claims to do in any README or marketing? A mismatch is a major red flag.

Step 2: Read the Markdown body. Does anything seem unusual? Does it instruct the agent to send data anywhere, access files outside the project scope, or perform actions unrelated to the stated purpose?

Step 3: List every file in the skill folder. Are there scripts? Are there files that seem out of place — binary executables, weird configuration files, anything that does not obviously belong?

Step 4: For each script, read it line by line. Pay specific attention to network calls (curl, wget, fetch, requests), file system access outside the project (especially ~/.ssh, ~/.aws, /etc), credential access (environment variables, config files) and any executable downloads.

Step 5: Check the author and the repo metadata. Is it a verified organisation? Are there many stars and active maintenance? Do other people use this skill successfully? skills.sh install counts are particularly informative — high counts mean the community has audited and trusted the skill.

Use Project Scope as a Sandbox

For skills you want to try but are not fully sure about, install at project scope (.claude/skills/) rather than user level (~/.claude/skills/). The skill only loads when you work in that specific project, limiting any potential damage to that directory.

Some AI agents also support permission scoping for skills. Claude Code, for example, allows configuring which skills can access which resources. The default is usually permissive (the skill can do whatever the agent can do), but you can restrict permissions for skills you want to use but not fully trust.

Building Safe Skills to Share

If you publish skills, follow practices that make them safe for others to install. Document everything your skill does, especially anything that touches the file system, network or credentials. Use environment variables for any configuration — never hardcode credentials or paths. Limit scope to the minimum needed for the skill purpose. Respond promptly to security reports.