---
title: "Connect documents and knowledge without losing permissions"
description: "Searching across SharePoint and Drive without bypassing the permission model: where filtering belongs, what you do not copy and how to arrange exit up front."
source_name: "Gen8"
source_url: "https://gen8.app/en/kennis/documenten-en-kennis-verbinden/"
site_home: "https://gen8.app/"
source_description: "Managed AI service for SMEs. We set up, connect and manage; you stay in control."
locale: "en"
authors:
  - name: "Sasker Soontiëns"
    url: "https://gen8.app/en/kennis/author/sasker-soontiens/"
copyright: "© 2026 Gen8 VOF · Dutch Chamber of Commerce 92978789 · Delft"
published_at: "2026-09-05T00:00:00.000Z"
modified_at: "2026-10-22T13:46:25.436Z"
---

# Connect documents and knowledge without losing permissions

Making documents from different systems searchable is technically simple. The hard part is keeping the permission model of those systems intact — and that is a design choice you make at the start, not afterwards.

By Sasker Soontiëns · September 5, 2026 · Knowledge, Documents

## Where it goes wrong

The usual approach is: load everything into one index and make that index searchable. It works, it is quick to build and it promptly produces an impressive demonstration. It also invalidates every permission model in your organization in one move, because the index no longer knows folders, groups or exceptions — only text.

It is also noticed late. For the first weeks nobody asks a question they were not supposed to know the answer to. Then someone does, by accident, and it is an incident.

## Rule 1 — Filter on the person asking, not on the outcome

The permission check should determine which documents are eligible at all, before anything is read or summarized. That is different from blocking an answer afterwards: in that second case the model has already processed the content, and it often leaks anyway in the form of a summary.

In practice this means the search step happens on behalf of the user and the source system determines the selection — not a separate permission list you maintain yourself and that drifts after three months.

## Rule 2 — Copy as little as possible

Every copy is a second place where permissions can lapse, that has to be cleaned up and that counts in a data breach. Keep the documents where they are and retrieve only what is needed for the answer.

If you cannot avoid storing something, record three things: exactly what is kept, for how long, and what happens when the source file is deleted or the permissions change. The last one is the one most often skipped: a deleted document that stays in an index is a document you have not deleted.

## Rule 3 — Choose the sources, do not include everything

Not every folder belongs in a knowledge base. Drafts give answers that formally do not apply, personnel files belong separately, and client documents are covered by agreements with that client. Fewer sources with a clear status produce better answers than indexing everything — and make the conversation with the administrator a lot shorter.

Make that explicit per source, even if the answer is "yes, everyone may read this". A recorded decision is something different from an assumption nobody has tested.

## Rule 4 — Arrange exit at the start

At the outset, agree where the configuration, the credentials and the logs live, who manages them and what happens when the collaboration ends. At the beginning that is a paragraph and at the end it is a negotiation. This also applies to the least exciting part: the access tokens the connection uses should belong to your organization.

## What this costs in speed

These four rules make the build slower than the "everything in one index" route, especially on the permissions side. That is the honest trade-off: you give up a few weeks for a solution that survives the security review and that you do not have to turn into a second project later.

What then makes a knowledge base usable for the people who use it — source, permission and date — is covered in [internal knowledge base with AI](<https://gen8.app/en/kennis/interne-kennisbank-met-ai/>).

## What to do with this

Ask your administrator which three folders or sites are used most often and who has permissions on them. If that answer does not come within a day, the permission model itself is the first assignment — and that is cheaper to discover now than during the security review.

## Frequently asked questions

Can a knowledge base search several document systems at once?

Yes, but each system brings its own permission model. Run the permission check per source rather than in a shared layer on top, otherwise the weakest variant applies to everything.

What happens when someone loses access?

From that moment they must also stop getting answers from those documents. That only works if the check sits with the source system and not in a separate copy that is updated periodically.

Is a separate index never acceptable?

Sometimes it is — for a clearly delimited source that everyone may read, such as published procedures. Then make it a deliberate exception with a retention period, not the default approach for everything.

## Want to apply this to your own process?

Bring one process to a conversation. We assess suitability, risk and the cost of the first step.

[Book an introduction](<https://gen8.app/en/contact/>)

- Reply within one business day
- No obligation