RBAC in HoneyHive allows you to set up distinct organization and project-level roles with specific permissions. This simplifies permission management across multiple projects and improves delegation of administrative tasks.

​
Key Benefits

  • Enhanced Token Security: Limit API key access based on precise project needs
  • Granular Control: Define roles for each team member within projects
  • Clear Hierarchy: Transparent permission structure across your organization
  • Flexible Team Management: Easier onboarding and role changes

​
Role Hierarchy Overview

Our new RBAC system is built around a clear hierarchy that separates organizational from project-level permissions.

​
Permission Scope

Permissions are now scoped to specific contexts:
  • Organization-level permissions: Apply across the entire organization
  • Project-level permissions: Apply only within specific projects
This clear separation ensures that project administrators have full control over their projects without necessarily having administrative access to the entire organization.

​
Roles

Org Admin > Project Admin > Project User > Org User Each role inherits permissions from roles below it in the hierarchy, with additional capabilities added at each level.

​
Roles & Permission Sets

PermissionDescriptionOrg MemberProject MemberProject AdminOrg Admin
org.create_projectCreate a new project in the organization✅✅✅✅
project.readView project data❌✅✅✅
project.list_usersList users within a project❌✅✅✅
project.read_api_keysView project API keys❌✅✅✅
project.use_ai_secretsInvoke AI secrets scoped to the project❌✅✅✅
project.update_user_roleChange a user’s role within the Project❌❌✅✅
project.invite_userInvite an external user to the project❌❌✅✅
project.onboard_userAdd an existing user to this project❌❌✅✅
project.remove_userRemove a user from the project❌❌✅✅
project.updateUpdate project settings and metadata❌❌✅✅
project.deleteDelete the project❌❌✅✅
project.cud_api_keysCreate, update, or delete project API keys❌❌✅✅
project.crud_ai_secretsCreate, read, update, or delete project AI secrets❌❌✅✅
org.invite_userInvite a user to join the organization❌❌❌✅
org.cud_project_roleModify any user’s role in any project❌❌❌✅
org.list_usersList all users in the organization❌❌❌✅
org.list_projectsList all projects in the organization❌❌❌✅

​
Role Transitions & Management

The transition between roles follows specific rules to ensure proper access control.

​
Organization Role Changes

  • An Org Admin can demote themselves to an Org Member, but only if they first promote another user to Org Admin
  • Only an Org Admin can promote an Org Member to become an Org Admin
  • Org Members cannot change their own role

​
Project Role Changes

  • A Project Admin can promote any Project Member to become a Project Admin
  • A Project Admin can demote another Project Admin to a Project Member
  • An Org Admin can change any user’s project role
  • Project Members cannot change their own role

​
Migration Guide

​
SDK Migration

Most critical update is to migrate the API keys to the new project-specific keys that can be found in the Settings page. Once you have made the update, you can revoke access to the old keys from the UI itself.

​
User Role Migration

All pre-existing users are going to automatically be set to Organization Admins. To smoothly transition to the new system:
  1. Set admins for your pre-existing projects
    • Assign Project Admins for each project
    • Project Admins can then remove any members who aren’t needed
  2. Demote users who don’t need to be admins
    • Demote the remaining users to Org Member & Project Member where relevant

​
Common Scenarios

​
Adding a New Team Member

  1. Org Admin invites user to organization
  2. User becomes Org Member by default
  3. Project Admin adds user to relevant projects as Project Member

​
Creating a New Project

  1. Org Member creates project
  2. Creator becomes Project Admin automatically
  3. Project Admin invites other users as needed

​
Changing Project Leadership

  1. Current Project Admin promotes another Project Member to Project Admin
  2. New Project Admin now has full control over the project
  3. New Project Admin demotes the old admin to a member

​
Offboarding a Team Member

  1. Project or Org Admin remove user from their projects
  2. Org Admin removes user from organization if they’re leaving entirely

​
FAQ

Q: What happens to existing permissions during this transition? A: Existing users will be mapped to Organization Admin by default. Q: Can a user have different roles in different projects? A: Yes! A user can be a Project Admin in one project and a Project Member in another, allowing for flexible team structures. Q: What if all Org Admins leave the company? A: An Org Admin must designate a replacement before demoting themselves. If this doesn’t happen, contact HoneyHive Support for assistance. Q: Can Org Admins access every project? A: Org admins cannot access data within a project, unless they’re invited to the project. An org admin only has administration access for projects, enabling them to delete project and manage project users. Q: Can Project Admins see other projects in the organization? A: Project Admins only have administrative access to their assigned projects. They can see other projects they’re members of but don’t have admin rights to them unless explicitly granted. Q: Who can create API keys? A: Project Admins and Org Admins can create and manage API keys for projects. Project Members can use but not create or modify them. Q: Can permissions be customized beyond the defined roles? A: Currently, permissions are tied to roles. For specialized access needs, contact HoneyHive Support to discuss your requirements.