I've seen more than one team barrel into OpenPipe, fire up a fine-tuning project, and immediately step on a rake because they gave everyone admin access. Don't be that team. The platform's access controls are actually quite granular, but you have to configure them deliberately. It's not a "set and forget" thing, especially in a B2B context where you might have data engineers, ML researchers, and product managers all needing different levels of access. Here's the breakdown of how we structured it after our first… let's call it a "learning experience."
First, map your actual organizational roles to OpenPipe's permission tiers. The key levels are Owner, Admin, Member, and Read-Only. The pitfall is thinking "Admin" is just for tech leads. In our failed first pass, we made all engineers Admins, which meant they could delete production fine-tuned models or alter billing. Bad idea.
We now use a matrix that looks like this:
* **Owner (CTO/Head of AI):** Full system access, including billing and deletion.
* **Admin (Senior ML Engineer):** Can create projects, manage models, invite users (but NOT to Owner), and run training jobs. Cannot delete the organization or alter billing.
* **Member (Data Engineer, Product Manager):** Can submit data for training, trigger inference on existing models, and view results. Cannot create new projects or manage user access.
* **Read-Only (Stakeholders, Ops):** Can view model performance, cost reports, and logs. No write actions.
The actual setup is done via the Organization Settings > Members page. You invite by email and assign a role. The critical step is **project-level permissions**. Just because someone is an Org-level "Member" doesn't mean they should see every project. We have a "finance-llm" project that our product team has no business accessing.
You achieve this by going into a specific Project's Settings. Here, you can override the org-level permissions. This is the YAML we use as a template for our project-level `permissions` structure. We version-control this.
```yaml
project: customer-support-finetune
permissions_overrides:
- user_email: data-engineer@company.com
project_role: admin # Can manage datasets and runs within *this* project only
- user_email: pm@company.com
project_role: member # Can only submit prompts and view results
- user_email: contractor@external.com
project_role: read_only # No direct access, added for specific reporting
```
The final and most important lesson: **Audit logs are your friend.** Go to **Activity Log** in the Organization Settings and *schedule a weekly review*. Look for permission changes, model deletions, and large training job triggers. This caught a mistaken scope creep by a well-meaning junior dev last month who was about to train a model on the wrong dataset. The cost of that mistake would have been in the thousands.
OpenPipe gives you the tools to build a secure, operational workflow. Use them from day one. Trying to retrofit permissions after a model is corrupted or data is leaked is a painful and expensive migration you don't want to undertake.
—BW
Migrate once, test twice.