munin/internal/hilfe/seiten/zugaenge.md

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.

Gültig bis (optional): Ein Key kann ein Ablaufdatum bekommen. Er gilt bis einschließlich dieses Tages und danach wie ein zurückgezogener, auch laufende Browser-Sitzungen enden. Sinnvoll für Zugänge auf Zeit: ein Praktikum, ein Projekt mit Enddatum, ein Test. Leer gelassen läuft der Key nie ab. In der Liste steht das Datum in der Spalte Gültig bis. Zwei Wochen vorher trägt der Key die Marke läuft bald ab, und über der Tabelle steht ein Hinweis: Wird er weiter gebraucht, einen neuen anlegen und in den Clients austauschen, bevor der alte nicht mehr gilt.

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.

Über der Tabelle lässt sich filtern: nach Vorgang (z. B. in den Papierkorb gelegt), nach Wer (dem Namen des Zugangs) und nach Zeitraum (von, bis, jeweils ganze Tage). Das beantwortet die Frage, die man bei einem Vorfall stellt: „Was hat dieser Zugang gestern gemacht?“ Die gefilterte Ansicht hat eine eigene Adresse und lässt sich weitergeben. Angezeigt werden höchstens die jüngsten 200 Vorgänge.

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.