Roles and Permissions
Two kinds of AI agent permissions apply in NocoDB. The project role of a member sets what that member can do with agents. The project role of the agent sets what the agent can do in the project. Roles and permissions explains the project roles.
What members can do
| Action | Minimum project role |
|---|---|
| See the agents of a project and open them | Viewer |
| Chat with an agent | Viewer |
| See the automatic runs of an agent | Viewer |
| Open the agent settings, read-only | Viewer |
| Create an agent | Creator |
| Change instructions, files, access, triggers, channels and skills | Creator |
| Turn an agent on or off | Creator |
| Rename, duplicate, move and delete an agent | Creator |
The setup chat of a draft agent belongs to the person who started the draft. Only that person can use it, and only while they have the Creator role or higher.
What members can do with coding agents
| Action | Minimum project role |
|---|---|
| See the repositories and machines of a coding agent | Editor |
| Start, open and watch coding sessions | Editor |
| Chat, use the terminal and edit files in a session | The person who started the session |
| Archive or delete any session | Creator |
| Add and remove repositories, and change the code settings | Creator |
| Create, change, build and delete machines, and their environment and secrets | Creator |
A coding session that a trigger started has no owner. Members with the Editor role or higher can watch it.
AI agent permissions and guardrails
AI agent permissions in NocoDB start with the project role of the agent. Every agent holds a role in its project: Viewer, Commenter or Editor. An agent cannot be a Creator or an Owner, so it cannot change the tables, fields or settings of the project.
| Agent role | What the agent can do with records |
|---|---|
| Viewer | Read records. |
| Commenter | Read records. |
| Editor | Read, create, change, link and delete records, when Tables and records is set to Edit. |
To change the role of an agent, see The project role of an agent.
Table permissions, field permissions and record-level security policies apply to agents as they do to members.
The role when a person starts the run
When a person starts a run, the agent acts with the lower of two roles: its own role, or the role of that person. The rule applies to a chat. The rule also applies to a trigger that a member fires, for example with a record change or a webhook call with their API token. A Viewer cannot use an agent to change records that the Viewer cannot change.
The role in a scheduled run
A scheduled run has no person behind it, so the agent acts with its own role. Give an agent that runs on its own only the role and the access that its job needs.
Should an AI agent have its own identity?
A NocoDB AI agent has its own identity, not the identity of the person who created it. NocoDB applies the same guardrails to the agent as to a member:
- The agent holds its own project role: Viewer, Commenter or Editor.
- Table permissions, field permissions and record-level security policies apply to the agent.
- Records that the agent creates or changes show the agent as the author, in the record history and the audit log.
With its own identity, an agent gets only the access that you give it, and you can see the changes that it made. See Security.
API tokens
An API token reaches agents through the Agents category: "Manage agents, sessions, channels, and messages". To call a webhook trigger, the token needs Read & write access to Agents.
Related
Last updated on