AI and Agent Permissions
Configure AI and Agent Permissions using global user roles to control feature access like AI chat, agent creation, and library sharing.
AI permissions are part of global user roles. They determine which features a user can access in the AI area.
For agents, there's an additional distinction between agent access and access to context. To run an agent in a task or project, you need both permissions.
Important: An agent is not a user. It doesn't have its own awork role and no permissions of its own. Every run is executed on behalf of a responsible user.
What AI permissions are there?
No Access
If No Access is enabled for a general permission role, users can't use the AI chat or agents. The AI menu item won't show in the main menu, and the AI chat sidebar can't be opened via Cmd/Ctrl + I.
These users can still be part of the AI subscription. This setting affects access, not billing.
Use AI & Agents - without sharing
This is the default setting.
Users can:
- Use AI
- Use agents
- Create their own agents
- Create their own skills
Your own agents and skills cannot be shared with the Workspace Library.
Use AI & Agents - share in Library
Users can share agents and skills with the Workspace Library in addition to the default setting.
Access rights for agents
For agents, there are the following permissions: None, Read and use, and Manage.
None
Users can't find, open, configure, or run the agent.
Historical agent activity and context-related threads can still be visible if the user has read access to the respective task or project context.
Read and Use
With Read and use, the user can:
- Open the agent and view details
- Run the agent, if you also have write access to the specific task or project context
- Use linked skills, including private agent skills
- Use linked connectors, as long as the responsible user's connection is available
Read permissions don't allow changes to the agent configuration.
Manage
Manage includes all read permissions and additionally allows you to edit the agent and change its settings or sharing.
This includes configuration, versions, avatar, sharing, memory, skills, connectors, workflows, schedules, and archive status.
How are agent permissions assigned?
An agent can be shared with the entire workspace, teams, or individual users.
- Creator and workspace admins: Always have permission to manage the agent
- Multiple shares: The highest permission applies
- New agents: Are initially only accessible to the creator and workspace admins
- No additional permission: Read allows use of the agent
What permission do I need?
| Action | Required Permission |
|---|---|
| Create agent | Authorized internal workspace user with agent access |
| Open agent | Agent read and use |
| Edit or share agent | Agent manage |
| Start standalone thread | Agent read and use |
| Run agent in task or project | Agent read and use + write access to the specific context |
| Mention agent in comment | Agent read and use + write access to the commented context |
| Read existing task/project thread | Read access to the specific context |
| Continue task/project thread | Agent read and use + write access to the specific context |
| Cancel context-related run | Write access to the specific context |
| Cancel standalone run | Creator only |
| See agent activity and run history | Read access to the task/project context |
| Create, edit, delete, or manually start schedule | Agent manage + required access to the selected context |
AI thread permissions at project level and agent activity
AI threads are private to their creator, unless they're linked to a project. Even workspace admins don't get access to other users' AI threads this way.
For projects, there's an additional permission for AI Threads.
It determines whether users can see AI threads linked to a project.
There are two levels:
- Read access
- No access
There's no separate edit permission for AI threads.
Agent activity shows agent involvement in tasks and projects. It doesn't grant permissions by itself and doesn't make an agent a task member or project member.
When a thread is deleted, involvement and run history are preserved. A later run creates a new thread if no available thread exists anymore.
Adjust permission levels for AI & Agents
Admin permissions are required.
-
Open Settings (gear icon in the bottom left of the main menu).
-
Navigate to the Admin category and select Rights Management.
-
Open the General Permission Role
-
Scroll to the AI Permissions section. There you'll find the permission for awork Agent & Custom Agents with a dropdown selection field on the right side of the row.
-
Open the permissions dropdown
Click on the dropdown field next to awork Agent & Custom Agents. The field shows the currently selected permission level and contains a small arrow icon indicating more options. -
Select permission level
In the opened dropdown menu with the title Permission Level, you have three options:- No Access: Users have no access to AI features and can't use the awork Agent or custom agents.
- Use AI & Agents - without sharing: Users can use the awork Agent and custom agents, but can't share them with others.
- Use AI & Agents - share in Library: Users can use the awork Agent and custom agents and additionally share them in the Library with others.
-
Select your desired option
Click on the permission level you want to set for your users. The selected option is applied immediately and displayed in the dropdown field.
AI permissions are now configured for the user role. The changes take effect immediately for all users with this role.
Who is the responsible user?
Every agent run has a responsible user. Their awork permissions, personal skills, and personal connector connections are used for the run.
- Direct run or follow-up: The user who selects Run agent or sends the message is responsible.
- Agent mention in comment: The user who adds the agent mention is responsible.
- Automatic schedule: The responsible user of the schedule remains responsible.
- Run schedule now: The schedule owner remains responsible. The user who selects Run now is additionally recorded as the triggering user.
- Delegated or sub-agent run: The run takes over the responsible and triggering user of the parent run.
When a user saves or edits a schedule, they become responsible for future runs.
Important: If the required permissions are missing, the user is inactive, or the permission can't be verified, the run is rejected or stops at the next protected boundary.
Permissions during an agent run
A central principle is: An agent doesn't get more permissions than the user it's acting on behalf of.
An agent has no permissions of its own. The agent always acts on behalf of the user. If a user isn't allowed to perform a certain action in awork, their agent can't do it either.
Every run is executed on behalf of a responsible user who starts it. The agent can therefore only perform actions that this user is authorized to do.
This means: If you don't have permission to edit a task or project, the agent can't make changes there either. In this case, the agent is limited to read access.
This applies to:
-
Agent runs in projects
-
Agent runs in tasks
-
Scheduled agent runs
-
Agent runs via automations
For a scheduled run or automation, the agent uses the permissions of the user who set up the run.
Only this user can edit the schedule. Other users may be able to access or delete the run depending on their permissions, but they can't automatically change its instructions.
Important: Existing sharing and approval rules still apply. Agents don't bypass permissions or approvals.
In short: If you have access to a task or project, you can also start an agent run for it. Changes are only possible if you have the corresponding edit rights.
Even without edit rights, an agent run can be helpful, for example for a health check, a summary, or a quick translation.
The same principle applies to connectors. If a user connects their Google account, for example, an agent can only perform actions with that connection that are also possible through that Google account.
When an agent is shared with another user, the agent uses that user's own connected accounts and permissions.
An exception is when you intentionally embed a specific account or credentials directly in an agent.
Permissions for general AI settings
Different permissions are required to manage AI settings:
- Models and workspace context:
Access to Workspace Settings and at least the permission level Use AI & Agents - without sharing in the AI Permissions of the general permission role - Usage & activity: Admin rights
- Library: at least the permission level Use AI & Agents - without sharing in the AI Permissions of the general permission role
What permissions apply to external users?
External users don't have access to the AI thread list of a project.
In such a project, they can:
- Not see the project's AI tab
- Not assign agents in the project
- Not mention an agent in a comment
- Not link their own AI thread with the project
They can still use AI in their own workspace and use a project as context if they have the appropriate rights.
An AI thread that an external user creates in their own workspace stays there and is charged to their own quota. It can't be transferred to another workspace's project.
FAQ
Is agent read permission enough to start an agent in a task?
No. You also need write access to the specific task or project context.
Does an agent have its own awork permissions?
No. An agent doesn't have its own awork role. Every run uses the permissions of the responsible human user.
Can workspace admins read other users' standalone threads?
No. Admin rights don't override the privacy of a standalone thread.
What happens if the responsible user no longer has permission?
The run is rejected or stops at the next protected boundary.
Powered by happysupport.ai