Workspace Permissions
Workspace permissions control who can see, use, edit, and manage every resource in your Assist workspace — subagents, sandcastles, tools, projects, connections, and knowledge bases. Permissions work through a combination of ownership, direct grants, and group membership, so you can set access once at the group level and have it apply to everyone in the group.
Who can manage permissions
- Workspace admins can manage all permissions, users, groups, and resources.
- Resource owners (the person who created a resource) have full admin access to that resource and can grant others access to it.
- Regular members can see and use resources shared with them, but cannot manage permissions on resources they don't own.
Permission levels
Every resource supports four levels, each one including everything the level below it grants:
| Level | What it allows |
|---|---|
| View | See the resource and read its contents. |
| Execute | Use the resource interactively — run a subagent, use a sandcastle, invoke a tool. |
| Edit | Modify the resource — change a subagent's prompt, edit a sandcastle's code, update a tool. |
| Admin | Everything Edit allows, plus manage who else has access and delete the resource. |
Admin includes Edit. Edit includes Execute. Execute includes View.
Three sources of access
A user can gain access to a resource through any of three paths:
- Ownership. The person who created the resource has implicit Admin access. This never needs to be granted — it is automatic.
- Direct grant. A workspace admin or the resource's owner explicitly grants a user a permission level on a specific resource.
- Group membership. A group is granted a permission level on a resource. Every member of that group inherits that access.
If a user has access through multiple paths (for example, direct Edit plus group Admin), the highest level wins.
Resource types
Permissions apply to these resource types:
- Subagents
- Sandcastles (and their state collections)
- Tools
- Projects
- Connections (OAuth and API credentials)
- Knowledge bases (document containers)
- Chats
- MCP bundles (MCP servers)
How it works under the hood
Assist uses a relationship-based access control system. Permissions are stored as tuples — "user X has role Y on resource Z" — and pre-computed into an effective permissions table for fast lookups. Every time you grant, revoke, or change a permission, the effective table is updated. RLS policies on every table check the effective permissions, so the enforcement is in the database layer, not just the UI.
This means permissions are consistent everywhere: the API, the UI, scheduled runs, and channel-routed messages all respect the same rules.
Related guides
- Managing users — view users and their access.
- Managing groups — create groups and assign members.
- Managing resource permissions — grant and revoke access to specific resources.
- Using the permissions simulator — test "can user X do Y on resource Z?"
- Setting up SSO — single sign-on and directory sync.
- Troubleshooting