Permissions
How Ali scopes an MCP connection. The six resources, the three levels, and what changes between a token, an OAuth connection and an agent.
Every connection to Ali carries a set of scopes. A scope is a resource plus a level, and it is the only thing standing between a client and your workspace. The model is deliberately small, because a permission model nobody understands is a permission model nobody uses well.
The six resources
| Resource | Covers |
|---|---|
| Tasks | Tasks, boards, columns, statuses and tags |
| Projects | Projects and their members |
| Customers | Accounts and the notes attached to them |
| Documentations | Documents and the pages inside them |
| Knowledge base | The knowledge base and its search |
| Dashboard | The workspace overview, your tasks and overdue work |
The three levels
No access removes the resource entirely. The client does not get a “permission denied” error, it simply never sees those tools.
Read lets the client list, open and search. Nothing changes in your workspace.
Edit adds create, update, archive and delete on top of read. Grant it only where the client has a job to do.
Dashboard is the exception to the last one. It is a read only surface, so setting it to Edit still results in read access.
Where you set them
The same picker shows up in three places, and they behave slightly differently.
You pick the levels when you create the token, in the New API token drawer. They are fixed for the life of the token: to change them, revoke it and create another one. This is on purpose, since a token that can quietly grow its own access is not much of a boundary.
The client asks for a set of scopes and the consent screen shows them as checkboxes. You approve the subset you are comfortable with. Uncheck everything and the Authorize button turns off, because an empty connection would be useless.
An agent starts read only. A single switch, Let this agent change data, unlocks the Edit column, and a Full access switch sets every resource to write at once. Turning the write switch back off drops every row back to read.
What a connection can never do
A connection acts as the member who created it. That has two consequences worth stating plainly:
- It cannot reach a project, client or document the member cannot reach. Granting Projects, Edit does not widen the member’s own visibility.
- It cannot outlive the member’s access. Remove someone from the workspace and their tokens and connections stop working with them.
Keeping it tight
A few habits that cost nothing and save a lot:
- Give a connection the smallest set it needs, then widen it when something actually fails. Widening takes a minute; explaining an unexpected deletion takes longer.
- Put an expiry on anything that lives on a laptop. Thirty days is a reasonable default.
- Name tokens after where they run, not after what they do. “CI pipeline” tells you where to look when you need to revoke it.
- Read the API tokens and Connected apps tabs every so often. A credential that has never been used, or was last used months ago, is a credential you can revoke today.