What an external client can reach
An access token behaves differently on the two surfaces. This distinction should be understood before a token is granted.
Over REST, a token is read-only
Section titled “Over REST, a token is read-only”Every non-GET request made with an access token is refused:
{ "error": "Forbidden", "message": "Access tokens are read-only. Use your account credentials for write operations."}This is a blanket rule rather than a scope check: no scope permits a token to POST over REST.
Writing through the REST API requires account credentials.
Over MCP, a token can write
Section titled “Over MCP, a token can write”Writes are performed over the MCP surface. Of the tools currently published, approximately half are mutating: creating and deleting wiki pages, rows and comments, and creating, updating and archiving workspace deliverables.
These writes are deliberately not gated by an administrative role. Editing a page in one’s own space or moving a task in a workspace one belongs to are ordinary member actions. They are constrained at the point of use by membership, plan, and the same role and mode checks the REST routes apply.
A tool outside the token’s scopes is not listed. It is not presented and then refused; the agent does not see it. An agent’s apparent capabilities therefore correspond exactly to its token’s scopes.
What each permission grants
Section titled “What each permission grants”The token dialog states the reach of each permission:
/a/settings/integrations in the app| Permission | Reaches |
|---|---|
| Read wikis | Pages, databases and rows in your personal wiki, the wikis of organisations you belong to, and the wikis of workspaces you belong to |
| Read workspaces | Members, tasks, activity and health of workspaces you belong to — and only those whose coordinator has switched on external agent access |
| Read knowledge base | Published knowledge-base entries. Reaches no workspace, project or wiki |
| Read projects & reports | Projects you are a member of, including budgets, expenses, impact evidence and full grant reports |
Read projects warrants the most consideration. It does not return a list of project names alone; it includes financial records and impact evidence. An agent granted it can read recorded expenditure and reported outcomes.
Write access is in a separate section of the same dialog, collapsed by default. Read and write are independent: a write permission does not imply the corresponding read.
Every token requires an expiry date. The field is mandatory; permanent tokens are not available.
The reach of an unnarrowed token
Section titled “The reach of an unnarrowed token”A token may be narrowed on four dimensions, which intersect rather than combine:
| Dimension | Limits |
|---|---|
workspaceIds |
Workspace deliverables, and workspace-owned wiki spaces |
orgIds |
Org-owned wiki spaces, and projects (which are org-scoped) |
spaceOwnerTypes |
Which types of space are reachable: personal, org, workspace |
spaceIds |
Individual spaces; the finest granularity |
Each accepts up to 50 entries.
{ spaceOwnerTypes: ['user'] } restricts the token to the personal wiki. { orgIds: [A] } excludes
organisation B’s wiki and B’s project finances. { orgIds: [A], spaceIds: [S] } denotes space S, and
only if it belongs to organisation A — an intersection rather than a union.
Workspace spaces carry a second control
Section titled “Workspace spaces carry a second control”Workspace-owned spaces are additionally subject to the workspace coordinator’s external-access setting, so a coordinator can exclude external agents from a shared space regardless of any member’s token.
Personal and organisation spaces have no equivalent per-space control. Narrowing the token is
the only available restriction, which is the purpose of spaceOwnerTypes and spaceIds.
Something wrong on this page? Report it