Konfiguration von Dust Spaces und rollenbasierten Berechtigungen: Wie IT-Administratoren abteilungsübergreifenden Datenabfluss in KI-Assistenten verhindern

Beim unternehmensweiten Rollout generativer KI-Assistenten (AI Agents / Assistants) stehen IT-Administratoren, Sicherheits- und Compliance-Verantwortliche vor einem kritischen Dilemma: Mitarbeiter erzielen enorme Produktivitätsgewinne, wenn sie über natürliche Sprache auf interne Wissensdatenbanken zugreifen können. Herkömmliche Architekturen der Retrieval-Augmented Generation (RAG) bergen jedoch das gravierende Risiko von Datenabflüssen zwischen Fachabteilungen (Cross-Department Data Leakage). Wenn ein Mitarbeiter aus dem Marketing einen allgemeinen Unternehmensassistenten fragt: „Welche Anpassungen der Vorstandsvergütung wurden letzten Monat beschlossen?“ oder „Fasse die vertrauliche Prozessstrategie im Rechtsstreit mit unserem Lieferanten zusammen“, ruft ein monolithisches RAG-System diese sensiblen Dokumente ungehindert aus dem geteilten Vektorspeicher ab und fasst sie zusammen.

Einfache Schutzmaßnahmen auf Prompt-Ebene (Prompt Guardrails, wie etwa die Systemanweisung „beantworte keine Fragen zu Gehältern“) versagen regelmäßig bei Prompt-Injection-Angriffen, indirekten Fragestellungen oder semantischen Umschreibungen. Die Datenisolation im Unternehmen muss deterministisch und auf Architekturebene erzwungen werden, damit unbefugte Daten das Kontextfenster (Context Window) des Large Language Models (LLM) zu keinem Zeitpunkt erreichen können.

Dust löst dieses Problem durch ein infrastrukturelles Zwei-Ebenen-Berechtigungsmodell (Dual-Layer Permission Model), gestützt auf Spaces (isolierte Datencontainer), rollenbasierte Zugriffskontrolle (RBAC), SCIM-gestützte Verzeichnis-Synchronisation über den Identity Provider (IdP) und präzise Konnektoren-Eingrenzung. Dieser Leitfaden beschreibt Schritt für Schritt, wie IT-Administratoren Dust Spaces und Berechtigungsmatrizen konfigurieren, um maßgeschneiderte KI-Assistenten bereitzustellen, die Abteilungsgrenzen strikt wahren.

1. Die Kernarchitektur: Dusts Zwei-Ebenen-Berechtigungsmodell

Um abteilungsübergreifende Datenabflüsse zuverlässig zu unterbinden, müssen IT-Administratoren trennen, wie Assistenten auf Daten zugreifen und wie Menschen auf Assistenten zugreifen. Traditionelle SaaS-Lösungen nutzen eindimensionale Zugriffskontrollen: Darf Benutzer X das Dokument Y einsehen? Bei generativer KI führen autonome Assistenten jedoch Abfragen, Aggregationen und Synthesen stellvertretend für den Anwender durch, was simple Schutzmechanismen aushebelt.

Dust begegnet dieser Herausforderung mit zwei getrennten Sicherheitsebenen:

[ Externe Systeme (Drive, SharePoint, Slack, Notion) ]
                         │
                         ▼ (Admin-Scoping & Dienstkonto)
                 [ Dust-Verbindungen ]
                         │
                         ▼ (Zugewiesene Daten-Teilmengen)
          ┌──────────────┴──────────────┐
          ▼                             ▼
   [ Open Spaces (Offen) ]       [ Restricted Spaces (Eingeschränkt) ]
   (z. B. Company Data)          (z. B. Finanzen, Recht, Personal)
          │                             │
          ▼                             ▼
   [ Allgemeine Assistenten ]    [ Abteilungsassistenten ]
          │                             │
          ▼                             ▼
   (Alle Workspace-Mitglieder)   (Nur Mitglieder des jeweiligen Space)
          ▲                             ▲
          └──────────────┬──────────────┘
                         │
               [ Benutzer und Gruppen ]
             (Synchronisiert über SCIM / IdP)

Ebene 1: Assistenten-zu-Daten-Zugriff (Deterministische Datenkapselung)

