Reference

Permissions Reference

Technical reference for Entitlement strings and System/Public roles in Monospace.

Permissions Reference

For a high-level overview of how Roles, Policies, and Entitlements work together in Monospace, please read the Access Control Concepts guide.

Entitlement String Format

Under the hood, an entitlement is evaluated as a granular string that denotes exact capabilities or access scopes over specific pieces of the application.

The entitlement string is formatted generally as: resource:action[:id]

For example:

  • dataModel:edit – Grants permission to edit the data model.
  • role:read:* – Grants permission to read any role.
  • role:assign:509139cf-... – Grants permission to assign a specific role.

Wildcards

Entitlements support the * wildcard at the action and ID levels. For example:

  • dataModel:* gives all data model management permissions.
  • role:read:* grants read access to all roles.

Pre-defined Resources

When configuring policies programmatically or interpreting API errors, these are the primary granular project-level resources evaluated by the system. Note that the string format uses camelCase:

  • dataModel: read, edit
  • projectMembers: add, delete
  • dataSource: create, read:id, delete:id
  • role: create, read:id, assign:id, update:id, delete:id
  • policy: create, read:id, assign:id, update:id, delete:id
  • aiProvider: create, read:id, update:id, delete:id
  • openApiSchema: read

Additionally, organization-level entitlements exist for system-wide operations (e.g., project, orgRole, apiKey, serviceAccount, orgMembers, user, orgSettings, systemOpenApiSchema). These are enforced at the /api/system/ scope.

Note: When granting read or update access with a specific id, it inherently filters endpoints so the user can only interact with that specific item.

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 (i.e., 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 configurations. See Pitfalls for risks regarding misconfigured public roles.
Copyright © 2026