Reference
Permissions Reference
The full catalog of Monospace entitlements, the entitlement string format, and system and public roles.
Permissions Reference
For a high-level overview of how Roles, Policies, and Entitlements work together, read Access Control.
Entitlement String Format
An entitlement is evaluated as a granular string that denotes an exact capability or access scope. It is formatted as:
resource:action[:id]
For example:
dataModel:edit— edit the data model.role:read:*— read any role.role:assign:509139cf-...— assign one specific role.
Wildcards
Entitlements support the * wildcard at the action and id levels:
dataModel:*grants every data model action.role:read:*grants read access to all roles.
When an action is granted with a specific id, it filters the relevant endpoints so the user can act only on that item.
Entitlements are independent: none is a prerequisite for another, and they are separate from collection permissions. An entitlement governs an administrative capability — it never controls the data inside your collections. For example,
dataSource:read lets a user view a data source's connection configuration; it does not affect whether they can read data in that source's collections, which is controlled entirely by collection permissions.Workspace Entitlements
Workspace entitlements are evaluated within a single workspace, and are granted through the policies attached to a member's roles.
| Resource | Actions | Controls |
|---|---|---|
dataModel | read, edit | View the schema (read); create and change collections, fields, and indexes via migrations (edit). |
workspaceMembers | add, delete | Invite and remove workspace members. |
workspaceSettings | read, edit | View and change workspace settings. |
dataSource | create, read:{id}, delete:{id} | Connect, view, and disconnect data sources. read views a source's connection configuration — not the data in its collections. |
role | create, read:{id}, assign:{id}, update:{id}, delete:{id} | Create, view, assign, modify, and delete roles. |
policy | create, read:{id}, assign:{id}, update:{id}, delete:{id} | Create, view, attach, modify, and delete policies. |
ai | access, admin, mcp | Use AI chat (access); configure AI settings and providers (admin); connect to the MCP server (mcp). |
openApiSchema | read | Read the workspace's OpenAPI specification. |
space | read:{id} | View a content space and its pages. |
keyStorage | accessOwn, accessShared | Read and write the member's own (accessOwn) or shared (accessShared) key-value entries. |
Organization Entitlements
Organization entitlements are evaluated across the organization, at the /api/system/ scope.
Organization entitlements are currently conferred by organization-administrator status — an organization admin holds all of them. There is no way to grant an individual organization entitlement to a non-admin today; granular assignment applies to workspace entitlements only.
| Resource | Actions | Controls |
|---|---|---|
workspace | create, update:{id}, delete:{id} | Create, update, and delete workspaces. |
orgRole | assign:{id} | Assign organization roles to members. |
apiKey | create, read, update:{id}, delete:{id} | Create, list, update, and delete API keys. |
serviceAccount | create, read, update:{id}, delete:{id} | Create, list, update, and delete service accounts. |
orgMembers | add, delete | Add and remove organization members. |
user | update:{id} | Update a member's organization-level profile. |
orgSettings | edit | Change organization settings. |
authProvider | create, read, update, delete | Create, view, update, and delete SSO providers. |
auditLog | read | Read the organization audit log. |
systemOpenApiSchema | read | Read the system OpenAPI specification. |
System & Public Roles
- System Execution: Certain operations executed internally by core Monospace logic bypass entitlement constraints natively.
- Public Roles: The API allows unauthenticated access according to what is assigned to any role marked as public (
isPublic: true). Multiple public roles are supported. By default, Monospace ensures new installations do not expose sensitive internal data to public endpoints without explicit opt-in via public role configuration. See Pitfalls for risks regarding misconfigured public roles.