Policy Resolution
Tool actions are approved only when role capability, tool capability, and plan gates all allow the action.
Effective Permission = Workspace Role Capability AND Entity Capability AND Plan/Feature GateOperation To Gate Mapping
| Operation | Gate |
|---|---|
| Open tool editor | canRead |
| Run tool | canRun |
| Edit prompt and fields | canUpdate |
| Publish or revert | canUpdate |
| Delete tool | canDelete |
| Move tool across scopes | canTransfer |
Role Availability Matrix
| Role | View | Run | Edit/Publish | Delete | Transfer |
|---|---|---|---|---|---|
| Owner | Yes | Yes | Yes | Yes | Yes |
| Admin | Yes | Yes | Yes | Yes | No |
| Contributor | Yes | Yes | Yes | No | No |
| Reader | Yes | Yes | No | No | No |
| Guest | No | Limited | No | No | No |
Note:
Backend authorization is the final gate for all update, delete, and transfer operations.
FAQ
How are tool permissions calculated?+
Tool permissions are evaluated from workspace role capability, tool-level capability, and plan or feature gates.
Q1
Can Contributor delete tools?+
No. Contributor can create and update tools, but cannot delete or transfer them by default.
Q2
Can Reader run tools?+
Yes. Reader can view and run where allowed, but cannot update, delete, or transfer.
Q3
Can Admin transfer tools by default?+
No. Admin can perform most management actions, but transfer remains role-capped unless explicitly granted.
Q4
Why does a blocked action still show in some UI states?+
In rare edge states, a control may render; backend authorization still blocks unauthorized operations.
Q5
Tip:
For cross-entity policy details, see Workspace Permissions Matrix.