AI Tools Permission Matrix
Role-by-role access model for workspace-owned AI Tools, including editing, publishing, running, deletion, and transfers.
Workspace Role Capability AND Entity Capability AND Plan/Feature GateOperation To Gate Mapping
| Operation | Gate |
|---|---|
| Open tool editor | canRead |
| Run tool | canRun |
| Edit config/prompt/fields | canUpdate |
| Publish/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 |
Frequently Asked Questions
Everything you need to know
How are AI Tool permissions calculated?
Effective permission combines workspace role capability, tool entity capability, and active plan/feature gates.
Can Contributor delete tools?
No. Contributor can create/update and run tools but cannot delete or transfer.
Can Reader run tools?
Yes. Reader can view and run where supported, but cannot edit, publish, delete, or transfer.
Why is transfer blocked for Admin by default?
Transfer is role-capped in the permission model. Admin has broad management rights but transfer remains restricted unless explicitly granted.
What if a button appears but action fails?
Backend authorization is final. In edge UI states, rendered controls may appear, but protected actions still enforce capability checks server-side.
Still have questions?
Contact our support teamNeed cross-entity guidance across all workspace resources?