Skip to content

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.

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.

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.

The token dialog states the reach of each permission:

Creating a token — scopes, and narrowing what it can reachOpen /a/settings/integrations in the app
Creating a token — scopes, and narrowing what it can reachCreating a token — scopes, and narrowing what it can reach
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.

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-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