Mintplex-Labs
[FEAT]: Fine-Grained Access controls
What would you like to see?
As an administrator on an AnythingLLM instance I should be able to:
- Create new roles that are based on RBAC elements on a model/action permission set.
- Apply these roles to current and existing users
dev note: To prevent disruption of existing user based we need to alias all the current roles to some pre-defined set of conditions so that access levels do not change user permissions post-merge.
Hi @timothycarambat
Just want to understand the exact change that has been implemented in this patch to modify the access control.
I re-installed but didn’t see any workspace level change, as a manager I can still view all the workspaces along with the documents uploaded across all workspaces, Idea was to have workspace level manager/super-user access. Even while adding a new user, I still see the old roles(_Default, Manager, Admin). In short I didn't notice any change at all, am I doing something wrong, I used the docker installation to pull the latest image
Linux Installation ~ AnythingLLM (useanything.com)
@rpaGuyai The issues were moved into one larger issue since they all have to do with the same thing. It is much easier to track one issue than 8-10 separate issues that all are asking the same thing. This issue remains open, so the feature is still in request and has not been completed.
YES! We really need this ASAP! Thanks guys, this would be huge for our use case.
We really need this +1, The features and functionality provided have significantly benefited our team(at least default user can upload their doc into workspace), and we're grateful for the effort and dedication you've put into maintaining and improving the project.
hi! when do you think this feature is scheduled to be deployed for users? Thanks!
Having similar functionality in which default users can just upload files but not have access to everything that managers can access is the only thing stopping me from enterprise adoption with multiple clients.
Same for us.
On Mon, Oct 21, 2024, 6:24 PM scooter7 @.***> wrote:
Having similar functionality in which default users can just upload files but not have access to everything that managers can access is the only thing stopping me from enterprise adoption with multiple clients.
— Reply to this email directly, view it on GitHub https://github.com/Mintplex-Labs/anything-llm/issues/1787#issuecomment-2427972512, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANXCABAJEJJWSO752MXKZC3Z4WLKZAVCNFSM6AAAAABKCNZ77KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRXHE3TENJRGI . You are receiving this because you commented.Message ID: @.***>
If you want this feature, please react with the "thumbs up" emoji on the top level.
This is easier to rank when looking at "most requested" features since we dont have a feature upvote board and leaving comments does not rank the items higher since there are a ton of general "help" tickets in the repo also!
Hi @timothycarambat , Just curious if this fine-grained access control issue has gained enough traction to be prioritized. I have several organizations that will likely adopt anything-llm if so. Thanks!
@scooter7 it certainly has, the primary issue is the depth of work required to support this feature. It is by no means a minor change and would be a very significant overhaul of the permissions system
Hi @timothycarambat ,
Thanks for getting back to me!
I completely understand that this is a major feature enhancement but am excited that it will be addressed.
Do you have an ETA on when it might happen?
Thanks again!
Uploading documents to be allowed for all users would be a very useful improvement. currently they will also be able to change all the settings, they should not touch. they can not even upload a single file in the chat without the manager permission.
this would add a real value im my opinion.
Hello,
my company also need this. A simple option for different user groups or for the 3 groups that exist with radio buttons or similar where we can change some options.
- upload attachments as default
- which workspaces someone can see
- who can edit workspace documents
- change username forbidden or work with aliases
https://github.com/jeremykenedy/laravel-users?utm_source=chatgpt.com
Right now, this would be a k.o. criteria for my company to use anything llm
Thank you for this amazing project! This feature would enable it to be usable in bigger organizations that could benefit from many workspaces.
same for us, does it support on the latest version 1.7.5 or main branch? I pull the latest docker image and don't have the function.
Having similar functionality in which default users can just upload files but not have access to everything that managers can access is the only thing stopping me from enterprise adoption with multiple clients.
Same for us!
Love the tool – but the current permissions system creates serious privacy and usability issues.
Privacy concerns:
- Both Managers and Admins can see all user chats, without limitation.
- This level of transparency is likely in conflict with GDPR and internal data protection policies in many organizations.
- Such unrestricted access discourages users from asking sensitive or strategic questions, pushing them toward external tools.
Permissions inconsistency:
- The User role:
- Cannot select a different LLM
- Cannot upload files – this is essential for team collaboration.
- The Manager role:
- Still cannot select the LLM
- But can see all user chats, across all workspaces
- Is therefore too powerful in terms of access, yet too limited in configuration options
Conclusion:
- The current model is both overly centralized and not flexible enough.
- Teams need:
- File upload rights for standard users (without requiring elevated roles)
- LLM selection permissions configurable by role
- Private chats that are not visible to managers or admins unless explicitly shared
- A proper role-based access control (RBAC) system is urgently needed for secure, scalable enterprise use.
Just writing this to stress the significance of the topic :)
Regards, Sebastian
Tim,
This issue is limiting my ability to pilot anythingLLM beyond a single desktop instance for document analysis. How would I best work with your organization to add resources to this effort? Would you be open to. me putting out a job for bidding on Fiverr? Do you have a requirements definition for this feature set that could be bid against? Would you accept a solution from Fiverr for inclusion in the general release?
Jim
+1 for me. File upload for default users is a core feature need. Otherwise we have to make everyone Managers and loose control of the workspaces.
+1 for me. File upload for default users is a core feature need. Otherwise we have to make everyone Managers and loose control of the workspaces.
🛠️ Proposal: Short-Term Workaround for Fine-Grained Access Controls (Issue #1787)
This comment is intended as a collaborative contribution to the ongoing discussion around Issue #1787 and related Issue #3855. It outlines a short-term workaround that could help bridge the gap for enterprise deployments while a full RBAC system is under development.
🔐 Proposed Role Extensions
To improve access control granularity without overhauling the current system, we propose extending the existing 3-tier role model with two additional roles:
| Role | Capabilities |
|---|---|
| Super User | Upload/download documents, view analytics, but no access to settings |
| Power User | Same as Super User, with limited workspace creation or agent execution |
These roles could be implemented by:
- Extending the backend role enum
- Adding conditional UI rendering
- Restricting access to settings and sensitive API endpoints
🧱 Workspace-Level Resource Locking
As discussed in Issue #3855, we suggest implementing:
- Workspace-bound permissions: Users can only interact with documents, agents, and tools within assigned workspaces
- Scoped API tokens: Limit token access to specific workspace IDs
This would allow for:
- Segregation of sensitive data (e.g., per-client or per-department)
- Controlled access for different user groups
🔐 Entra ID (or IDP) Enforcement (Optional)
For teams using Entra ID or similar identity providers, we suggest:
- Group-based access mapping: Map Entra ID groups to internal roles
- Device compliance enforcement: Use Conditional Access policies to restrict access to compliant devices
This could be implemented via:
- Middleware that inspects OAuth claims
- Reverse proxy (e.g., Nginx) enforcing group/device-based access
🤝 Temp workaround / short-term fix - possible unblock
We recognize this is a temporary workaround, not a replacement for full RBAC. However, it may help unblock enterprise use cases (e.g., financial services, regulated industries) in the short term.
🛠️ Proposal: Short-Term Workaround for Fine-Grained Access Controls (Issue #1787)
This comment is intended as a collaborative contribution to the ongoing discussion around Issue #1787 and related Issue #3855. It outlines a short-term workaround that could help bridge the gap for enterprise deployments while a full RBAC system is under development.
🔐 Proposed Role Extensions
To improve access control granularity without overhauling the current system, we propose extending the existing 3-tier role model with two additional roles:
Role Capabilities Super User Upload/download documents, view analytics, but no access to settings Power User Same as Super User, with limited workspace creation or agent execution These roles could be implemented by:
- Extending the backend role enum
- Adding conditional UI rendering
- Restricting access to settings and sensitive API endpoints
🧱 Workspace-Level Resource Locking
As discussed in Issue #3855, we suggest implementing:
- Workspace-bound permissions: Users can only interact with documents, agents, and tools within assigned workspaces
- Scoped API tokens: Limit token access to specific workspace IDs
This would allow for:
- Segregation of sensitive data (e.g., per-client or per-department)
- Controlled access for different user groups
🔐 Entra ID (or IDP) Enforcement (Optional)
For teams using Entra ID or similar identity providers, we suggest:
- Group-based access mapping: Map Entra ID groups to internal roles
- Device compliance enforcement: Use Conditional Access policies to restrict access to compliant devices
This could be implemented via:
- Middleware that inspects OAuth claims
- Reverse proxy (e.g., Nginx) enforcing group/device-based access
🤝 Temp workaround / short-term fix - possible unblock
We recognize this is a temporary workaround, not a replacement for full RBAC. However, it may help unblock enterprise use cases (e.g., financial services, regulated industries) in the short term.
I love that you are working on this. I would like to recommend using the name "Workspace Admin" for your proposed "Power User", and recommend "Super User" be changed to "Power User". "Power User" is a traditional name for your top 5%-10% of users, cranking away in the system everyday that need some additional capabilities, but no administrative capabilities.
When will default users be able to upload files? This is impacting my application a lot. I can change the permissions and allow the default user to access the file upload URL, but I can't modify the frontend and enable the button since I'm using the official image.
