Zusammenfassung
Gib Vertrieb, Einkauf und Service eine gemeinsame KI-Dateisuche über das Firmenlaufwerk und lass jede Rolle nur ihre Ordner sehen. So funktionieren die Ordnerberechtigungen in AnythingMCP Enterprise (Allow, Deny, Deny gewinnt), wie du die Regeln planst und welche Alternative es ohne Enterprise gibt.
Frag einfach
Beispiel-Prompts für Network folder (File Search)
Klick auf einen Prompt, um ihn zu kopieren. In Claude, ChatGPT, Cursor, Gemini, Copilot oder OpenClaw einfügen — und gegen diesen Connector laufen lassen.
Claude ist KI und kann Fehler machen. Bitte Antworten gegenprüfen.
TL;DR: Ein KI-Assistent, der das Firmenlaufwerk durchsuchen kann, darf dem Azubi nicht die Einkaufskonditionen zeigen und auch nicht jedem den HR-Ordner. AnythingMCP steuert das auf drei Ebenen: wer die Datei-Tools überhaupt bekommt (MCP-Rollen), welcher Ordner ein Connector ist (ein Connector pro Ordner) und, in Enterprise, Ordnerberechtigungen pro Rolle innerhalb eines Connectors: Allow- und Deny-Regeln auf Ordnern, wobei Deny gewinnt. Die Regeln gelten für jedes File-Search-Tool, ein verborgener Ordner wird also nicht gefunden, nicht aufgelistet, nicht gelesen und nicht als Datei herausgegeben.
Drei Ebenen der Zugriffskontrolle
| Ebene | Was sie entscheidet | Edition |
|---|---|---|
| MCP-Rollen | Welche Rollen die Tools eines Connectors überhaupt bekommen, über die MCP-Server und Tool-Berechtigungen ihrer Rolle | Jede Edition |
| Ein Connector pro Ordner | „Wissensdatenbank“ für alle, „Lieferantenkonditionen“ für den Einkauf: zwei Connectors, zwei Zielgruppen | Jeder Plan mit File Search |
| Ordnerberechtigungen | Welche Ordner jede Rolle innerhalb eines Connectors sehen darf | Enterprise (Cloud und self-hosted) |
Die ersten beiden reichen für eine Handvoll klar getrennter Ordner. Ordnerberechtigungen lohnen sich, wenn ein Laufwerk viele Abteilungen enthält und du eine einzige Suche über alles willst, was die jeweilige Person sehen darf, statt fünf Connectors und fünf Tool-Sets.
So funktionieren Ordnerberechtigungen
Öffne den Tab Files des Connectors und gehe zu Folder permissions. Jede Regel besteht aus drei Teilen: einer Rolle, Allow oder Deny und einem Ordner des Connectors (ein Pfad relativ zum indexierten Ordner, etwa Purchasing/Conditions). Eine Regel gilt für den Ordner und alles darunter.
- Eine Rolle ohne Regeln sieht alles. Regeln gelten pro Rolle: Eine Regel für eine Rolle ändert nie, was andere Rollen sehen.
- Allow beschränkt eine Rolle. Allow-Regeln beschränken eine Rolle auf diese Ordner und ihre Unterordner. Eine Rolle ohne Allow-Regeln ist unbeschränkt.
- Mehrere Rollen addieren sich. Ein Nutzer mit mehreren Rollen sieht die Ordner, die irgendeine seiner Rollen erlaubt. Hat eine seiner Rollen keine Allow-Regeln, ist diese Rolle unbeschränkt, und der Nutzer sieht jeden Ordner.
- Deny gewinnt immer. Eine Deny-Regel verbirgt einen Ordner, auch innerhalb eines Ordners, den eine Allow-Regel geöffnet hat, und unabhängig davon, zu welcher Rolle des Nutzers sie gehört.
- Administratoren sehen jeden Ordner. Workspace-Administratoren sind nie beschränkt, damit sie prüfen können, was der Connector enthält.
- Jedes Tool hält sich daran. Suche, Find, List, exakte Suche, Lesen und der Dateilink arbeiten alle innerhalb der Ordner des Nutzers.
Die Regeln planen: ein Beispiel
Ein erfundener Großhändler bindet sein Laufwerk Company mit diesen Ordnern auf oberster Ebene an: Products (Datenblätter, Kataloge), Sales (Angebote, Kundenakten), Purchasing (Preislisten, Konditionen, Verträge), Service (Handbücher, Berichte) und Management.
| Rolle | Regel | Ordner |
|---|---|---|
| Sales | Allow | Products |
| Sales | Allow | Sales |
| Purchasing | Allow | Products |
| Purchasing | Allow | Purchasing |
| Purchasing | Deny | Purchasing/Contracts |
| Service | Allow | Products/Datasheets |
| Service | Allow | Service |
Das Ergebnis: Der Vertrieb fragt nach dem letzten Angebot eines Kunden und bekommt eine Antwort aus Sales; der Einkauf findet Preise in Purchasing, aber nicht die Rahmenverträge; der Service findet Handbücher und Datenblätter. Keine der drei Rollen sieht Management, weil jede auf ihre erlaubten Ordner beschränkt ist. Eine Management-Rolle ohne Regeln sieht alles, ebenso die Administratoren.
Schreibe die Regeln aus Sicht der Rollen: Beginne damit, was jede Rolle braucht (Allow), und schneide dann die Ausnahmen heraus (Deny). Das liest sich wie eine kurze Liste und lässt sich leicht mit den Abteilungsleitern prüfen.
Beachte, dass Regeln nur die Rollen einschränken, zu denen sie gehören, und sonst nichts. Ein Nutzer, der die Tools des Connectors hat, aber keine der beschränkten Rollen, sieht jeden Ordner. Entscheide zuerst, wer die Tools überhaupt bekommt (MCP-Rollen), und beschränke dann innerhalb dieser Rollen; und um einen Ordner vor einer Rolle zu verbergen, die sonst alles sehen soll, gib dieser Rolle eine Deny-Regel.
Teste es
- Nutze einen Testnutzer, der kein Workspace-Administrator ist und nur die Rolle hat, die du prüfen willst (oder bitte eine Kollegin oder einen Kollegen in dieser Rolle).
- Melde dich mit diesem Nutzer in Claude oder ChatGPT an (OAuth, nicht per API-Key) und frage zuerst etwas, das in einem erlaubten Ordner liegt, dann etwas aus einem gesperrten, zum Beispiel „finde den Rahmenvertrag mit Kessler“.
- Die erste Frage liefert Datei und Seite; die zweite liefert keinen Treffer, als gäbe es den Ordner nicht.
- Prüfe das Audit-Log: Jede Suche und jeder Lesezugriff wird mit Nutzer, Tool und Argumenten protokolliert.
Ohne Enterprise: ein Connector pro Ordner
Bei Starter und Team (und self-hosted Community während der Testphase) verbindest du jeden Ordner mit eigener Zielgruppe als eigenen File-Search-Connector und gibst jeden Connector an die MCP-Server und Rollen, die ihn bekommen sollen. Das Tool-Präfix des Connectors zeigt der KI dann, welchen Ordner sie durchsucht (products_search, purchasing_search). Die Anzahl der File-Search-Connectors pro Plan ist das Limit: einer bei Starter, drei bei Team. Pläne vergleichen.
Was Enterprise für File Search noch bietet
- Workspace-Richtlinie: öffentliche Freigabelinks an oder aus, maximale Gültigkeit von Links, KI-Entwurf für Ordnerbeschreibungen an oder aus, unverschlüsseltes FTP an oder aus.
- OCR für gescannte PDFs.
- Synchronisierung alle 15 Minuten in der Cloud, alle 5 Minuten self-hosted, und bis zu 50.000 Dateien in der Cloud (unbegrenzt self-hosted).
Single Sign-on und SCIM, die die Rollen mit deinem Verzeichnis abgleichen, gehören zu Enterprise self-hosted oder einer dedizierten Instanz. Siehe AnythingMCP Enterprise.
FAQ
Ändern Ordnerberechtigungen etwas auf dem Fileserver? Nein. Sie bestimmen, was AnythingMCP an jeden Nutzer zurückgibt. Das NAS oder Laufwerk behält seine eigenen Berechtigungen, und das File-Search-Konto sollte dort nur Leserechte haben.
Kann die KI die Regeln umgehen, indem man anders fragt? Nein. Die Regeln werden serverseitig bei jedem Tool-Aufruf angewendet, bevor Ergebnisse zusammengestellt werden. Das Modell erhält nie Dateien außerhalb der Ordner des Nutzers, also gibt es nichts, wozu man es überreden könnte. Die einzige Ausnahme ist nicht das Modell, sondern die Verbindung: Aufrufe mit einem MCP-API-Key sind nicht an einen Nutzer gebunden, daher gelten Ordnerregeln für sie nicht.
Folgen die Regeln den Berechtigungen des Laufwerks selbst? Nein, AnythingMCP liest die ACLs des Laufwerks nicht. Du legst die Regeln pro Rolle in AnythingMCP fest. Halte sie kurz: eine Handvoll Allow-Regeln pro Rolle und wenige Deny-Ausnahmen.
Verwandt
- MCP-Governance, Benutzerrollen und Berechtigungen
- Ein Synology- oder QNAP-NAS mit Claude und ChatGPT durchsuchen, Schritt für Schritt
- Eine Artikelnummer in PDF- und Excel-Preislisten finden
- Ein E-Mail-Archiv aus .msg- und .eml-Dateien mit KI durchsuchen
- Mit deinen Dokumenten chatten, RAG oder File Search: Was passt zu einem Firmen-Fileserver?
- Den Firmen-Fileserver mit KI durchsuchen
- Dateien aus einem KI-Chat als Download-Links teilen
War dieser Guide hilfreich?