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](/hilfe/mcp-einrichten)).

## 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.