mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-08 04:16:03 -05:00
[GH-ISSUE #17669] feat: Hide knowledge bases which are private from users even if they are using a model which has had the knowledge base shared with it #33888
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#33888
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @b4ux1t3 on GitHub (Sep 23, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/17669
Check Existing Issues
Problem Description
Simply allowing a model access to a knowledge base in the admin settings makes any and all knowledge bases shared with that model available to users who should not have visibility of that knowledge.
Desired Solution you'd like
I'd prefer if users talking to a model could only access resources they're actually allowed access to. When processing chats from users with no access to knowledge that the model has been given access to, simply don't use it for querying/searching.
Alternatives Considered
No response
Additional Context
No response
@silentoplayz commented on GitHub (Oct 23, 2025):
Thank you for the report. At the moment the ticket does not contain enough detail for us to determine whether this is a permissions bug, an enhancement request, or both, BUT I believe I have confirmed this issue on the latest commit of the
devbranch at the time of typing out this comment. I would very much appreciate your confirmation as to whether this is similar to how you were able to reproduce the issue.Test plan – 5-minute sanity check that proves the bug exists
Preconditions
• You need two accounts:
– Admin (can attach KBs to models)
– User (must not have read access to at least one KB)
• Create / pick two knowledge bases:
– KB-public : visible to everyone (Public)
– KB-private : visible only to Admin (Private)
• Pick any model (base or workspace) that Restricted-user is allowed to chat with.
Attach both KBs to the model
KB-publicandKB-privateknowledge-bases to model → Save & Update.New Chatpage → Type#in the text input field → You should not seeKB-Privateknowledge collection or any files contained in that collection.Verify you only see
KB-Publicknowledge collection and its files.Observe that the model answers with the private content as a source → bug confirmed (user obtained data they cannot directly read).
Repeat once with the KB-private detached to be sure the model really was pulling from it in step 4.
TL;DR: When a knowledge base is attached to a model, all users who can chat with that model receive answers drawn from the KB—even if their own account lacks read permission on that KB. In short, model-level attachment currently overrides user-level KB access control lists. The model disclosed a private file to a user without access/visibility to the knowledge; the file is stored in a knowledge base that belongs only to the superadmin who created it as a private knowledgebase.
The provided screenshots alone speaks for itself and are a product of the test results:
From my Superadmin account, I created two knowledge-bases. One made
Public, the otherPrivate.I then attached both knowledge-bases to a model (tested with both a base model and a custom
Workspacemodel created from a base model; either works to reproduce this issue).Moving over to the user account, typing
#reveals that I can only attach the Public knowledge-base collection and/or file to the chat input field, but asking a question about something only in the Private knowledge-base collection and/or file revealed exactly what it shouldn't have!I SHOULD NOT BE ABLE TO SEE THE CONTENTS OF THIS FILE AT ALL AS A USER WITHOUT PERMISSION TO THE KNOWLEDGE-BASE!
If I click on the underlined text file name from the user account that shouldn't have access to the private file, it indeed doesn't get to see the contents of the file, but the model still tells the user about the file and reveals the contents in the source/annotation modal.
Edit: If I toggle the switch for
Use Full Documentfor thePrivateknowledgebase, then the user does not have access to it! The user has access to it without this switched on.@b4ux1t3 commented on GitHub (Oct 31, 2025):
Just wanted to let you know I saw your response and have put "Read this and verify" to my todo list for today/early next week, sorry for the slow response!
@apunkt commented on GitHub (Dec 16, 2025):
I see exactly the desired behaviour in v0.6.41
I (Admin) have a private knowledge base, which I attach to a public model.
Anyone using the public model - cannot see the knowledge base nor add via #
The knowledge base is not used when any user is using this model, but is used when I use this model. (you can see in the logs search is not performed for any user - even though the frontend briefly (and wrongly) shows that is performing search)
However, in previous versions the behaviour was different!
When an admin attached a private knowledge base to a model, anyone using this model was not able to see or access the knowledge base, but the model they had access to still had access to the knowledge base, so any user could leverage knowledge from the model response without exposing it to the user.
Which, I believe is the correct behaviour, because as an admin I might want to decide to grant a model access to knowledge (but not the user, so keeping it private) and granting users access to the model that uses the knowledge.
How would I config this in v0.6.41 ?
Because this is what I want (back).
Thanks
@Classic298 commented on GitHub (Dec 16, 2025):
Just set the knowledgebase to public?
@Classic298 commented on GitHub (Dec 16, 2025):
Thanks @apunkt for confirming this fixed. Closing.
@apunkt commented on GitHub (Dec 16, 2025):
I want a public model have access to a private knowledge base using it to formulate responses for public users
AND public users NOT to see the private knowledge base.
This was working (intentionally or unintentionally) in previous versions, but now isn't anymore.
Now the UI says "searching knowledge base" but it silently fails, nothing in the logs, no search hits the vector store (qdrant).
I suppose because the knowledge base is private and user has no access to it.
But I believe it is a feature to only grant a model access to a private knowledge base and make this model publicly available.
@Classic298 commented on GitHub (Dec 16, 2025):
Can you please expand on why a public knowledgebase is not an option here yet you want the information to be publicly accessible? Maybe this can help with finding an alternative solution.
@apunkt commented on GitHub (Dec 16, 2025):
In my use case the knowledge base contains propietary information.
The way I chunked the information and prompted the model will not expose this propietary information, but rather share the "method" of the propietary information, which itself is not propietary.
The model then answers how you can do something (approach) rather than how it has been done (i.e. in code), this keeping propietary information private but sharing allowed methods so users can come up with own ideas.
@Classic298 commented on GitHub (Dec 16, 2025):
@apunkt As a security engineer I want to urgently tell you that no prompt is good enough to prevent attacks against LLMs.
Any information given to an LLM (e.g. via a knowledge base) CAN (and eventually WILL) be extracted by users managing to jailbreak the model to ignoring it's system prompt and just throwing out the information.
Even models by the largest companies, i.e. Anthropic and Google, get jailbroken regularly despite their very noble red teaming efforts. It's just the nature of these models. It's not classic software that adheres to fixed rules - it's non deterministic.
Furthermore: in Open WebUI, users can just click on the sources the model cited (i.e. the knowledgebase that is referenced) and when clicking on the source, you will see the source's content in the source citation popup.
e.g.:
What I could recommend to you in your case could be to build a function, give that function to the model and have the model query information from a knowledge base (RAG) via the function - through that you could bypass the access control of open webui.