A local ChatGPT on your Nextcloud data where every person sees only what they are allowed to see?
In the RAG Proof of Value we make one priority knowledge source usable with citations, a permissions path and subject-matter acceptance, from €9,900 excl. VAT. The AI Cube can serve as the local platform; automated Nextcloud integration and permission synchronisation are planned for your actual source.
A local language model on your own Nextcloud documents is quickly set up: Open WebUI as the interface, a few files in a knowledge base, done. For a prototype that is enough. For production, however, it creates a silent data leak - because the permissions from Nextcloud do not travel with the data automatically. This article shows the architecture of a dependable system: from identity through carrying over the Nextcloud ACLs to the filter in the vector database. As of October 2026, Open WebUI v0.12.
Table of contents
- The language model is not a bouncer
- The target architecture: ACLs before the vector search
- Shared identity and its secure handover
- Carrying over Nextcloud permissions
- The ACL filter in the vector database
- Three paths: from oikb to a dedicated retrieval service
The language model is not a bouncer
The obvious but wrong path: load all documents into a shared knowledge base and tell the model via a system prompt to show personnel files only to HR. That is not a security boundary. A language model is not an access check - it can be talked into things, and a single unlucky retrieval hit is enough for a passage from a confidential document to land in the answer.
The core of the problem: Open WebUI does not automatically carry over the Nextcloud ACL when a file is uploaded. The personnel file that is visible in Nextcloud only to HR becomes findable in the shared knowledge base for anyone with access to that knowledge base. The solution is a principle from classic enterprise applications: rights are enforced in the backend, not in the presentation layer. Applied to RAG that means - the model receives only passages already authorized for the requesting user.
The target architecture: ACLs before the vector search
Between the interface and the language model sits a dedicated retrieval service that carries the security logic. The flow of a request:
- The user asks a question in Open WebUI; their identity is handed over securely.
- The retrieval service resolves identity and groups into security principals.
- From the principals a mandatory filter for the vector search is built.
- The vector database returns only hits the filter permits.
- Only these authorized passages go to the LLM as context.
The language model thus never sees a chunk the user may not see. What is forbidden is not "forbidden" via a prompt but does not reach the model at all.
Shared identity and its secure handover
The foundation is a shared identity via a central identity provider (OIDC): Open WebUI, Nextcloud and the RAG service know the same user through a stable ID - the immutable OIDC sub, not the changeable email.
In the handover from Open WebUI to the retrieval service lies a trap. With ENABLE_FORWARD_USER_INFO_HEADERS enabled, Open WebUI forwards unsigned plaintext headers (X-OpenWebUI-User-Id, -Email, -Name, -Role) that are forgeable on the network path. If FORWARD_USER_INFO_HEADER_JWT_SECRET is also set, an HS256-signed token in the header X-OpenWebUI-User-Jwt replaces these headers; it expires after 300 seconds by default (environment variables). HS256 is a shared secret, not a public key. And the sub in this token is the internal Open WebUI user ID, not the OIDC sub: the retrieval service has to map the two identifiers.
The more robust path is the sign-in token from the identity provider. MCP and OpenAPI tool servers can be connected in Open WebUI with the authentication "OAuth"; the service then receives the user's access token as a bearer token and can verify it asymmetrically against the identity provider (MCP in Open WebUI). Since v0.12.0 a renewed token is used as well. It carries the real OIDC sub and, depending on configuration, groups.
Groups do not belong in headers you have to trust. The built-in headers and the JWT contain no groups; since v0.11.0 Open WebUI groups can be written into custom headers via the placeholders {{USER_GROUPS}} and {{USER_GROUP_IDS}}, but these are unsigned. The RAG service therefore resolves groups server-side from the identity provider or via LDAP, or reads them from the verified token. In every case the retrieval endpoint is reachable internally only, never directly from the browser.
Carrying over Nextcloud permissions
During indexing a connector computes the effective ACL per document: owner, direct user shares, inherited folder shares, group and Teams shares. These shares come from the OCS Share API. If documents live in Team Folders (formerly Group Folders), their extended rights do not come from the Share API but via WebDAV with the nc:acl-list property. Changes to files and shares can be fetched via the Activity API; its feed is per user, however, so a service account only sees its own view.
The computed ACL is stored as a list of security principals in the payload of each chunk - directly on the text passages that will later be searched. A deliberate decision concerns public link and federated shares: they should not automatically mean that every AI user gets access. For internal RAG you carry over, by default, only owner, direct user shares and internal group shares.
The ACL filter in the vector database
The decisive technical point: the ACL filter runs together with the similarity search, not after it. Post-filtering - first find the best hits, then remove forbidden ones - is error-prone and weakens tenant separation. A vector database such as Qdrant applies the payload filter directly during the search, so that forbidden chunks do not even enter the result set.
For tenant and rights separation a payload filter over the stored principals is preferable to a separate collection per user. And the direction of failure must be right: on revocation or doubt the rule is fail-closed - no access when in doubt, not the other way round. A revoked right must land in the index promptly, otherwise a document stays visible that must no longer be.
Three paths: from oikb to a dedicated retrieval service
Which path fits depends on how fine-grained the rights need to be.
| Path | How documents reach Open WebUI | Rights | Fits |
|---|---|---|---|
| Knowledge base + oikb | The official sync tool oikb synchronises a Nextcloud folder via WebDAV into a knowledge base, on a schedule and including deletions | Open WebUI grants read and write rights per knowledge base to groups; Nextcloud rights per file are not carried over | Knowledge areas with a clear group mapping, for example one knowledge base per department folder |
| Nextcloud-native | Context Chat indexes inside Nextcloud; the Context Agent provides an MCP endpoint that Open WebUI uses as a tool | What the user sees in Nextcloud applies; rules from files_accesscontrol are not respected | Teams that already work in Nextcloud and do not want to run their own indexing |
| Dedicated retrieval service | Own connector with the ACL in the payload, connected as an MCP or OpenAPI tool server with an OAuth token | Rights per file, enforced technically before the vector search | Production systems with confidential documents and individual shares |
The pragmatic path starts with the first option: it shows value and answer quality and needs no dedicated service. For mapping individual user and group rights per file it does not hold, not even with oikb, which synchronises with a single service account. That is when the dedicated retrieval service follows. Today you connect it as an MCP or OpenAPI tool server; Open WebUI lists pipelines as legacy and advises against them for new deployments.
One change affects all three paths: with native function calling, Open WebUI no longer injects attached knowledge bases into the context automatically; instead the model calls tools such as query_knowledge_files (Knowledge). These tools respect the rights in Open WebUI, not those in Nextcloud. How RAG works in principle is explained in What is RAG?; where the components sit in the bigger picture is shown by The open-source LLM stack.
Want to take this path with your Nextcloud data?
In the RAG Proof of Value we implement the retrieval service with carried-over permissions for one prioritised knowledge source and review it with your subject experts.
