Implementing Granular Access Control in Arize Phoenix

Swapnil J. · 2025-08-15T09:30:14.747Z

Hi Phoenix Community, @RunLLM, I'm currently running a self-hosted instance of Arize Phoenix on Google Cloud Run. I have already enabled authentication (PHOENIX_ENABLE_AUTH, PHOENIX_SECRET) and tried creating new users. I am looking to implement more granular access control. My questions are: 1. Project-Based User Access Control: How can I restrict user access so that member/user can only view or interact with specific projects, rather than having broad access across all projects? 2. Project-Specific API Keys: How to generate API keys that are explicitly scoped to individual projects? I've reviewed the existing documentation on RBAC and API keys, but haven't found explicit details on these project-level control mechanisms. Any insights, examples, or pointers would be greatly appreciated. Thank you!

Implementing Granular Access Control in Arize Phoenix | Arize AI Community

3 comments

· Sorted by Oldest

RunLLM
APP
·
Phoenix’s current RBAC model only supports two roles—admin and member—at the instance level. There is no built-in way to restrict user or API key access to specific projects; all users with access can see all projects, and API keys are not project-scoped. Project-based user access control and project-specific API keys are not supported in the current self-hosted Phoenix release, as confirmed in the documentation and community discussions. Admins can manage users and API keys, but these permissions apply globally, not per project. The only available workaround is to deploy separate Phoenix instances for each project to achieve isolation, but this is not a native feature. For more, see the official RBAC and API key documentation: Access Control (RBAC), Authentication & API Keys, and FAQ on user management.Would you like more detail on possible workarounds or deployment strategies?Sources: - RBAC limitations discussion - Access Control (RBAC) - Authentication & API Keys - FAQ on user management
💡 Hint: Mention RunLLM in the thread for followups.
Mikyo
·
Good Morning. The bot is correct above in that a single phoenix will not give you resource level access control inside of phoenix outside of roles for administration vs developers. This is somewhat by design as Phoenix is very much designed for teams to collaborate on a shared set of applications. We may in the future add resource controls but currently we do not. You can accomplish what you are trying to do by deploying two phoenix instances talking to the same DB (via different schemas). We like this approach because the data is fully isolated and so are the users and API keys. This way the access control is fully isolated across the two. Appreciate the feedback. Please file us an issue with regards to what type of access control you are looking for. Looking forward.
❤️1
Swapnil J.
·
Thank you so much Mikyo, I am so happy to receive a response from you. I will try out the your suggestion and add the issue too. I have watched numerous of your videos. And I love the work you and the team are doing. Thank you so much for such a wonderful product!
1

RunLLM
APP
·
Phoenix’s current RBAC model only supports two roles—admin and member—at the instance level. There is no built-in way to restrict user or API key access to specific projects; all users with access can see all projects, and API keys are not project-scoped. Project-based user access control and project-specific API keys are not supported in the current self-hosted Phoenix release, as confirmed in the documentation and community discussions. Admins can manage users and API keys, but these permissions apply globally, not per project. The only available workaround is to deploy separate Phoenix instances for each project to achieve isolation, but this is not a native feature. For more, see the official RBAC and API key documentation: Access Control (RBAC), Authentication & API Keys, and FAQ on user management.Would you like more detail on possible workarounds or deployment strategies?Sources: - RBAC limitations discussion - Access Control (RBAC) - Authentication & API Keys - FAQ on user management
💡 Hint: Mention RunLLM in the thread for followups.
Mikyo
·
Good Morning. The bot is correct above in that a single phoenix will not give you resource level access control inside of phoenix outside of roles for administration vs developers. This is somewhat by design as Phoenix is very much designed for teams to collaborate on a shared set of applications. We may in the future add resource controls but currently we do not. You can accomplish what you are trying to do by deploying two phoenix instances talking to the same DB (via different schemas). We like this approach because the data is fully isolated and so are the users and API keys. This way the access control is fully isolated across the two. Appreciate the feedback. Please file us an issue with regards to what type of access control you are looking for. Looking forward.
❤️1
Swapnil J.
·
Thank you so much Mikyo, I am so happy to receive a response from you. I will try out the your suggestion and add the issue too. I have watched numerous of your videos. And I love the work you and the team are doing. Thank you so much for such a wonderful product!
1