Leitfaden
Einem Agenten Zugriff auf „alle Dokumente“ zu geben, wirkt wie der naheliegende Weg, ihn nützlich zu machen. Auf demselben Weg verschwinden aber sorgfältig gesetzte Zugriffsrechte still. Sobald ein Dokument zu Vektoren in einer Wissensdatenbank wird, sind die Regeln weg, wer es lesen durfte. Es sei denn, Sie setzen sie neu. In diesem Leitfaden geht es um diese Lücke und darum, wie Sie sie einfach schließen.
Ein Wissensdatenbank-KI-Agent beantwortet Fragen, indem er Ihre Dokumente liest, meist per Retrieval-Augmented Generation: Er findet die passenden Stellen in einem Speicher Ihrer Inhalte und nutzt sie für die Antwort. Kaum ein Agent liegt näher, und kaum einer wird so leicht unsicher gebaut. Denn der naheliegende Entwurf entfernt still einen Schutz, auf den Sie sich verlassen haben. Die Lösung ist nicht kompliziert, aber Sie müssen sie bewusst angehen.
Wir bauen Pinchy, eine selbst-gehostete Agentenplattform, deren Wissensdatenbank-Agenten von Haus aus begrenzt sind. Wir sind hier also nicht neutral. Das Problem unten ist trotzdem real, egal womit Sie bauen.
Das überrascht viele: Die Zugriffsrechte eines Dokuments stecken nicht im Dokument. Sie stecken im System, das es verwahrt. SharePoint weiß, wer diese Datei öffnen darf, Confluence weiß, wer jene Seite lesen darf. Bauen Sie eine Wissensdatenbank, nehmen Sie diese Dokumente, zerlegen sie in Teile und betten sie in einen Vektorspeicher ein, damit der Agent darin suchen kann. Nur die Berechtigung wandert nicht mit. Der Inhalt landet im Vektorspeicher ohne das Wer-darf-das-sehen, das das Quellsystem sorgfältig durchgesetzt hat. Und der Agent, der aus diesem Speicher abruft, weiß nicht, wer ursprünglich was lesen durfte. Standardmäßig prüft er es auch nicht (Truto).
Eine Wissensdatenbank, die Sie durch Zugriff auf alles befüllen, bewirkt also etwas Unauffälliges und zugleich Schädliches. Sie ebnet jede Berechtigungsgrenze in Ihrem Unternehmen zu einem einzigen ungetrennten Pool ein, den der Agent vollständig durchsuchen kann. Was die Personalabteilung sieht und was der Rest des Unternehmens sieht, war sorgfältig getrennt. Diese Trennung übersteht den Weg in den Vektorspeicher nicht.
Dieser Effekt hat einen Namen, sobald er zuschlägt. Der Agent wird zum verwirrten Stellvertreter: ein Akteur mit weitem Zugriff, den jemand mit geringen Rechten dazu nutzt, etwas zu tun, was er selbst nicht dürfte. Ein Nutzer, der ein heikles Dokument nicht öffnen darf, kann dem Agenten trotzdem eine Frage stellen, deren Antwort daraus stammt. Der zu weit berechtigte Agent ruft den Inhalt brav ab und gibt ihn zurück. Beim Zugriff selbst verletzt niemand eine Regel, denn der Agent ist für den Nutzer hineingegangen.
Deshalb gilt eine zu freizügige Wissensdatenbank heute als ernster interner Weg, Daten abzuziehen, nicht als Bequemlichkeit. Die OWASP Top 10 für LLM-Anwendungen rückten 2025 die Offenlegung sensibler Informationen auf Platz zwei. Schwächen bei Vektoren und Embeddings nahmen sie als neue Kategorie auf. Allen RAG-spezifischen Risiken liegt dasselbe zugrunde: ein Abruf, der Inhalte erreicht, die er nicht erreichen sollte.
So verhindern Sie verlässlich, dass Daten ungewollt durchsickern: Der Agent ruft immer nur ab, was er abrufen darf. Dafür gibt es zwei Routen, und eine davon ist für die meisten Teams deutlich einfacher.
Die schwere Route ist eine Zugriffskontrolle auf Dokumentebene. Sie prüft bei jeder Anfrage die Rechte des fragenden Nutzers gegen das Quellsystem, damit der Agent nur die Teile sieht, die dieser Nutzer einsehen durfte. Für ein großes Suchwerkzeug über viele Systeme hinweg ist das die richtige Antwort. Im Betrieb ist es aber echte Entwicklungsarbeit.
Die Route, die zu den meisten Teams passt, begrenzt den Agenten, statt Rechte pro Nutzer nachzubauen. Geben Sie jedem Agenten Lesezugriff auf bestimmte Verzeichnisse oder Dokumentmengen, nur lesend, mit Standard-Verbot, statt ihn auf den ganzen Bestand loszulassen. Ein Support-Agent liest die Support-Dokumente und sonst nichts. Ein Personal-Agent liest den Ordner der Personalabteilung und sonst nichts. So bleibt die Berechtigungsgrenze auf der Ebene des Agenten, genau dort, wo die Grenze eines Agenten mit einem Zweck hingehört. Und Sie schütten gar nicht erst jedes Dokument in einen durchsuchbaren Pool. Verbinden Sie das mit einem Audit-Eintrag, was der Agent gelesen hat. Geben Sie von vornherein nicht zu viel frei, dann entsteht das Problem gar nicht erst.
Pinchy begrenzt seine Wissensdatenbank-Agenten über eine Verzeichnisauswahl je Agent. Sie geben einem Agenten nur lesenden Zugriff auf bestimmte Verzeichnisse, und das ist die gesamte Welt, aus der er liest. Ein neuer Agent hat keinen Dokumentzugriff, bis Sie ihm einen geben. Und was Sie geben, ist eine bewusste, sichtbare Wahl, kein Standard von allem. Pinchy nimmt also die Route oben und begrenzt den Agenten. Die Berechtigungsgrenze bleibt auf Agentenebene. Der Bestand wird nie zu einem Pool eingeebnet, und jeder Lesezugriff landet im Audit-Trail. Wir sind offen zur Grenze: Das ist verzeichnisbasierter Zugriff, kein Abgleich der Rechte pro Endnutzer gegen die ACLs eines Quellsystems. Die richtige Zugriffseinheit in Pinchy ist also der Agent und seine freigegebenen Ordner, kein lebendes Abbild dessen, wer in SharePoint was sehen darf. Die meisten Wissensdatenbank-Agenten verfolgen einen Zweck und lesen eine begrenzte Menge Dokumente. Für sie passt genau dieses Modell. Es gehört zum selben Ansatz mit Standard-Verbot, den die Plattform auch sonst bei den Berechtigungen verfolgt. Die Produktsicht finden Sie auf der Seite zu den Wissensdatenbank-Agenten.
FAQ
Ein Wissensdatenbank-KI-Agent beantwortet Fragen, indem er Ihre Dokumente liest, meist per Retrieval-Augmented Generation (RAG): Er findet die passenden Stellen in einem Speicher Ihrer Inhalte und nutzt sie für die Antwort. Er macht aus einem Stapel Dokumente etwas, das Sie befragen können. Über die Sicherheit entscheidet diese Governance-Frage: Welche Dokumente erreicht er, und achtet er darauf, wer sie sehen durfte?
Weil die Zugriffsrechte im Quellsystem stecken, nicht im Text. Zerlegen Sie ein Dokument aus einem Werkzeug wie SharePoint oder Confluence in Teile und betten es in einen Vektorspeicher ein, wandert die ursprüngliche Einstellung nicht mit, wer das sehen darf. Der Vektorspeicher hält den Inhalt ohne die Berechtigung. Der Agent, der daraus abruft, weiß also nicht, wer diesen Inhalt ursprünglich lesen durfte, und prüft es standardmäßig nicht.
Es tritt auf, wenn ein Nutzer mit wenigen Rechten einen Agenten mit mehr Rechten dazu bringt, für ihn zu handeln. In einer RAG-Wissensdatenbank kann ein Nutzer, der ein heikles Dokument nicht sehen darf, dem Agenten trotzdem eine Frage stellen, deren Antwort daraus stammt. Der zu weit berechtigte Agent ruft diesen Inhalt ab und gibt ihn zurück. Der Agent ist der verwirrte Stellvertreter: Er hat weiten Zugriff und nutzt ihn für jemanden, der ihn nicht hat. Das macht eine zu freizügige Wissensdatenbank zu einem internen Weg, Daten abzuziehen.
Sorgen Sie dafür, dass der Agent nur das abruft, was er abrufen darf. Der verlässliche Ansatz für die meisten Teams begrenzt den Lesezugriff jedes Agenten an der Quelle: Geben Sie ihm bestimmte Verzeichnisse oder Dokumentmengen, nur lesend, mit Standard-Verbot, statt ihn auf alles loszulassen. So bleibt die Berechtigungsgrenze auf der Ebene des Agenten, statt jedes Dokument zu einem ungetrennten Speicher einzuebnen. Und Sie können festhalten, was der Agent tatsächlich gelesen hat.
Es kann eines sein, und das Risiko liegt vor allem am Zugriff, nicht an der Technik selbst. In den OWASP Top 10 für LLM-Anwendungen stieg 2025 die Offenlegung sensibler Informationen auf den zweiten Platz, und Schwächen bei Vektoren und Embeddings kamen als neue Kategorie hinzu. Allen gemeinsam ist ein zu freizügiger Abruf: ein Agent, der aus Dokumenten ziehen kann, die er nicht ziehen sollte. Begrenzen Sie den Abruf, dann entfällt der Großteil des RAG-spezifischen Risikos.
Pinchy-Wissensdatenbank-Agenten lesen nur die Verzeichnisse, die Sie freigeben, nur lesend und mit Standard-Verbot, und Pinchy protokolliert jeden Lesezugriff im Audit-Trail. Open Source, selbst-gehostet, kostenlos zu betreiben.
Oder schreiben Sie uns: info@heypinchy.com