Are there plans to implement access control at the project level within phoenix? Use case that we have is that there will be sensitive data passing through some of our agents and this should be able to have access control around it. Ideally, this access control can even be driven by Oauth roles. If not, we’ll likely need to have a 1:1 relationship between phoenix deployments + Areas of the business
Currently, Phoenix does not support project-level access control. The platform provides role-based access control (RBAC) at a more general level, allowing for admin and member roles, but it does not extend to granular project-level permissions. According to this GitHub issue, there is interest in more granular access control, but it is not yet implemented.For your use case, you might need to deploy separate instances of Phoenix for different areas of the business to ensure data segregation and access control. Alternatively, you could explore using middleware to implement custom access control based on OAuth roles, as suggested in this GitHub issue.Would you like more detail on how to set up separate instances or implement custom middleware? Sources: - GitHub Issue: Authorization beyond Authentication - this GitHub issue
💡 Hint: Mention RunLLM in the thread for followups.
Hey Ben M. so we have ideas of assigning resource tags to things like projects, datasets, and prompts. That basically would limit the scope of a user's access to certain things. But for now I think thinking of a single phoenix as an area of business and possibly managing access through different oAuth apps is probably the best solution. It will let you right size each phoenix to it's needs as well. So we are thinking about it but right now we are tackling data retention rules and a lot more features for developers. We'll move into enterprise features like fine-grain access control a little more down the line.
