466f1e40af
Umsetzung der Ausbaustufen 2.1, 3.6, 3.8, 3.9, 4.1, 4.2, 4.4, 4.6, 5.1–5.4 (Details in AUSBAUSTUFEN.md). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
74 lines
3.3 KiB
Markdown
74 lines
3.3 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.
|
|
|
|
## 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 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.
|