DocsAccess Control

Access Management with Roles in Byterover

Byterover’s authorization system is structured around organizations, projects, and roles:

  • Organizations: Serve as the top-level entities containing multiple projects.
  • Projects: Group all data of one project, enabling precise role-based access control (RBAC).
  • Roles: Define user permissions within organizations and projects:
  • Users: are assigned a default role at the organizational level.
  • For finer control, users can be assigned specific roles at the project level, allowing differentiated permissions across projects within the same organization.

API Keys: API keys authenticate access to the Byterover Client. Each key is linked to a specific project, enabling programmatic access to project data. API keys are independent of user accounts.

Roles and Permissions

Byterover defines user roles with specific scopes of access and control:

  • Owner: Full access to all features and settings across the organization and its projects.
  • Admin: Manages project settings and can grant or revoke access for other users.
  • Member: Can view metrics and create scores but lacks permissions to modify project configurations.
  • Viewer: Read-only access to both the project and organization, with most configuration options hidden.
  • None: No default access to the organization; intended for users who only need access to a specific project.

Role Permissions Reference

Permission ScopeOwnerAdminMemberViewerNone
Organization
projects:create✓✓
organization:update✓✓
organization:delete✓
organizationMembers:CUD✓✓
organizationMembers:read✓✓✓
apiKeys:read✓✓✓
apiKeys:CUD✓✓
llmApiKeys:read✓✓✓✓
llmApiKeys:create✓✓✓
llmApiKeys:delete✓✓
Billing:CRUD✓
Project Management
project:read✓✓✓✓
project:update✓✓
project:delete✓
Access Control
projectMembers:read✓✓✓
projectMembers:CUD✓✓
Data Operations
objects:publish✓✓✓
objects:bookmark✓✓✓
objects:tag✓✓✓
note:delete✓✓
Collaboration
comments:CUD✓✓✓
comments:read✓✓✓✓

Key: ✓ = Full access · C = Create · R = Read · U = Update · D = Delete CRUD = Full management rights · Empty = No access Viewer = Read-only access · None = No permissions granted

User Management

Add Organization User

Steps:

  1. Org Settings/Members, Add new member -> enter email -> select role -> click Grant access.

Behavior:

  • User receives email invite

Notes:

  • Roles editable post-invitation

User Management

Modify User Roles

Required permission: members:CUD

Steps:

  1. Org Settings/Members ➔ Select user ➔ Choose role ➔ Save

Behavior:

  • Changes apply globally to all organization projects
  • Can only assign roles ≤ current user’s permissions

Notes:

  • Role hierarchy defined in organization policies

Project Management

Create Project

Required permission: projects:create

Steps: Org Dashboard ➔ New Project ➔ Configure ➔ Create

Behavior:

  • Project resources automatically provisioned
  • Access governed by org roles

Notes:

  • Projects are isolated environments

Project-level roles

Project-level roleshobbyproteam
availability✓

By default, users inherit the role assigned at the organizational level. For greater control, you can assign roles at the project level, allowing you to customize permissions for individual projects within the same organization.

When a project-level role is assigned, it overrides the user’s organization-level role for that specific project.

To restrict a user’s access to only specific projects within an organization, set their organization-level role to None and then assign the appropriate role at the project level.

MCP Server