Skip to main content
Applies to:
  • Plan -
  • Deployment -

​
Summary

You cannot remove an organization-level or group-granted permission at the project level. Braintrust permissions are hierarchical and additive. To lock a single project, remove the broad organization-level permission and explicitly allow only the users/groups who need access, or isolate the project in a separate organization.

​
What is happening

Organization-level permissions, including permissions granted through broad groups, apply across all projects in the organization. Project-level settings can add permissions but cannot revoke grants inherited from higher levels. When a user belongs to a broad organization-wide group, such as a group with Read access to all projects, that membership gives access to every project. Editing a single project’s permissions cannot negate that organization-level access.

​
Fix or suggestion

Steps:
  1. Identify the organization-level permission or broad group membership that gives unwanted access. Export the member list for that group.
  2. Create project-scoped groups for each project (or a small set of projects) that should retain access.
  3. Create a test group and migrate a small subset of users there first.
  4. Staged migration:
    • Remove test users from the broad org group.
    • Add them to the project-scoped group(s).
    • Validate access (see validation below).
    • Repeat in larger batches until migration is complete.
  5. Finalize: remove remaining users from the broad org group and add them to appropriate project groups.
Rollback:
  • If access breaks, re-add affected users to the org group to restore previous access quickly, then troubleshoot.
Automation and safety:
  • For large migrations, use the Braintrust API to automate group membership changes. See the API reference for groups and permissions.
  • Export and back up current group memberships before applying changes.
  • Test the workflow on a small set of users first.
  • Apply changes in batches, then verify access before continuing.
  • Use an admin token or service account from a secure host.
Service accounts:
  • Service accounts are useful for least-privilege automation and API access.
  • They do not solve human UI access if users still belong to a broad organization-wide group.
  • To scope automation to one project, create a service account and add it only to permission groups for that project.

​
Option 2: isolate the project in a separate organization

When strict isolation is required and many users or data planes must be segregated:
  1. Create a new organization.
  2. Create the production project(s) inside that organization.
  3. Invite only the users or groups who require access.
  4. Migrate resources or workflows to the new org as needed.
Trade-offs:
  • Stronger isolation with no risk of inherited org grants.
  • Requires managing a second organization (billing, admin overhead, cross-org collaboration complexity).

​
How to confirm it worked

  • Attempt access as a user who previously relied on the broad org grant. They should be denied for the locked project and allowed only on projects where they were added.
  • Verify group membership lists and project ACLs. Confirm audit/log entries for membership changes if available.

​
Notes

  • Use staging and small batches to minimise collateral impact when changing organization-wide group memberships.