Wird ein Assistent in Dust erstellt, sind seine Wissensabfragen und Tool-Funktionen strikt an zugewiesene Spaces gebunden. Ein Assistent, der ausschließlich mit dem IT-Support-Space und dem allgemeinen Company Data Space verknüpft ist, besitzt keinerlei Schnittstellen oder Vektorrechte, um Daten aus dem Finanz-Space oder Rechts-Space abzufragen. Diese Barriere greift auf Datenbank- und Indexebene, noch bevor eine Anfrage an das LLM übergeben wird.

Ebene 2: Mensch-zu-Assistent-Zugriff (Standardmäßige Sichtbarkeitssicherheit)

Dust folgt einem klaren Sicherheitsprinzip: Die von einem Assistenten genutzten Spaces bestimmen, wer diesen Assistenten sehen und nutzen darf. Standardmäßig kann ein Mitarbeiter einen Assistenten nur dann im Workspace suchen, einsehen und aufrufen, wenn er autorisiertes Mitglied aller Spaces ist, auf die der Assistent zugreift.

Greift ein Finanz-Assistent auf den eingeschränkten Finanz-Space zu, blendet Dust diesen Assistenten für alle Mitarbeiter außerhalb der Finanzabteilung vollständig aus. Dies verhindert Proxy-Angriffe: Kein unbefugter Mitarbeiter kann einen hochprivilegierten Assistenten als Hebel nutzen, um geschützte Unternehmensgeheimnisse abzugreifen.

2. Spaces-Strategie: Trennung von öffentlichen und sensiblen Datenbereichen

In Dust werden sämtliche Daten, Dokumente und Tools in Spaces organisiert. Eine saubere Strukturierung dieser Spaces ist die erste Verteidigungslinie gegen Datenlecks.

Open Spaces vs. Restricted Spaces

Die Rolle des Standard-Bereichs „Company Data“

Jeder Dust-Workspace enthält von Beginn an einen offenen Standard-Space namens Company Data:

• Dieser Bereich steht allen Mitarbeitern offen und kann weder gelöscht, umbenannt noch in einen eingeschränkten Bereich umgewandelt werden.
• Dort hinterlegte Dokumente werden von Standard-Assistenten (wie @dust) automatisch erfasst.
• Leitregel für Administratoren: Verknüpfen Sie niemals vertrauliche Abteilungsdokumente, Gehälter oder rechtliche Schriftsätze mit Company Data. Dieser Bereich fungiert als öffentliches schwarzes Brett des Unternehmens.

Kapazitätsgrenzen je Lizenzplan

• Business-Plan: Unterstützt bis zu 5 Spaces. Ausreichend für flache Unternehmensstrukturen mit grundlegender Trennung (Company Data, Führungsebene, Entwicklung, Vertrieb, Betrieb).
• Enterprise-Plan: Unterstützt bis zu 100 Spaces. Konzipiert für Konzerne und Matrixorganisationen, die eine feingranulare Kapselung je Abteilung, Tochtergesellschaft oder Geheimprojekt (z. B. interne Revision, M&A-Audits, Vergütung) benötigen.

3. Schritt-für-Schritt-Implementierung in 6 Phasen

Um eine abteilungsübergreifende Datenisolierung ohne Informationsabfluss zu etablieren, sollten IT-Administratoren folgende Schritte durchführen:

Schritt 1: Automatisierte Identitätsbereitstellung über SCIM 2.0

Die manuelle Verwaltung von Benutzerkonten führt unweigerlich zu Berechtigungsüberhängen bei internen Abteilungswechseln oder Austritten. Enterprise-Kunden sollten Dust zwingend über SCIM 2.0 an ihren zentralen Identity Provider (Okta, Microsoft Entra ID, Google Workspace) anbinden.

1. Navigieren Sie in Dust zu Admin > Organization > Members > Groups > User provisioning > Set up Directory sync.
2. Wählen Sie Ihren IdP aus und folgen Sie den Schritten zur SCIM-Einrichtung.
3. Richten Sie die Übertragung der Abteilungsgruppen ein (z. B. dept-finance, dept-legal, dept-people, exec-board).
4. Wechselt ein Mitarbeiter in Entra ID die Abteilung, synchronisiert Dust diesen Status in Echtzeit. Verlässt jemand die Finanzabteilung, erlischt der Zugriff auf den Finanz-Space und alle zugehörigen Finanz-Assistenten im selben Augenblick.

