AI Assistants Permissions
AI Assistants Permission Matrix
Role-by-role access control for workspace-owned assistants across read, run, update, publish, delete, and transfer operations.
Effective permission formula:
Workspace Role Capability AND Entity Capability AND Plan/Feature GateOperation To Gate Mapping
| Operation | Gate |
|---|---|
| Open assistant editor | canRead |
| Run assistant conversation | canRun |
| Edit config/behavior | canUpdate |
| Publish/Revert | canUpdate |
| Delete assistant | canDelete |
| Move assistant 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 Assistant permissions calculated?
Effective permission is computed from workspace role capability, assistant entity capability, and plan/feature gates.
Can Reader use an Assistant?
Reader can view and run assistants where allowed, but cannot edit, publish, delete, or transfer.
Can Contributor delete assistants?
No. Contributor can build and update assistants but cannot delete or transfer them by default.
Can Admin transfer assistants between scopes?
Not by default. Transfer remains role-capped unless explicitly enabled.
What if permissions seem inconsistent in UI?
Backend authorization is authoritative. Any display-layer mismatch does not bypass protected checks.
Still have questions?
Contact our support teamNeed cross-entity guidance across all workspace resources?