Permissions
The permission identifiers capabilities declare, which ones need approval by default, and how policies block or gate them.
| Permission | Meaning | Approval by default |
|---|---|---|
filesystem.project.read | Read the mapped project folder | |
filesystem.project.write | Write the mapped project folder | |
filesystem.read | Read anywhere the worker's user can | |
filesystem.write | Write anywhere the worker's user can (high risk) | |
network.outbound | Network connections | |
git.read | Read repository history and state | |
git.write | Create commits and branches | ✓ |
browser.control | Drive a browser (high risk) | ✓ |
shell | Run shell commands (high risk) | ✓ |
process.execute | Start processes (high risk) | ✓ |
secrets.read | Receive secret values (high risk) | ✓ |
Manifests may use namespaced sub-permissions (filesystem.project.read is under filesystem); blocking a parent
blocks its children.
Policy
Organization policy
{
"capabilities": {
"installPolicy": "ASK",
"allowedTrust": ["OFFICIAL", "VERIFIED", "LOCAL"],
"approvalRequiredPermissions": ["shell", "secrets.read", "browser.control", "process.execute", "git.write"],
"blockedPermissions": ["filesystem.write"]
}
}An installation is evaluated as follows:
- Any blocked permission → blocked.
- A trust level not in
allowedTrust→ blocked underRESTRICTED, otherwise needs approval. - Any permission in
approvalRequiredPermissions, any plugin, or install policyASK→ needs approval (underRESTRICTED, any such reason blocks it). - Otherwise it is installed.
The reasons are shown to the approver.
Where permissions are enforced
For plugins, permissions are enforced by the Node.js permission model on the worker. For skills and MCP servers, they are declarations used for policy and approval; what the agent and servers can actually do is bounded by the worker's controls — project paths, environment allowlist, the agent's permission mode and the OS sandbox.