Schritt 2: Konnektoren-Eingrenzung mit dedizierten Dienstkonten

Dust-Konnektoren (Google Drive, Microsoft SharePoint/OneDrive, Notion, Confluence, Slack) binden externe Speicher an. Um ein versehentliches Überindizieren zu verhindern:

1. Keine persönlichen Admin-Konten verwenden: Binden Sie Unternehmensdaten niemals über das persönliche Konto eines IT-Mitarbeiters an. Scheidet dieser aus, bricht die Verbindung ab; zudem könnten persönliche Notizen versehentlich indiziert werden.
2. Dedizierte Dienstkonten einsetzen:
   • Google Drive: Legen Sie ein Dienstkonto wie dust-admin@ihre-domain.de an und gewähren Sie diesem nur Leserechte auf die freigegebenen Ablagen (Shared Drives), die für die KI vorgesehen sind.
   • Microsoft SharePoint / OneDrive: Erstellen Sie eine App-Registrierung in Entra ID mit der Anwendungsberechtigung Sites.Selected oder nutzen Sie ein dediziertes Dienstkonto (dust-service@ihre-domain.de). Beschränken Sie den Zugriff via PowerShell (Grant-PnPAzureADAppSitePermission) oder Microsoft Graph API streng auf ausgewählte SharePoint-Websitesammlungen.
   • Slack: Fügen Sie den Dust-Bot nur zu öffentlichen oder spezifischen Archivkanälen hinzu, niemals zu vertraulichen Leitungs-Channels.
3. Ordner gezielt auswählen: Wählen Sie im Einstellungsfenster von Dust gezielt Unterordner aus, anstatt komplette Root-Laufwerke pauschal zu synchronisieren.

Schritt 3: Restricted Spaces anlegen und IdP-Gruppen zuweisen

Sobald Daten über Verbindungen synchronisiert sind, verbleiben sie in einem Bereitstellungspool, bis ein Administrator sie einem konkreten Space zuordnet.

1. Öffnen Sie in Dust den Reiter Spaces und klicken Sie auf New.
2. Geben Sie den Namen ein (z. B. Finance & Accounting).
3. Wählen Sie Restricted.
4. Wählen Sie unter Mitgliederzuweisung Provisioned group access und verknüpfen Sie die SCIM-Gruppe (z. B. dept-finance).
5. Öffnen Sie den neuen Space, klicken Sie auf Connected Data und wählen Sie Add data from connections.
6. Markieren Sie ausschließlich die für diese Abteilung bestimmten Drive-Ordner oder SharePoint-Bibliotheken.
7. Speichern Sie mit Save. Die sensiblen Finanzdaten sind nun im isolierten Container eingeschlossen.

