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 | Administration, publishing, and audit visibility | Owner/Admin does not automatically include sensitive audit payload access |
| MCP access policies | Catalog server access | Does not replace shared-vMCP profiles |
| vMCP profiles | Shared endpoint and tool grants | Matching grants are additive |
| Model policies | Accessible models | A configured provider alone does not grant model access |
| Skill policies | Skill discovery and installation | Administrators bypass these grants; downloaded copies remain |
| Authorization scopes | Programmatic credential capabilities | Cannot exceed the owning user's access |
| Sentry allowlists | 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 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.
Available Roles
Owner
Full platform management plus the ability to assign the Owner and Auditor roles to users.
Admin
Full platform management, including server and model configuration, users, and platform settings. Cannot assign the Owner or Auditor roles.
Power User+
All Power User permissions plus the ability to create MCP Registries and share MCP servers with other users.
Power User
All Standard User permissions plus publishing custom MCP servers (personal use only) and viewing Audit Logs and Usage statistics for their activity.
Standard User
Connect to approved MCP servers and use models granted through access policies.
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.
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.
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.
- 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.
The 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.
Managing User Roles
Updating a User's Role
- Navigate to Identity & Access > Users
- Click the three vertical dots on the user's current role
- Click Update Role
- Select the new role
Default Role for New Users
Configure the default role for new users on the Identity & Access > Roles page.
Pre-Assigning Roles
To grant admin or owner access to users before they log in, set these environment variables during deployment. See Enabling Authentication for details.