Der Kern von Whiskers ist kein weiteres Dashboard — es ist die Governance-Schicht zwischen deiner Infrastruktur und denjenigen, die sie bedienen, Mensch oder KI. Statt eine Shell herauszugeben, stellt Whiskers explizite Werkzeuge bereit, jedes begrenzt durch Berechtigungen, geprüft durch im Code erzwungene Guardrails und — wenn es darauf ankommt — zurückgehalten für deine Freigabe.
Das Problem, das es löst
Einer KI Infrastruktur zu überlassen bedeutet meist, ihr einen SSH-Key oder eine Shell zu geben. Diese Zugangsdaten sind God Mode: alles möglich, selten ablaufend, und fällt der Controller, fallen alle Server mit. Prompt-Regeln (“bitte nichts löschen”) sind keine Kontrolle — das Modell kann sie ignorieren, jailbreaken oder schlicht falsch liegen.
Wie Governance funktioniert
1 · Berechtigungen — was ein Akteur versuchen darf
Jeder MCP-API-Key hat eine Stufe: Read, Write oder Admin, oder eine explizite Werkzeugliste. Ein Read-Key darf inspizieren und analysieren, aber nichts ändern. Gib einem Agenten so wenig wie möglich.
2 · Explizite Werkzeuge statt Shell
Akteure rufen benannte Fähigkeiten auf (“Container neu starten”, “CVEs auflisten”), nie eine beliebige Kommandozeile. Die Menge ist endlich, beschrieben und rechte-bewertet — es gibt keine “führe alles aus”-Hintertür.
3 · Guardrails — Allow / Confirm / Block
Guardrails sind eine Richtlinie, die serverseitig am Werkzeug-Boundary geprüft wird — nicht im Prompt. Pro aktivem Preset ist jedes Werkzeug Allow (läuft), Confirm (hält für einen Menschen an) oder Block (läuft nie). Weil es im Code erzwungen wird, redet sich auch ein gejailbreaktes oder irrendes Modell nicht daran vorbei.
4 · Freigaben (Human-in-the-Loop)
Ein Confirm-Werkzeug hält die Ausführung an und erzeugt eine Freigabe mit Akteur, Werkzeug, Zielserver und -workload, Parametern (Secrets redigiert), der auslösenden Regel, Begründung und Ablauf. Du gibst frei oder lehnst ab; die Aktion läuft genau einmal und nur mit den genehmigten Parametern — oder gar nicht.
5 · Secret-Redaction
Sensible Werte werden maskiert, bevor irgendetwas geloggt oder gespeichert wird — Tokens und Passwörter erscheinen weder in der Freigabe-Karte noch in History oder Audit.
6 · Agent-History & Audit-Log
Die Agent-History hält jeden Werkzeug-Aufruf einer KI fest: Werkzeug, Akteur, Guardrail-Entscheidung, redigierte Parameter, Ergebnis, Dauer. Das Audit-Log hält Nutzer-Aktionen fest. Zusammen beantworten sie wer was an welchem Ziel getan hat und was dabei herauskam — manipulationssicher, mit einer Correlation-ID, die Aufruf, Freigabe und Aufzeichnung verknüpft.
Beispiel: einen ungesunden Workload neu starten
- Ein Container ist ungesund. Der Agent liest Status und Logs mit einem Read-Key.
- Der Agent schlägt einen Neustart vor. Der aktive Guardrail bewertet das Restart-Werkzeug mit Confirm — nichts läuft.
- Whiskers erzeugt eine Freigabe: Akteur, Werkzeug, Ziel, redigierte Parameter, Regel, Begründung, Ablauf.
- Du gibst frei. Whiskers führt nur die genehmigte Aktion aus und prüft danach den Workload.
- Agent-History und Audit-Log zeigen die vollständige Kette, verlinkt zur Freigabe.
Prompt-Regel vs. serverseitige Policy
Das ist der entscheidende Unterschied: eine Prompt-Regel ist eine Bitte an das Modell und kann ignoriert werden. Eine serverseitige Policy wird von Whiskers erzwungen — egal, was das Modell “will”. Whiskers legt die Kontrollen an die zweite Stelle.
Einrichten → Sicherheits-Architektur
So sieht das im Produkt aus
