A skill’s permission is not its purpose

Two kinds of influence

A skill can influence an agent’s interpretation of its task and can also cause filesystem, network, or tool actions. SkillGuard proposes governing both. These are different review questions: is this guidance appropriate for the user request, and is this action within the permission boundary?

A tool permission granted at installation is not evidence that every later use of that tool is intended. Conversely, a polite instruction is not containment if the runtime lets an untrusted script read unrelated files.

Write the allowed action as a tuple

Record the exact package revision, legitimate task, input class, permitted data, target path or destination, and approval requirement. When a skill proposes an action, compare those fields with the user request and independent policy. Treat a new recipient or unrelated data source as a new decision, even if the package calls it a prerequisite.

Observe and enforce separately

Log attempted and completed effects with their originating skill revision. Put filesystem and network restrictions outside skill prose; require an independent approval for sensitive or new destinations. Test with synthetic data to confirm that a blocked action stays blocked when the same request is phrased differently.

What the paper does and does not show

SkillGuard reports reductions in attack success in selected adversarial settings and evaluates permission taxonomy and manifest generation. Its abstract does not establish that the approach prevents all poisoning or transfers unchanged to every host. This guide is an editorial application of the principle, not an implementation or independent replication of the paper.