AgentSkills.site

SKM-P02 · Portability

`allowed-tools` is experimental

The specification marks `allowed-tools` experimental, with support that 'may vary between agent implementations.' Don't treat it as a security control.

What the rule is

`allowed-tools` is a space-separated list of pre-approved tools, and it's in the specification — but the specification itself marks it experimental, stating that support 'may vary between agent implementations.' No runtime's documentation commits to consistent behaviour for it.

It's also the field people reach for first when they want to constrain what a skill can do, which makes its unevenness the most consequential caveat in the format for anyone building a trust or safety model around skills.

Where it comes from

Which runtimes enforce it

RuntimeEffectNote
Claude CodeNot documentedIn the spec, but the spec itself does not commit to consistent behaviour across implementations — that caveat is the finding.
CodexNot documentedIn the spec, but the spec itself does not commit to consistent behaviour across implementations — that caveat is the finding.
CursorNot documentedIn the spec, but the spec itself does not commit to consistent behaviour across implementations — that caveat is the finding.
OpenClawNot documentedIn the spec, but the spec itself does not commit to consistent behaviour across implementations — that caveat is the finding.
Hermes AgentNot documentedIn the spec, but the spec itself does not commit to consistent behaviour across implementations — that caveat is the finding.

How to fix it

  • Don't rely on `allowed-tools` as a security or safety control. If tool access genuinely needs to be constrained, do it at the runtime or MCP-server level instead, where the guarantee is real.

Elsewhere