> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://help.moveworks.com/llms.txt.
> For full documentation content, see https://help.moveworks.com/llms-full.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://help.moveworks.com/_mcp/server.

# How Permissions Work

> The Relationship-Based Access Control (ReBAC) model Moveworks uses to evaluate file access from your Content Gateway

## Overview

Moveworks evaluates content access using a Relationship-Based Access Control (ReBAC) model. Your gateway provides the identity and access graph; Moveworks resolves whether a specific user can view a specific file at query time.

***

## What your gateway provides

Three sets of records together define access:

| Endpoint                        | Returns                                                                                                             | Used for                                                                    |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
| `GET /files/{id}/permissions`   | Permission entries on a file. Each entry has `{"type": "USER" \| "GROUP", "id": "<external-id>", "action": "VIEW"}` | Who has access to each file                                                 |
| `GET /groups/{groupId}/members` | The **direct** members of a group. Each entry is either a user or a nested sub-group                                | Building the group membership graph                                         |
| `GET /users`                    | User identities                                                                                                     | Resolving identity references from permission entries and group memberships |

The `id` values in permission entries and group memberships are external IDs in your system. They must match the corresponding `id` fields returned by `/users` and `/groups`.

***

## How access is resolved

When evaluating whether a user can view a specific file, Moveworks:

1. Reads the file's permission entries from `/files/{id}/permissions`.
2. For each entry, checks whether the requesting user satisfies it:
   * A `USER` entry matches if the user's external ID equals the entry's `id`.
   * A `GROUP` entry matches if the user is a member of that group, directly or through any chain of nested groups.
3. The user can view the file if at least one permission entry matches.

Group membership traversal is handled entirely by Moveworks. Your `/groups/{groupId}/members` endpoint must return **only the direct members** of each group. Moveworks follows the chain itself. If group A contains group B which contains user U, the response for group A returns `[{"type": "GROUP", "id": "B"}]`, not `[{"type": "USER", "id": "U"}]`.

***

## Wildcards (public content)

To grant access to all users in your organization, return a permission entry of the form `{"type": "GROUP", "id": "*", "action": "VIEW"}`. This specific shape (a `GROUP` type with `*` id) is what Moveworks interprets as "any user." Other variants such as `{"type": "USER", "id": "*"}` will not behave as a wildcard and should not be used.

***

## Supported action

The `action` field on permission entries must be `"VIEW"`. Other action values are not evaluated and will be rejected by the schema validator.

***

## Related

* [Common Pitfalls](/api-reference/content-gateway/common-pitfalls): mistakes to avoid when implementing the permission model
* [Verifying Your Build](/api-reference/content-gateway/verifying-your-build): validate your permission responses with the schema validator