Access Control

Overview

Access control in Monospace determines what users can see and do within a workspace. It is built on three core building blocks: Roles, Policies, and Entitlements.

Roles

A role is a named grouping that users are assigned to. Roles themselves do not define permissions — instead, they act as containers for one or more policies.

• A user can be assigned to multiple roles
• A role can have multiple policies attached

A user assigned to both "Editor" and "Contributor" receives the policies of both.

Policies

A policy is where permissions are actually defined. Each policy operates in one of two modes:

Admin — Grants unrestricted access to all workspace settings, data, and administrative functions. Turn on the policy's Workspace Administrator switch; no further configuration is needed.

Rules — Fine-grained permission rules across two areas: Collection Permissions and Entitlements.

Collection Permissions

Collection permissions control what a user can do with the data in your collections. For each collection, you can configure access for four CRUD actions:

Each action can be set to one of three states:

• Full Access — The user can perform the action on all items
• No Access — The user cannot perform the action at all
• Custom Access — The user can perform the action only on items matching a filter condition, only on selected fields, or both

Item Permissions

When custom access is configured, you define an item filter that controls which items the user can access. For example, you could allow a user to only update orders that have already been shipped.

Field Permissions

For the create, read, and update actions, you can further restrict which fields a user can access (delete has no field permissions):

• Wildcard Access — The user can access all fields in the collection, including fields added in the future
• Specific Fields — Only the selected fields are accessible

Field-level access can optionally follow the same filter as the item permissions, or have its own custom filter.

Validation Rules

Policies can also include validation rules that enforce data constraints on create and update operations. These rules act as server-side validation filters that items must satisfy before being saved.

Dynamic Filters

Filters can reference the requesting user instead of a fixed value. Write $CURRENT_USER in an item filter, a field filter, or a validation rule, and Monospace substitutes the user's own data when it evaluates the rule. This is how you express ownership — "read only the articles you wrote" — without a separate policy per user.

Monospace resolves the value against the user's record on every request, so a policy stays correct when the user's data changes.

Grant authors access to their own articles by matching the article's author against the current user:

{
  "author": { "id": { "_eq": "$CURRENT_USER" } }
}

Match on the user's email address instead — here, articles whose author has the requesting user's email:

{
  "author": { "email": { "_eq": "$CURRENT_USER.email" } }
}

A filter can also reach data you store about the user yourself. Add a User field to your collection, set it to Single User, and turn on Exclusive — each member is then referenced by at most one item, so the path resolves to a single value.

With an AuthorProfiles collection linked that way and the reverse relation on the user named profile, filter articles by the member's region:

{
  "region": { "_eq": "$CURRENT_USER.profile.region" }
}

Leave Exclusive off and a member can be referenced by many items, so the path is rejected when you save the policy.

In the Studio, choose the current user as a filter value from the value picker rather than typing the variable.

For the full variable syntax, see the Permissions Reference.

Entitlements

Entitlements are system-level permissions that control access to administration features — managing roles, policies, data sources, members, and similar — at both the workspace and organization scope. Some actions can be scoped to a specific resource, such as the ability to assign only certain roles. Workspace entitlements are assigned granularly through policies; organization entitlements are currently conferred by organization-administrator status rather than assigned individually.

Entitlements are separate from collection permissions and independent of one another. An entitlement never controls the data inside your collections — that is governed by collection permissions — and no entitlement is a prerequisite for another. For example, the Data Source → Read entitlement lets a user view a data source's connection configuration; it does not affect whether they can read data in that source's collections.

For the complete catalog of entitlements and what each one controls, see the Permissions Reference.

How Permissions Are Evaluated

When a user makes a request, Monospace resolves their effective permissions by:

1. Collecting all roles the user is assigned to
2. Aggregating every policy across those roles
3. Merging the rules — permissions are additive (a permission granted by any policy is granted to the user), except validation rules, which accumulate: a write must satisfy the validation rules of every policy

If any policy grants admin access, the user has full access. Otherwise, the union of all collection permissions, field permissions, and entitlements determines what the user can do.

Public Role

Every project has one built-in Public role that controls requests made without authentication. Monospace creates this role automatically with no policies attached, so it grants no collection access or workspace entitlements by default.

Configure public access by attaching policies to this role. You do not create additional public roles or assign the Public role to users.

Request Permissions

Public permissions are not automatically added to an authenticated user's permissions. To grant the same access to members, attach the same policy to their roles.

Public Access Rules

Public policies use the same collection permissions and workspace entitlements as policies for authenticated users. A collection contains items, and each item's named values are its fields.

Permissions from multiple attached policies are additive. A restrictive policy does not cancel access granted by another policy. Validation rules are the exception: they accumulate, so a write must satisfy the validation rules of every attached policy.

Public requests have no current user. Do not use $CURRENT_USER in filters or validation rules that must work without authentication.

Configure Public Article Access

For a public blog, grant read access only to published articles and the fields readers need.

To remove public access, detach the policies that grant it or remove their grants. Keep the built-in Public role in place.

See Also

• Authentication — credential sources and authenticated requests
• Permissions Reference — entitlements and built-in role constraints
• Overly Permissive Public Access — avoid unintended public grants