1. Turn the workflow into concrete capabilities
Permission labels such as files or network are too broad to support a real decision. Ask which files, which commands, which domains, which account, and which write operations the workflow needs. A documentation Skill reading one folder is different from a browser Skill signing into an external service, even if both are described as productivity tools.
Inspect SKILL.md, referenced scripts, configuration examples, and install steps together. A safe-looking summary can omit behavior delegated to a helper script or command-line tool.
2. Classify access by consequence
Read-only local access can still expose secrets. Local writes can overwrite generated files or duplicate sensitive documents. Shell execution inherits the tools and environment available to the Agent. Network access can transmit content outside the machine. Account actions can create messages, records, deployments, or purchases. Destructive operations need exact targets and a recovery path.
Do not collapse these consequences into one risk badge. Record the first credible failure mode and the control that prevents it.
- Files: exact folders, read/write mode, secret exclusions.
- Commands: binaries, arguments, working directory, and approval points.
- Network: destination domains and data leaving the machine.
- Accounts: identity used and external side effects allowed.
- Destructive actions: exact targets, preview, backup, and rollback.
3. Check evidence without turning it into certification
A pinned source revision makes the reviewed instructions reproducible. It does not prove that the workflow has been executed safely. Documentation quality, popularity, official-source status, and community use are separate signals; none should be relabeled as a runtime or security audit.
Prefer profiles that state what was reviewed, when it was checked, what remains unverified, and which dependencies are outside the source boundary.
4. Install with a minimum permission budget
Use a disposable branch or sample project first. Remove unrelated credentials, restrict filesystem scope, prefer read-only operations, and approve network or external-account actions one at a time. Run the smallest representative task before expanding scope.
The budget should describe what the Skill may do during this task—not every capability it might support. If the task only needs a report, do not grant permission to publish, deploy, message, or delete.
- The test project contains no unrelated secrets or customer data.
- Credentials are scoped to the minimum service and action.
- Writes are reviewable before they reach the main branch or external system.
- The first run has a named owner watching for stop conditions.
5. Define stop conditions before the first run
Stop when the workflow requests a broader directory, an unexpected executable, an unlisted domain, a credential with more privilege, or an irreversible external action. Also stop when output cannot be tied back to the pinned source and exact command.
A good stop condition is observable and immediate. “Be careful” is not a control; “do not continue if a command writes outside this worktree” is.