> AI agents: this is one page from Mammoth Analytics documentation. The index of all pages as Markdown is https://docs.mammoth.io/llms.txt. Append `.md` to any docs URL, or send `Accept: text/markdown`, to get Markdown.

# Access control

> The complete roles and permissions matrix for Mammoth workspace, project, and dashboard roles, plus how access control is enforced.

This page is for security reviewers, IT administrators, and Workspace Owners. Start with the [roles and permissions matrix](#roles-and-permissions-matrix) for the permission tables.

Mammoth enforces access control at two levels: **Workspace** and **Project**. Workspace roles govern administrative capabilities across the entire tenant. Project roles govern what a user can do with data, pipelines, and connectors inside a specific project. A user can hold a different project role in each project they belong to.

Mammoth checks the required permission for every request before the operation proceeds.

## How requests are authenticated

Authorization depends on who made the request. Mammoth supports two authentication methods; see [Sign-in and authentication](https://docs.mammoth.io/learn/security-overview/authentication/) for setup.

### User sessions (JWT)

User sessions are authenticated with a signed token that Mammoth validates on every request. Each request is scoped to a single workspace through the `X-WORKSPACE-ID` header.

CSRF protection is enforced for all browser sessions: an anti-CSRF token is validated on state-mutating requests. API token sessions are excluded from CSRF checks.

### API tokens

Programmatic access uses an API token sent as `Authorization: Bearer mm_...`. The token belongs to one workspace, so no workspace header is needed. The token is shown once when it's created and can't be retrieved afterward. The older `X-API-KEY` / `X-API-SECRET` headers are deprecated. See [API authentication](https://docs.mammoth.io/build/auth) for details.

An API token can optionally be scoped to a single project. When scoped, the token can't access any other project within the workspace, and Mammoth enforces this before any resource operation proceeds.

## Roles and permissions matrix

This is the complete reference for what each role can do. Other pages summarize roles and link here. In the product, open **View Roles & Permissions** at the bottom of any project role dropdown in the user side panel to see the same permissions in a modal with **Workspace Permissions** and **Project Permissions** tabs.

### Roles at a glance

| Level | Role (as shown in the UI) | Scope |
| --- | --- | --- |
| Workspace | Workspace Owner | The whole workspace. A workspace can have more than one Owner. |
| Workspace | Workspace Member | The workspace. Project access requires being added to each project. |
| Project | Project Admin | One project. A user can hold a different role in each project. |
| Project | Project Editor | One project. |
| Dashboard | Dashboard Editor | One dashboard. |
| Dashboard | Dashboard Viewer | One dashboard. |

### Workspace roles

Workspace roles are assigned by a Workspace Owner and apply across the entire workspace.

| Capability | Workspace Owner | Workspace Member |
| --- | --- | --- |
| **Workspace settings** |  |  |
| Rename or delete the workspace | Yes | No |
| Enable or disable upcoming features | Yes | No |
| **User management** |  |  |
| Invite users to the workspace | Yes | No |
| Modify or remove workspace users | Yes | No |
| **Projects** |  |  |
| View all project names (without needing access) | Yes | No |
| Assign users to projects they're not already in | Yes | No |
| Create a new project | Yes | Yes |
| Delete any project (including ones they don't belong to) | Yes | No |
| **API keys** |  |  |
| Manage workspace API tokens | Yes | No |
| Manage external service API keys | Yes | No |
| **Billing** |  |  |
| Manage subscription and payment settings, update the plan | Yes | No |
| **Activity log** |  |  |
| View the workspace Activity Log | Yes | Yes |

### Project roles

Project roles are assigned per project. A Workspace Member must be explicitly added to a project to access it. Membership in the workspace alone does not grant project access.

| Capability | Project Admin | Project Editor |
| --- | --- | --- |
| **Project settings** |  |  |
| Edit project settings | Yes | No |
| Delete the project | Yes | No |
| **User management** |  |  |
| Add workspace members to the project | Yes | No |
| Invite external users to the project | Yes | No |
| Remove users from the project | Yes | No |
| **Data Library** |  |  |
| Create, edit, and delete datasets, views, and pipelines | Yes | Yes |
| View Data Library items | Yes | Yes |
| **Live Connections** |  |  |
| Create, update, or delete Live Connections | Yes | No |
| Create or modify queries from Live Connections | Yes | Yes |
| View Live Connections and their queries | Yes | Yes |

### Dashboard roles

Dashboards have their own sharing model, set in the **Publish & Share** panel of the dashboard.

| Capability | Dashboard Editor | Dashboard Viewer |
| --- | --- | --- |
| Modify the dashboard | Yes | No |
| View the dashboard | Yes | Yes |

Editors of a dashboard must have access to the same project as the dashboard. See [Publishing and sharing dashboards](https://docs.mammoth.io/learn/dashboard/share-dashboard/) for the steps.

Row-level security for dashboards is a plan feature, included on the Pro plan. Whether your workspace has it depends on your plan.

## Authorization enforcement

Every request passes two checks before it reaches application logic:

1. **Authentication**: Mammoth validates the session token or API token and establishes the user, workspace, and session type.
2. **Authorization**: Mammoth checks the required permission against the user's role on the target resource. If the check fails, the request is rejected.

Authorization also validates resource hierarchy—for example, confirming that the project referenced in a request actually belongs to the workspace in the request context. A user cannot reference a resource from a different workspace, even if they know its ID.


## Workspace isolation

Workspaces are the primary tenant boundary.

**Database level:** Every major resource (projects, datasets, views, pipelines, connectors, invitations, API keys) belongs to one workspace. Lookups are scoped to the workspace, so a query cannot return another workspace's data.

**Session level:** Each request carries a single workspace context. Mammoth verifies that it matches the workspace referenced in the request. A user cannot act on behalf of a workspace they do not belong to.

**API key level:** Each API key is bound to a single workspace at creation time. The workspace ID is validated on every API-key-authenticated request.

Users can belong to multiple workspaces. Each workspace membership is represented by a separate role record; roles in one workspace have no effect in another.

## Project isolation

Within a workspace, projects provide a second isolation boundary.

- Datasets, views, pipelines, and Live Connections belong to exactly one project.
- Workspace Members must be explicitly assigned to a project to access it.
- Workspace Owners can view all project names, delete any project, and assign users to projects they're not part of.
- Mammoth checks both workspace membership and project role before granting access to project-scoped resources.
- Live Connections are project-scoped. The same physical database can have separate connections in two different projects, and each connection is independently credentialed—users in one project cannot use or discover connections belonging to another project.

## External users

External users are individuals whose email domains are not part of the organization's workspace.

**Invitation paths:**

- A **Workspace Owner** can invite external users to the workspace via Workspace Settings. Once in the workspace, they can be assigned to projects.
- A **Project Admin** can invite external users directly to a project via project user management.

Invited users receive an email with an activation link. Until they accept, they exist only as a pending invitation record. Role and project assignments are stored with the invitation and applied upon acceptance.

External users operate under the same role model (Workspace Member, Project Admin, Project Editor) as internal users. There are no special permissions or restrictions unique to external status beyond the invitation workflow. Pending invitations can be revoked before acceptance; active workspace access is removed by the Workspace Owner.

## Activity log

The Activity Log records workspace and project actions such as invitations, removals, renames, and pipeline changes, each with a timestamp, the author, and the affected resource. Workspace Owners and Workspace Members can view it; project roles don't affect access. How far back it reaches depends on your plan. See [Audit logs](https://docs.mammoth.io/learn/security-overview/audit-logs/).

## Role assignment and removal

**Adding users:**\
When inviting a new user, the Workspace Owner specifies the workspace role (Member) and can optionally assign them to one or more projects with a designated project role.

**Changing roles:**\
Workspace role changes (Owner ↔ Member) and project role changes (Admin ↔ Editor) take effect immediately. There is no grace period or deferred propagation.

**Removing users:**\
Removing a user from the workspace removes their workspace and project role assignments. The user's account is not deleted—if they belong to other workspaces, those memberships are unaffected. Project Admins can remove users from their project without affecting workspace membership.

## Best practices

- **Workspace Owner access** should be limited to the individuals responsible for billing and workspace administration. A workspace can have more than one Owner, so keep the number small.
- **Default to Project Editor** for new members. Elevate to Project Admin only when the user needs to manage project membership or Live Connections.
- **Remove users promptly.** Removing a user from the workspace revokes all project access simultaneously.
- **Scope API keys.** When issuing API keys for integrations or pipelines targeting a specific project, set the project scope on the key to prevent access to other projects in the workspace.
- **Review access periodically.** Use Workspace Settings, then User Management, to audit who belongs to which projects and in what role. Cross-reference against current team structure.

---
Source: https://docs.mammoth.io/learn/security-overview/access-control.md · Updated: 2026-10-13