5.5 KiB
Zugänge verwalten
Wer im Projekt die Rolle admin hat, sieht in der Seitenleiste den Punkt
Zugänge. Dort werden Keys angelegt und zurückgezogen.
Anlegen: Name und Rolle wählen. Der Name sollte sagen, wer oder was den
Key benutzt, zum Beispiel anna-cline oder ci-pipeline. Er erscheint als
Autor an jedem Eintrag und im Protokoll.
Der Key wird genau einmal angezeigt, zusammen mit fertigen Konfigurationsblöcken für Claude Code, Cline und OpenCode. Munin speichert nur eine Prüfsumme. Geht der Key verloren, lässt er sich nicht wiederherstellen. Dann einfach einen neuen anlegen und den alten zurückziehen.
Zurückziehen: Der Key funktioniert sofort nicht mehr, auch laufende Browser-Sitzungen mit diesem Key enden. Im Protokoll bleibt er mit seinem Namen erhalten, damit sich weiterhin nachvollziehen lässt, was er geschrieben hat.
Ungenutzte Keys: Ein aktiver Key, der seit über 90 Tagen nicht benutzt wurde, trägt die Marke ungenutzt. Über der Tabelle steht dann ein Hinweis. Wurde ein Key noch nie benutzt, zählt das Anlegedatum. Ein frisch angelegter Key ist also nicht sofort markiert. Solche Keys stammen oft von Personen, die das Team gewechselt haben, oder von abgeschalteten Pipelines. Jeder davon ist ein offener Zugang. Wenn niemand mehr weiß, wofür er da ist, am besten zurückziehen.
Workspace-Admin
Ein Workspace-Admin kümmert sich um die Projekte einer ganzen Abteilung, ohne
dafür Plattform-Admin sein zu müssen. Er meldet sich mit einem eigenen Token
(beginnt mit wa_) in der Weboberfläche an und landet direkt unter
Projekte → Verwalten….
| Darf | Darf nicht |
|---|---|
| Projekte des eigenen Workspace anlegen, umbenennen und löschen | Einträge schreiben, löschen oder importieren |
| Zugänge aller Projekte dort anlegen und zurückziehen | das Schreibbudget ändern oder auf die Platte des Servers exportieren |
| alle Projekte dort lesen, samt Protokoll und Nutzung | andere Workspaces sehen |
| einzelne Projekte oder den ganzen Workspace als ZIP herunterladen | |
| sich über MCP verbinden (das Token taugt dafür nicht) |
Einträge ändern Teams über ihre eigenen Keys, damit im Protokoll eindeutig steht, wer etwas geschrieben hat. Ein Workspace-Admin, der selbst mitarbeiten will, legt sich dafür einen Key im jeweiligen Projekt an.
Weil er Zugänge anlegen darf, kann ein Workspace-Admin sich faktisch Zugriff auf jedes Projekt seines Workspace verschaffen. Die Rolle gehört deshalb nur an Personen, denen die Abteilung ohnehin alle ihre Projekte anvertraut. Was er tut, steht mit seinem Namen im Protokoll.
Workspace-Admins legt der Plattform-Admin an und zieht sie zurück. Ein zurückgezogenes Token gilt sofort nicht mehr, auch eine laufende Sitzung endet.
Welche Rolle für wen?
| Wer | Empfohlene Rolle |
|---|---|
| Agent, der ohne Aufsicht läuft (z. B. in einer Pipeline) | read |
| Agent, mit dem ein Mensch zusammenarbeitet | write |
| Teammitglied im Browser | write |
| Verantwortliche für das Projekt | admin |
Faustregel: Schreibrecht nur dort, wo jemand die Einträge auch durchsieht.
Ein Key je Person und je Agent
Keys zu teilen ist bequem, aber dann steht im Protokoll nur noch „team-key“. Außerdem lässt sich ein geteilter Key nicht zurückziehen, ohne alle anderen auszusperren. Keys kosten nichts, also besser einen mehr anlegen.
Gehört ein Key in eine Konfigurationsdatei im Repository, dann nicht im Klartext, sondern über eine Umgebungsvariable (siehe Agent anbinden).
Schreibbudget
Jedes Projekt darf über MCP nur eine begrenzte Zahl an Schreibvorgängen je
Stunde ausführen (remember und forget zusammen, standardmäßig 1.000). Lesen
ist nie begrenzt. Das Budget gilt für das ganze Projekt, nicht je Key.
Das ist ein Sicherheitsnetz gegen Agenten, die in einer Schleife hängen. Im normalen Betrieb wird es nicht erreicht. Ist es erschöpft, bekommt der Agent die Anweisung, abzubrechen und das zu melden. Die Weboberfläche ist davon nicht betroffen. Eine andere Obergrenze für ein Projekt kann nur der Plattform-Admin einstellen.
Protokoll
Unter Protokoll steht, wer im Projekt wann geschrieben oder gelöscht hat, wer sich angemeldet hat (auch Fehlversuche) und wann Zugänge angelegt oder zurückgezogen wurden. Einträge werden nach 90 Tagen gelöscht, weil sie Namen und Adressen enthalten.
Was Agenten suchen, steht getrennt im Suchprotokoll und wird nach 30 Tagen gelöscht. Die häufigsten Anfragen ohne Treffer zeigt die Nutzungsseite allen mit Zugang zum Projekt, auch mit Leserecht. Eine Anfrage kann verraten, woran jemand gerade arbeitet. Wie bei den Einträgen gilt deshalb: keine Geheimnisse hineinschreiben.
Was man beim Teilen von Wissen bedenken sollte
Keine Geheimnisse in Einträge. Passwörter, Tokens und private Schlüssel gehören in einen Passwortspeicher. Ein Eintrag darf beschreiben, wo ein Geheimnis liegt, aber nicht das Geheimnis selbst. Alles, was hier steht, landet im Kontext von KI-Agenten.
Was drinsteht, lesen Agenten als Anweisung. Wer in ein Projekt schreiben darf, schreibt damit indirekt in die Prompts aller Agenten dieses Projekts. Darum stehen Herkunft und Autor an jedem Eintrag, und darum lohnt sich der Haken Kuratiert für geprüftes Wissen. Wirkt ein Eintrag merkwürdig oder fordert er zu ungewöhnlichen Handlungen auf, sieh im Verlauf nach, wer ihn geschrieben hat.
Projekte sind voneinander getrennt. Ein Key sieht nur sein eigenes Projekt. Fremde Projekte sind für ihn nicht einmal als vorhanden erkennbar.