Zum Inhalt springen

Rechtevergabe für angebundene Werkzeuge

Admin

Angebundene Werkzeuge erweitern den Assistenten um Ihre eigenen Systeme — eine Datenbank, einen Ordner, ein Postfach, eine API oder einen MCP-Server. Mit welchen Rechten diese Anbindungen arbeiten, entscheiden Sie bei der Einrichtung. CompanyWizard kann nur das, was das hinterlegte Konto darf.

Dieser Artikel beschreibt, wie Sie diese Rechte so vergeben, dass ein Fehler klein bleibt.

Der Grundsatz: geringstmögliche Berechtigung

Section titled “Der Grundsatz: geringstmögliche Berechtigung”

Ein angebundenes Werkzeug bekommt genau die Rechte, die seine Aufgabe erfordert — nicht die Rechte, die gerade zur Hand sind. Drei Fragen vor jeder Anbindung:

  1. Welche Daten braucht das Werkzeug? Eine Tabelle, nicht die Datenbank. Ein Ordner, nicht das Laufwerk.
  2. Welche Art von Zugriff braucht es? Lesen genügt fast immer. Schreiben ist die Ausnahme und muss begründet sein.
  3. Wer darf es aufrufen? Standardmäßig sieht jeder Benutzer jedes aktive Werkzeug. Im Tab Zugriff können Sie einen Benutzer auf ausgewählte Werkzeuge beschränken. Das gilt für Werkzeuge, die der Benutzer im Chat direkt aufruft — ein Agent führt die Werkzeuge seiner eigenen Konfiguration unabhängig davon aus.

Verwenden Sie für jede Anbindung ein eigenes technisches Konto, nicht das persönliche Konto eines Administrators und kein Sammelkonto, das schon für etwas anderes im Einsatz ist. Das hat drei praktische Gründe:

  • Rechte lassen sich zuschneiden. Ein Datenbankbenutzer nur mit SELECT auf drei Views ist schnell angelegt; ein Administratorkonto lässt sich nicht nachträglich beschneiden.
  • Protokolle werden lesbar. Im Protokoll des Zielsystems erkennen Sie sofort, dass ein Zugriff von CompanyWizard kam und nicht von einem Mitarbeiter.
  • Abschalten ist ein Handgriff. Ein technisches Konto können Sie sperren, ohne dass jemand seine Arbeit verliert.

Benennen Sie die Konten sprechend, etwa svc-cw-vertriebsdaten statt dbuser3.

Welche Werkzeuge überhaupt schreiben können

Section titled “Welche Werkzeuge überhaupt schreiben können”

Viele Anbindungen sind von Haus aus rein lesend. Es lohnt sich zu wissen, welche das nicht sind — dort und nur dort entsteht das Risiko einer nicht umkehrbaren Aktion.

AnbindungSchreibender Zugriff möglich?Was Sie einstellen
SQL-DatenquelleNein. Die Abfrage legen Sie fest; erlaubt ist nur ein einzelnes SELECT/WITH, und die Transaktion wird immer zurückgerolltDatenbankbenutzer trotzdem auf Lesen und auf die benötigten Tabellen oder Views beschränken
Kalender-WerkzeugeNein. Kein Anlegen, Ändern, Löschen, keine EinladungenKalenderfreigabe auf die benötigten Kalender begrenzen
Git-Werkzeuge (Desktop)Nein. GitStatus, GitLog, GitDiff sind lesend—
Arbeitsordner (Desktop, eingebaut)Ja. WorkspaceWrite legt Dateien an und ändert sieAls Arbeitsordner keinen Ordner wählen, dessen Verlust wehtut; Sicherung prüfen
Ordner-Werkzeug (Desktop)Optional. write ist abschaltbar und standardmäßig auswrite nur aktivieren, wenn die Aufgabe es verlangt; Stammpfad eng wählen
Postfach-WerkzeugJa. Markieren und Archivieren gehören schon zum Lesezugriff; Versand nur mit freigegebenem send, nur an Empfänger der Positivliste und standardmäßig höchstens 20 pro Stunde (einstellbar)Funktionspostfach statt persönlichem Postfach; Versand nur bei Bedarf
HTTP-API-WerkzeugHängt von der Methode ab, die Sie festlegen. GET/HEAD fragen ab, POST/PUT/PATCH/DELETE verändern — was ein Aufruf tatsächlich bewirkt, entscheidet die APIToken mit möglichst engem Geltungsbereich; lesende Endpunkte bevorzugen
CLI-Befehlswerkzeug (Desktop)Ja, aber zustandsändernde oder netzende Kommandos laufen erst nach Ihrer Freigabe im DialogNur die Programme pinnen, die eine Aufgabe tatsächlich braucht
Externe MCP-ServerJa, in vollem Umfang dessen, was der Server anbietetZugangsdaten des Servers beschränken; nur Server anbinden, deren Werkzeugumfang Sie kennen

Die MCP-Zeile verdient die meiste Aufmerksamkeit. Ein MCP-Server bringt seinen eigenen Werkzeugkasten mit, und CompanyWizard kann ihm nicht mehr Grenzen setzen, als die hinterlegten Zugangsdaten es tun.

SQL-Datenquelle. Legen Sie einen eigenen Datenbankbenutzer an, geben Sie ihm ausschließlich SELECT, und zwar auf die benötigten Tabellen oder — besser — auf eigens dafür angelegte Views. Views sind hier das stärkere Werkzeug: Sie können darin Spalten weglassen, die der Assistent nicht sehen soll.

