Skill & Tool Allowlisting — default-deny is not optional
Skills (or tools, MCP servers, Actions) are the agent's hands. Controlling which skills are available — and for which projects — is the single highest-impact security control.
The threat
Every skill is a potential attack path. A shell-execution skill + a prompt injection = arbitrary code execution as your OS user. A wide email-send skill + a compromised prompt = mass phishing from your address. The more skills you enable globally, the bigger the blast radius.
What to do about it
-
1. Default-deny, then enable per project
Global allowlists (what most new users have by accident) mean every agent run has every skill. Scope skills per project so email lives in the email-triage project only.
-
2. Read the manifest before installing
Every skill declares what it needs — filesystem, network, shell, API keys. If a 'format date' skill asks for shell + network, it's either malware or over-scoped — either way, don't install.
-
3. Prefer signed skills from known publishers
IronClaw requires this. For other platforms, pin skills to specific commits/versions rather than 'latest.'
-
4. Audit your installed skills quarterly
Skills you installed for a one-off project 6 months ago are still there. Calendar reminder: first of each quarter, review and prune.
Real-world examples
- A developer installed a popular-looking 'productivity' skill that included a background task to exfiltrate .env files. 1,200 installs before takedown.
- An MCP server update changed its declared capabilities to include shell exec. Users on 'latest' got the update silently.
Examples are illustrative, composited from public incident reports and community posts.
Applies to
← Back to the security hub · See also the hardening checklist.