---
title: "Roles and access policies"
version: "v0.27.0"
canonical: "https://docs.obot.ai/v0.27.0/security/policy-coverage"
unreleased: false
---

# Roles and access policies

Roles determine platform capabilities. Resource policies and profiles determine which resources a caller can use. Review both.

| Control                                                                                                      | What it governs                                  | Important limit                                                           |
| ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------ | ------------------------------------------------------------------------- |
| [User roles](https://docs.obot.ai/v0.27.0/security/policy-coverage.md#obot-doc-user-roles-available-roles)   | Administration, publishing, and audit visibility | Owner/Admin does not automatically include sensitive audit payload access |
| [MCP access policies](https://docs.obot.ai/v0.27.0/mcp-gateway/access.md)                                    | Catalog server access                            | Does not replace shared-vMCP profiles                                     |
| [vMCP profiles](https://docs.obot.ai/v0.27.0/mcp-gateway/access.md#obot-doc-virtual-mcps-tools-and-profiles) | Shared endpoint and tool grants                  | Matching grants are additive                                              |
| [Model policies](https://docs.obot.ai/v0.27.0/functionality/model-access-policies.md)                        | Accessible models                                | A configured provider alone does not grant model access                   |
| [Skill policies](https://docs.obot.ai/v0.27.0/registries/publish-skills.md)                                  | Skill discovery and installation                 | Administrators bypass these grants; downloaded copies remain              |
| [Authorization scopes](https://docs.obot.ai/v0.27.0/functionality/agent-auth-scopes.md)                      | Programmatic credential capabilities             | Cannot exceed the owning user's access                                    |
| [Sentry allowlists](https://docs.obot.ai/v0.27.0/device-management/enforcement.md)                           | Supported local client tool calls                | Experimental; client coverage and fail-closed behavior apply              |

Use a regular test account with the intended group membership to verify grants. Review broadly matching profiles and policies before concluding a narrow rule is ineffective. [User management](https://docs.obot.ai/v0.27.0/security/authentication.md) describes administrative account controls.

Obot uses role-based access control to manage what users can do in the MCP Platform. Each role has different permissions and sees different parts of the interface.

<a id="obot-doc-user-roles-available-roles"></a>

## Available Roles

<a id="obot-doc-user-roles-owner"></a>

### Owner

Full platform management plus the ability to assign the Owner and Auditor roles to users.

<a id="obot-doc-user-roles-admin"></a>

### Admin

Full platform management, including server and model configuration, users, and platform settings. Cannot assign the Owner or Auditor roles.

<a id="obot-doc-user-roles-power-user"></a>

### Power User+

All Power User permissions plus the ability to create MCP Registries and share MCP servers with other users.

<a id="obot-doc-user-roles-power-user-1"></a>

### Power User

All Standard User permissions plus publishing custom MCP servers (personal use only) and viewing Audit Logs and Usage statistics for their activity.

<a id="obot-doc-user-roles-standard-user"></a>

### Standard User

Connect to approved MCP servers and use models granted through access policies.

<a id="obot-doc-user-roles-auditor"></a>

### Auditor

Add-on permission that grants read-only access to sensitive data across the platform. Sensitive data (MCP request/response bodies) can only be viewed by users with this role. All other roles, including Owner, see only metadata for these resources. Can be combined with any other role.

<a id="obot-doc-user-roles-role-comparison"></a>

## Role Comparison

| Capability                           | Standard | Power | Power+ | Admin   | Owner   |
| ------------------------------------ | -------- | ----- | ------ | ------- | ------- |
| Connect to MCP servers               | Yes      | Yes   | Yes    | Yes     | Yes     |
| View Audit Logs                      |          | Yes\* | Yes\*  | Yes\*\* | Yes\*\* |
| View Usage                           |          | Yes\* | Yes\*  | Yes     | Yes     |
| Publish personal MCP servers         |          | Yes   | Yes    | Yes     | Yes     |
| Share MCP servers through registries |          |       | Yes    | Yes     | Yes     |
| Manage Filters                       |          |       |        | Yes     | Yes     |
| Server Scheduling                    |          |       |        | Yes     | Yes     |
| User Management                      |          |       |        | Yes     | Yes     |
| App Preferences                      |          |       |        | Yes     | Yes     |
| Assign Owner/Auditor roles           |          |       |        |         | Yes     |

\* Only for servers they deployed

\*\* Metadata only. Full request/response bodies require the Auditor role. Owners can assign Auditor to themselves, but this is an explicit action to prevent accidental exposure to sensitive data.

<a id="obot-doc-user-roles-security-model"></a>

## Security Model

Obot's MCP hosting platform runs the MCP servers that users add. The **Power User** and **Power User+** roles can publish and deploy MCP servers — including `npx` (npm) and `uvx` (PyPI) packages, and **containerized** servers that run an arbitrary OCI image with a user-supplied command, arguments, and environment. By design, these roles can therefore cause code to execute on Obot's MCP hosting backend.

Treat Power User and Power User+ as **privileged** roles. Grant them only to users you trust to run code on your infrastructure, and harden the hosting backend so that the code those users deploy stays contained:

- **Docker deployments** bind-mount the host Docker socket, so a containerized MCP server runs on the host Docker daemon — effectively host-level access on that machine. Use Docker deployments only for development or single-machine, single-tenant use. See [Docker Deployment](https://docs.obot.ai/v0.27.0/installation/docker-deployment.md).
- **Kubernetes deployments** isolate each MCP server in its own pod. For multi-tenant or untrusted users, keep the restricted Pod Security Admission policy and the MCP NetworkPolicy enabled (both are on by default), and consider a sandboxed container runtime such as gVisor or Kata Containers. See [MCP Deployments in Kubernetes](https://docs.obot.ai/v0.27.0/configuration/mcp-deployments-in-kubernetes.md).

The [default role for new users](https://docs.obot.ai/v0.27.0/security/policy-coverage.md#obot-doc-user-roles-default-role-for-new-users) is configurable. Do not default new users to Power User or Power User+ unless every user who can sign up is trusted to run code on your infrastructure.

<a id="obot-doc-user-roles-managing-user-roles"></a>

## Managing User Roles

<a id="obot-doc-user-roles-updating-a-users-role"></a>

### Updating a User's Role

1. Navigate to **Identity & Access > Users**
2. Click the three vertical dots on the user's current role
3. Click **Update Role**
4. Select the new role

<a id="obot-doc-user-roles-default-role-for-new-users"></a>

### Default Role for New Users

Configure the default role for new users on the **Identity & Access > Roles** page.

<a id="obot-doc-user-roles-pre-assigning-roles"></a>

### Pre-Assigning Roles

To grant admin or owner access to users before they log in, set these environment variables during deployment. See [Enabling Authentication](https://docs.obot.ai/v0.27.0/security/authentication.md) for details.

```bash
OBOT_SERVER_AUTH_ADMIN_EMAILS=admin@example.com,admin2@example.com
OBOT_SERVER_AUTH_OWNER_EMAILS=owner@example.com
```