Ordner-Werkzeug. Der Stammpfad ist die Grenze: Pfade außerhalb werden abgewiesen, auch über .. und symbolische Links. Wählen Sie ihn deshalb so eng wie möglich — den Projektordner, nicht das Abteilungslaufwerk. write bleibt aus, solange niemand einen Grund nennen kann.

Postfach. Ein Funktionspostfach, kein persönliches. Wenn der Assistent nur suchen und lesen soll, geben Sie den Versand nicht frei.

HTTP-API. Ein eigener Token je Anbindung, mit dem engsten Geltungsbereich, den die API anbietet. Läuft der Token ab, erneuern Sie ihn — ein Token ohne Ablauf ist bequem und bleibt Jahre gültig.

Kalender. Ein eigenes Konto oder eine gezielte Freigabe auf die Kalender, um die es geht. Nicht das Postfach des Geschäftsführers mit Vollzugriff.

MCP-Server. Prüfen Sie vor der Anbindung, welche Werkzeuge der Server anbietet — nach dem Anlegen zeigt der Dialog die Werkzeugliste, und in der Serverliste können Sie sie jederzeit aufklappen. Einzelne Werkzeuge eines Servers lassen sich nicht abschalten, nur der ganze Server. Hinterlegen Sie Zugangsdaten, die im Zielsystem selbst beschränkt sind. Bei einem Server, den Sie nicht selbst betreiben, gilt das doppelt.

Inhalte aus angebundenen Quellen sind Daten, keine Anweisungen

Section titled “Inhalte aus angebundenen Quellen sind Daten, keine Anweisungen”

Was aus einer angebundenen Quelle zurückkommt, kann Text enthalten, der wie eine Anweisung an den Assistenten formuliert ist — ein Kommentarfeld in der Datenbank, eine Datei im Ordner, die Antwort eines fremden Servers. Das ist kein theoretischer Fall; die Fachwelt nennt es Prompt Injection.

Praktisch heißt das:

  • Binden Sie nur Quellen an, deren Inhalte Sie als vertrauenswürdig ansehen oder gesondert prüfen.
  • Je weniger eine Anbindung verändern darf, desto weniger kann ein manipulierter Inhalt anrichten. Das ist der eigentliche Grund für den lesenden Zugriff als Voreinstellung.

Nicht jede schreibende Aktion wird vorher bestätigt. Der Arbeitsordner fragt im Chat nach, bevor er eine bestehende Datei überschreibt (im Planmodus vor jedem Schreiben), und das CLI-Befehlswerkzeug startet zustandsändernde Kommandos erst nach Ihrer Freigabe. Beim Ordner-Werkzeug, beim Postfach, beim HTTP-API-Werkzeug und bei MCP-Servern fragt CompanyWizard derzeit nicht nach, bevor geschrieben wird; Agenten unterdrücken schreibende Aufrufe nur im Trockenlauf. Die wirksame Grenze sind dort die Rechte, die Sie vergeben.

Verbindungszeichenfolgen und Token konfigurierter Werkzeuge, Kennwörter von Postfach- und Kalenderkonten sowie OAuth-Geheimnisse von MCP-Servern werden verschlüsselt abgelegt.

Ausnahme: Kopfzeilen und Umgebungsvariablen eines MCP-Servers werden unverschlüsselt gespeichert und sind für Administratoren im Formular lesbar. Ein API-Schlüssel, den Sie dort eintragen, ist also so geschützt wie die Datenbank selbst. Bevorzugen Sie OAuth, wenn der Server es anbietet, und geben Sie einem Schlüssel in einer Kopfzeile nur den engsten Geltungsbereich. → Umgebungsvariablen & appsettings

Trotzdem gilt: Ein Zugangsdatum, das einmal hinterlegt wurde, sollte auch einmal wieder gewechselt werden. Nehmen Sie Anbindungen in Ihren üblichen Turnus für Kennwortwechsel auf.

Anbindungen überleben die Projekte, für die sie eingerichtet wurden. Sehen Sie die Liste der konfigurierten Werkzeuge und MCP-Server in Ihrem üblichen Prüfzyklus durch:

  • Wird die Anbindung noch gebraucht? Wenn nein: deaktivieren.
  • Stimmen die Rechte noch mit der Aufgabe überein, oder sind sie inzwischen zu weit?
  • Sind die Beschränkungen im Tab Zugriff noch richtig, oder hat sich der Nutzerkreis verschoben?
  • Existiert das technische Konto im Zielsystem noch, und ist sein Kennwort aktuell?

Was tatsächlich genutzt wird, zeigt das Protokoll des Zielsystems — ein weiterer Grund für das eigene technische Konto.

  • Eigenes technisches Konto je Anbindung, sprechend benannt
  • Nur lesender Zugriff, sofern Schreiben nicht ausdrücklich gebraucht wird
  • Datenumfang eng geschnitten: Views statt Tabellen, Projektordner statt Laufwerk
  • Werkzeugzugriff je Benutzer bewusst beschränkt statt „alle aktiven Werkzeuge“ belassen — und bedacht, dass Agenten davon nicht erfasst werden
  • Nur Quellen angebunden, deren Inhalte als vertrauenswürdig gelten
  • Zugangsdaten im Kennwortturnus erfasst
  • Anbindungen im Prüfzyklus aufgeführt