Permissions & abilities

TKP separates two questions that look similar but are answered independently: who runs the workspace, and who can see into a specific library. A third, separate layer governs what a machine credential (an API key or a connected OAuth app) may do on a human's behalf.

Library access is its own membership

Your tenant role (Owner, Admin, Member) does not by itself grant access to any library's contents. Being an Owner means you may run the workspace (invite people, change settings, delete the tenant), not that you may read every document inside it. Access to a specific library is a separate membership, scoped to that library alone, with its own role:

Library role	Grants
Admin	Every library ability, implicitly: read, upload/create resources, update the library, delete resources. Can also manage who else has access to this library.
Member	Exactly the abilities explicitly listed on their membership: any combination of read, create resources, update, delete resources.

When you create a library, you are automatically made its Admin. Otherwise it would be unreachable the moment it existed, since nothing else grants access to it. Beyond that, adding someone else to a tenant does not add them to any library; an existing library Admin adds them explicitly, choosing a role and, for Members, exactly which abilities they need.

This is deliberate: the members list of a library is meant to be the whole truth about who can see it, rather than something you have to cross-reference against tenant roles to understand.

Machine credentials: interfaces and abilities

A Personal Access Token (API key) or a Connected App (OAuth) acts as you, but only within limits you set explicitly when you create it. It never inherits your full access by default. Two things are configured per credential:

Interfaces, which surface the credential may be used with:

Interface	Use
api	The REST API
mcp	The MCP server

Abilities, what it may do, in two scopes:

• Workspace abilities, all-or-nothing across the tenant: create libraries, delete libraries, or, separately, read/create-resources-in/update/delete-resources-in all libraries (including ones created later).
• Per-library abilities, the same four (read, create resources, update, delete resources) granted for one specific library at a time.

A credential can only be granted abilities and library access its owner already holds themselves; you cannot mint a token with more power than your own account has. This is what makes the API key and OAuth setup pages' permission screens look the way they do: the same library/ability picker as everywhere else in the admin panel, scoped down to exactly what the connecting agent needs.