Dust Administrationskonsole: Restricted Space anlegen
┌─────────────────────────────────────────────────────────────┐
│ Neuen Space erstellen (Create New Space)                    │
│ Name: [ Finance & Accounting                              ] │
│ Zugriffstyp: ( ) Open (Offen)   (•) Restricted              │
│ Mitgliederzuweisung:                                        │
│   [ Provisioned group access                              ▼]│
│   Gruppen: [ dept-finance x ] [ exec-cfo x ]                │
│                                                             │
│ Verbundene Daten (Connected Data):                          │
│   [x] Google Drive: /Shared Drives/Finance/FY26_Budgets/    │
│   [x] SharePoint: /sites/FinanceOps/Financial_Statements/   │
│   [ ] Google Drive: /Shared Drives/Company_Wide/ (Exkludiert│
│                                                             │
│ [ Abbrechen ]                               [ Space anlegen]│
└─────────────────────────────────────────────────────────────┘

Schritt 4: Rollenverwaltung und Berechtigungen für Assistenten-Erstellung (RBAC)

Standardmäßig erlaubt Dust jedem Mitglied das Erstellen und Veröffentlichen von Assistenten. Im Unternehmensumfeld muss dies reglementiert werden.

Öffnen Sie Admin > Governance zur Anpassung der Berechtigungsmatrix:

1. Create agents und Publish agents: Ändern Sie die Berechtigung von Everyone auf autorisierte Fachgruppen (z. B. geschulte AI Builders) oder Admin only, um Wildwuchs ungeprüfter Assistenten zu unterbinden.
2. Create skills und Manage skill availability: Behalten Sie für Fähigkeiten mit externen API-Aufrufen die Einstellung Admin only bei.
3. Rollenmapping: Weisen Sie Rollen unter Admin > Members > Roles über Verzeichnisgruppen zu. Die Admin-Rolle sollte dem Kern-IT-Team vorbehalten bleiben. Abteilungsleiter können die Rolle Manager erhalten oder zu Group Managers ernannt werden, um Budgets und Mitglieder lokal zu verwalten, ohne sicherheitsrelevante Einstellungen zu verändern.
4. Sicherheitsrechte gezielt delegieren: Die Berechtigung Access security features (Zugriff auf Audit-Logs und Netzwerkkonfigurationen) ist nicht standardmäßig in der Manager-Rolle enthalten und muss explizit zugewiesen werden.

Schritt 5: Abteilungsassistenten erstellen und Schnittmengenregel beachten

Bei der Konfiguration im Agent Builder:

1. Formulieren Sie präzise Instructions bezüglich Zweck und Vertraulichkeit.
2. Fügen Sie unter Knowledge / Tools das Werkzeug Search data sources hinzu:
   • Wählen Sie ausschließlich den zutreffenden Restricted Space (z. B. Finance & Accounting).
   • Binden Sie Company Data nur dann ein, wenn allgemeine Handbücher zwingend erforderlich sind.
3. Beachten Sie die Multi-Space-Schnittmengenregel (AND-Bedingung):
   • Verknüpft ein Assistent Werkzeuge aus Space A (Finanzen) und Space B (Vorstand), muss ein Anwender Mitglied in BEIDEN Spaces sein, um den Assistenten sehen und nutzen zu können.
   • Besitzt ein Nutzer nur Rechte für Space A, wird der Assistent für ihn komplett ausgeblendet.
   • Best Practice: Ordnen Sie Fachassistenten in der Regel nur einem einzigen Restricted Space zu, um versehentliche Sperren berechtigter Kollegen zu vermeiden.

Schritt 6: Tool-Anmeldedaten festlegen (Personal vs. Shared)

Für Assistenten, die interaktive Aktionen in externen Plattformen (GitHub, Salesforce, Jira, HubSpot, MCP-Server) durchführen, legt der Administrator unter Knowledge > Tools das Berechtigungsmodell fest:

• Geteilte Anmeldedaten (Shared Credentials): Alle Nutzer führen Aktionen über ein zentrales Dienstkonto aus. Geeignet für rein lesende Wissensdatenbanken.
• Persönliche Anmeldedaten (Personal Level Credentials): Nach der initialen OAuth-Einrichtung durch den Administrator muss sich jeder Anwender beim ersten Aufruf mit seinem persönlichen Benutzerkonto authentifizieren.
  • Unerlässlich für sensible Fachsysteme: Bei Salesforce oder privaten GitHub-Repositories greift hierdurch die native Rechteverwaltung des Quellsystems. Fragt ein Marketingmitarbeiter über den Assistenten Vertriebsdaten ab, greifen seine persönlichen Salesforce-Rechte – eine doppelte Schutzmauer aus Dust-Space-Isolation und Quellsystem-RBAC.

4. Audit-Protokollierung, Monitoring und Offboarding-Prozesse

Nachhaltige Compliance erfordert die lückenlose Nachvollziehbarkeit aller Interaktionen im Workspace.

┌──────────────────────────────────────────────────────────────┐
│                    Enterprise-Echtzeit-Event-Stream          │
└──────────────────────────────┬───────────────────────────────┘
                               │
            ┌──────────────────┴──────────────────┐
            ▼                                     ▼
     [ Menschliche Aktion ]                [ Autonome KI-Aktion ]
     actor: "user"                         actor: "user"
     action: "agent.executed"              metadata.actor_type: "agent"
     targets: ["agent-finance-01"]         metadata.initiating_user: "..."
            │                                     │
            └──────────────────┬──────────────────┘
                               ▼
                 [ Dust Enterprise Audit-Engine ]
                               │
            ┌──────────────────┴──────────────────┐
            ▼                                     ▼
     [ Revisionssichere UI-Logs ]          [ SIEM-Streaming ]
     (Admin > Security > Audit Logs)       (Datadog, Splunk, S3, GCS)

Audit-Logs: Trennung zwischen Mensch und Maschine

Die Audit-Logs von Dust Enterprise (Admin > Organization > Security > Audit Logs) bieten manipulationssichere Protokolle:

• Akteur (Actor): Unterscheidet zwischen menschlichen Anwendern (user), API-Schlüsseln (api_key) und Systemprozessen (system), inklusive IP-Adresse und Client-Informationen.
• Aktionserfassung: Protokolliert Ereignisse wie agent.executed, space.created, space.deleted, data_source.updated und tool.executed.
• KI-Kausalitätszuordnung: Führt ein Assistent Abfragen oder Tool-Aktionen aus, wird metadata.actor_type: "agent" vermerkt, während die ID des auslösenden Menschen (initiating_user_id und initiating_user_email) dauerhaft gespeichert bleibt. Auditoren können jeden Datenzugriff zweifelsfrei rückverfolgen.

SIEM-Integration in Echtzeit

Audit-Logs können in Echtzeit an externe SIEM-Plattformen gestreamt werden, darunter Datadog, Splunk, AWS S3, Google Cloud Storage (GCS) oder benutzerdefinierte HTTPS-Webhooks. Bei restriktiven Firewalls sollten die in der Dust-Dokumentation aufgeführten WorkOS-Liefer-IP-Adressen freigegeben werden.

Mitarbeiter-Offboarding

Scheidet ein Mitarbeiter aus dem Unternehmen aus:

1. Deaktiviert der IdP das Benutzerkonto, woraufhin SCIM den Zugang in Dust sofort sperrt.
2. Der Zugriff auf alle Restricted Spaces und Fachassistenten erlischt unverzüglich.
3. Persönlich eingerichtete Automatisierungen und Trigger des Mitarbeiters werden automatisch und endgültig gelöscht.
4. Handlungsempfehlung vor dem Löschen: Prüfen Sie unter Programmatic Usage > Automations wichtige geplante Prozesse und übertragen Sie diese auf verbleibende Mitarbeiter. Bei unveröffentlichten Assistenten des ausscheidenden Nutzers kann ein Admin im Agent Builder auf Become an editor as an admin klicken, um die Bearbeitungsrechte zu übernehmen.

5. Architekturmatrix und Checkliste für Administratoren

Spaces- und Berechtigungsmatrix

Checkliste vor dem Produktivgang

• SCIM-Synchronisation aktiv: SCIM 2.0 ist konfiguriert; Abteilungsgruppen aus Okta oder Entra ID werden fehlerfrei nach Dust übertragen.
• Company Data bereinigt: Es befinden sich keine Gehaltsdaten, Quartalszahlen oder Rechtsakten im offenen Unternehmensbereich.
• Dienstkonten eingerichtet: Drive- und SharePoint-Verbindungen nutzen separate Dienstkonten mit minimalen Ordnerberechtigungen.
• Restricted Spaces zugeordnet: Für alle vertraulichen Abteilungen wurden eigene eingeschränkte Spaces mit verknüpften IdP-Gruppen erstellt.
• Konnektoren-Daten präzise gebunden: Vertrauliche Ordner wurden ausschließlich den jeweiligen Restricted Spaces zugewiesen.
• Assistenten-Erstellung eingeschränkt: Unter Admin > Governance wurde das Erstellen und Veröffentlichen von Assistenten auf autorisierte Gruppen begrenzt.
• Persönliche Anmeldedaten für Fach-Tools: Externe Systeme mit differenzierten Benutzerrechten (Salesforce, GitHub) sind auf Personal Credentials gestellt.
• SIEM-Protokollierung verifiziert: Audit-Log-Streaming zu Splunk oder Datadog ist aktiv und Testalarme wurden erfolgreich ausgelöst.

Durch die konsequente Trennung über Dust Spaces, gekoppelt mit nativer Verzeichnis-Synchronisation und feingliedriger Rollensteuerung, schützen IT-Administratoren geschäftskritische Daten zuverlässig vor unbefugtem Zugriff und ermöglichen gleichzeitig den sicheren, produktiven Einsatz generativer KI im gesamten Unternehmen.

Referenzen

• Spaces management
• Workspace Governance: Roles, Groups & Permissions
• Access Controls and Permissions
• Users and groups provisioning
• Personal vs Shared Credentials for Tools & MCP Servers
• Agents management
• Audit Logs
• Google Drive
• Microsoft
• Dust Security: Enterprise-Grade Data Protection