Role Based Access Control
Guide to user access control on organization and project levels
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
| Permission | Description | Org Member | Project Member | Project Admin | Org Admin |
|---|---|---|---|---|---|
org.create_project | Create a new project in the organization | ✅ | ✅ | ✅ | ✅ |
project.read | View project data | ❌ | ✅ | ✅ | ✅ |
project.list_users | List users within a project | ❌ | ✅ | ✅ | ✅ |
project.read_api_keys | View project API keys | ❌ | ✅ | ✅ | ✅ |
project.use_ai_secrets | Invoke AI secrets scoped to the project | ❌ | ✅ | ✅ | ✅ |
project.update_user_role | Change a user’s role within the Project | ❌ | ❌ | ✅ | ✅ |
project.invite_user | Invite an external user to the project | ❌ | ❌ | ✅ | ✅ |
project.onboard_user | Add an existing user to this project | ❌ | ❌ | ✅ | ✅ |
project.remove_user | Remove a user from the project | ❌ | ❌ | ✅ | ✅ |
project.update | Update project settings and metadata | ❌ | ❌ | ✅ | ✅ |
project.delete | Delete the project | ❌ | ❌ | ✅ | ✅ |
project.cud_api_keys | Create, update, or delete project API keys | ❌ | ❌ | ✅ | ✅ |
project.crud_ai_secrets | Create, read, update, or delete project AI secrets | ❌ | ❌ | ✅ | ✅ |
org.invite_user | Invite a user to join the organization | ❌ | ❌ | ❌ | ✅ |
org.cud_project_role | Modify any user’s role in any project | ❌ | ❌ | ❌ | ✅ |
org.list_users | List all users in the organization | ❌ | ❌ | ❌ | ✅ |
org.list_projects | List 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:
- Set admins for your pre-existing projects
- Assign Project Admins for each project
- Project Admins can then remove any members who aren’t needed
- 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
- Org Admin invites user to organization
- User becomes Org Member by default
- Project Admin adds user to relevant projects as Project Member
Creating a New Project
- Org Member creates project
- Creator becomes Project Admin automatically
- Project Admin invites other users as needed
Changing Project Leadership
- Current Project Admin promotes another Project Member to Project Admin
- New Project Admin now has full control over the project
- New Project Admin demotes the old admin to a member
Offboarding a Team Member
- Project or Org Admin remove user from their projects
- 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.