115 lines
5.5 KiB
Markdown
115 lines
5.5 KiB
Markdown
## 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](/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.
|
|
|
|
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.
|