- Permissions belong to a use case, not only a package name.
- Constrain filesystem and network behavior together.
- Test rejected actions in an isolated environment.
Define the smallest working profile
List the inputs, outputs, commands, and network destinations required for the legitimate task. Test that profile with synthetic data. Expand it only when a specific blocked requirement is understood and reviewed.
The profile should be attached to a package revision and a use case. A single skill can serve several workflows with different data sensitivities; it does not need the union of every user’s permissions in every run.
Filesystem boundaries
Separate input and output areas, protect unrelated directories, and consider whether outputs may replace existing files. Avoid making secrets available in the working environment simply because the agent can run code there.
Check symlinks, temporary directories, subprocesses, and inherited environment values in the actual sandbox. Permission configuration needs evidence that it works, not only a readable declaration.
Network boundaries
List destinations by purpose. Distinguish downloading a public resource from sending private content. Where practical, restrict outbound connections and validate targets independently of skill-generated instructions.
A task that needs one external service should not automatically receive arbitrary egress. Consider what information the allowed service receives and how that service authenticates requests.
Consequential actions
For publishing, sharing, deleting, or changing access, apply action-specific authorization. Show the target, scope, and meaningful arguments at approval time. Make it possible to reject the action while preserving the rest of the task.
Prefer credentials that are scoped to the service and task. Do not place general administrative tokens in reach of a package that only needs to generate a document.
Verify containment
Try a read outside the approved input area, a write to a protected path, and an outbound request to a blocked destination in the isolated test environment. Observe the rejection and log it. Do not use real credentials as test data.
Containment limits impact; it does not certify the package. Continue to review the skill itself and its updates.
Worked example: the chart needs one folder, not a workstation
A chart skill needs read access to a synthetic CSV directory and write access to an output directory. The default agent session can also read browser profiles and cloud configuration. The excess access is not needed for the chart; it expands the effects of any misleading instruction or compromised helper.
Work through the evidence
Define allowed inputs, output locations, destinations, and sensitive actions before execution. Use an isolated environment appropriate to the host rather than assuming that an instruction to behave safely enforces anything. Try denied reads and network requests with synthetic markers. Record whether the operating system, sandbox, application, or approval mechanism stopped each attempt.
Decision criteria and a useful review record
A useful permission profile lets the approved task complete and blocks unrelated effects. Document any exception with purpose and duration. Separate network isolation from filesystem isolation; one cannot substitute for the other. Treat a prompt asking for broader access as a new decision, not an automatic continuation of the original approval.
Sources & scope
This guide combines editorial explanation and practical review suggestions. Linked sources support the underlying concepts; this site has not independently replicated their experiments.
S10