Skill Permissions, Sandboxes, and Trust
A skill can suggest an action. Only the host can authorize it, only an isolation boundary can contain it, and only verification can tell you whether it worked. Explain why activating a skill does not grant tool authority or create a sandbox. Separate capability exposure, permission policy, approval, execution isolation, and verification. Threat-model a skill package, its resources, its scripts, and the content it processes. Review commands, paths, network needs, secrets, and side effects before execution. Choose a process, container, or microVM boundary according to the task's risk. This lesson has two required route edges. Complete Lesson 25 and complete Lesson 15 or demonstrate that you can separate tool poisoning and untrusted content from authority-bearing instructions. If Lesson 15 is missing, take that detour before continuing; the focused website route keeps Lesson 26 visible but reports the unmet edge. A code-review skill contains this instruction: "Run the project's test suite and inspect the failure." That sentence is harmless in one environment and dangerous in another. In a disposable repository container with no secrets and no network, running tests is bounded. On a developer laptop, the same command can execute repository-controlled build hooks with access to SSH agents, cloud credentials, browser data, and the entire filesystem. The skill did not change. The authority around it did. Now add indirect prompt injection.…
Skill Permissions, Sandboxes, and Trust: A skill can suggest an action. Only the host can authorize it, only an isolation boundary can contain it, and only…
This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.
Browse the complete course catalog or open this lesson on GitHub.