​
Access Management with Roles in Byterover

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

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

API Keys: API keys authenticate access to the Byterover Client. Each key is linked to a specific workspace, enabling programmatic access to workspace 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 workspaces.
  • Admin: Manages workspace settings and can grant or revoke access for other users.
  • Member: Can view metrics and create scores but lacks permissions to modify workspace configurations.
  • Viewer: Read-only access to both the workspace and organization, with most configuration options hidden.
  • None: No default access to the organization; intended for users who only need access to a specific workspace.

​
Role Permissions Reference

Permission ScopeOwnerAdminMemberViewerNone
Organization
workspaces:create✓✓
organization:update✓✓
organization:delete✓
organizationMembers:CUD✓✓
organizationMembers:read✓✓✓
apiKeys:read✓✓✓
apiKeys:CUD✓✓
llmApiKeys:read✓✓✓✓
llmApiKeys:create✓✓✓
llmApiKeys:delete✓✓
Billing:CRUD✓
Workspace Management
workspaces:read✓✓✓✓
workspaces:update✓✓
workspaces:delete✓
Access Control
workspaceMembers:read✓✓✓
workspaceMembers: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 memory workspaces
  • Can only assign roles ≤ current user’s permissions

Notes:

  • Role hierarchy defined in organization policies

​
Memory Workspace Management

​
Create Memory Workspace

Required permission: workspaces:create

Steps: Org Dashboard ➔ New Memory Workspace ➔ Configure ➔ Create

Behavior:

  • Memory workspace resources automatically provisioned
  • Access governed by org roles

Notes:

  • Memory workspaces are isolated environments

​
Memory Workspace-level roles

Memory Workspace-level roleshobbyproteam
availability✓

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

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

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