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 what a skill asks for before installing it
A skill's instructions and any bundled scripts run with your agent's access. If a 'format date' skill wants shell and network, it is either malware or over-scoped; either way, don't install it.
-
3. Pin skills to specific versions and prefer known publishers
Pin skills to specific commits or versions rather than 'latest'. Some platforms add a trust rule of their own: IronClaw, for example, does not let the model self-activate a skill installed from IronHub, only one you name.
-
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.
Applies to
OpenClaw · NemoClaw · IronClaw · Kilo Code · Claude Cowork
← Back to the security hub · See also the hardening checklist.