Guardrails & Agenten-Schutz
Wie OpenCognit gefährliche Befehle sperrt oder zur Freigabe anhält — bei deinen Eingaben und bei dem, was Agenten selbst ausführen.
KI-Agenten führen Befehle aus. Meistens harmlos — aber ein git reset --hard, ein rm -rf oder
ein unbedachter git push kann Arbeit vernichten oder etwas veröffentlichen. Guardrails sind
Regeln, die solche Befehle erkennen, bevor sie laufen.
Drei Stufen
| Stufe | Was passiert | Beispiele (mitgeliefert) |
|---|---|---|
| Block | Der Befehl wird abgelehnt. | git reset --hard, rm -rf /, git clean -fdx, DROP TABLE, TRUNCATE |
| Freigabe | Der Befehl wartet, bis du ihn in OpenCognit erlaubst. | git push, git push --force, npm publish, Deployments, Datenbank-Migrationen, curl … | sh |
| Warnung | Der Befehl läuft, du bekommst einen Hinweis. | sudo |
Alle Regeln findest und änderst du unter Einstellungen → Guardrails. Eine Regel ist ein regulärer Ausdruck (Groß-/Kleinschreibung egal); eigene Regeln kannst du hinzufügen.
Wo die Guardrails greifen
1. Bei deinen Eingaben
Alles, was du oder die Warteschlange an ein Terminal schickst, wird vor dem Absenden geprüft — auch mehrzeiliges Einfügen, Zeile für Zeile.
2. Bei Befehlen, die ein Agent selbst ausführt
Das ist der wichtigere Teil: Ein Agent tippt seine Befehle nicht in dein Terminal, er führt sie selbst aus. Damit auch diese geprüft werden, startet OpenCognit jede Session von Claude Code, Codex und Gemini mit einem kleinen Prüf-Hook (alle drei CLIs bieten dafür eine Schnittstelle):
- Bevor Claude einen Shell-Befehl ausführt, fragt es den Hook.
- Der Hook fragt OpenCognit — über eine lokale Verbindung, nur für diese Session gültig.
- OpenCognit prüft den Befehl gegen deine Regeln:
- Block → Claude bekommt eine Absage mit Begründung und der Bitte, die Sperre nicht zu umgehen.
- Freigabe → Claude wartet. Im Terminal erscheint eine Karte mit Erlauben (einmal), Für Session erlauben und Ablehnen; zusätzlich kommt eine Benachrichtigung.
- Nichts gefunden → OpenCognit mischt sich nicht ein; Claude fragt wie gewohnt selbst.
Ist OpenCognit nicht erreichbar, fragt Claude selbst nach — ein Befehl wird nie stillschweigend
durchgewunken. Deine eigene Claude-Konfiguration (~/.claude) bleibt unverändert; der Hook gilt
nur für Sessions, die OpenCognit startet.
Codex und Gemini: Gemini bekommt eine eigene Einstellungsdatei, Codex den Hook beim Start —
deine Konfiguration (~/.gemini, ~/.codex) bleibt unverändert. Weil Codex jeden Hook sonst einmal
bestätigt haben will, startet OpenCognit ihn mit dem Schalter, der diese Bestätigung für diesen einen
Start überspringt. Codex und Gemini kennen im Hook kein „Nachfragen“ — dort wird eine Freigabe-Regel
zu einer Absage mit Begründung, solange du nicht in der App erlaubst.
Derselbe Hook meldet nach jedem Lesen oder Ändern einer Datei kurz an OpenCognit — so sieht der Kosmos live, woran die Agenten arbeiten.
Abschaltbar unter Einstellungen → Guardrails → „Auch Befehle der Agenten prüfen“ (Standard: an). Die Änderung gilt für neu gestartete Sessions.
3. In Threads
In Threads läuft jede Aktion des Agenten ohnehin über eine Freigabe-Karte. Die Guardrails kommen davor: Gesperrtes wird gar nicht erst angeboten, Freigabepflichtiges wird immer gefragt — auch wenn du das Werkzeug sonst „immer erlaubt“ hast.
Geheimnisse im Commit
Bevor ein Agent (Claude-Session oder Thread) git commit ausführt, durchsucht OpenCognit die
Änderungen, die in den Commit gehen — bei git commit -a oder vorherigem git add auch die noch
nicht vorgemerkten und neuen Dateien. Gesperrt wird bei:
- Bekannten Schlüsseln: Anthropic, OpenAI, GitHub, GitLab, Slack, AWS, Google, Stripe
- Privaten Schlüsseln (
-----BEGIN … PRIVATE KEY-----) und Kennwörtern in Verbindungs-URLs (postgres://user:kennwort@…) - Fest eingetragenen Geheimnissen wie
API_KEY = "…"mit einem zufällig aussehenden Wert — Platzhalter wieyour-api-keyoderprocess.env.TOKENlösen nichts aus - Heiklen Dateien:
.env(Vorlagen wie.env.examplesind erlaubt), SSH-Schlüssel,*.pem,credentials.json,.npmrc
Der Agent erfährt, in welcher Datei was gefunden wurde — der Schlüssel selbst wird dabei nie angezeigt oder protokolliert.
Schutz vor Umgehung
Die Regeln prüfen den Befehl so, wie die Shell ihn ausführen würde — nicht nur den Text, der dasteht:
- Verkettet:
npm test && git push→ beide Teile werden geprüft - Verpackt:
bash -c "…",sh -lc '…',eval "…",$(…)und Backticks - Verschleiert:
g"i"t,\git,/usr/bin/git,sudo/env/timeoutdavor,git -C pfad -c … reset --hard - Über Variablen:
X=reset; git $X --hard - Kodiert: Wird dekodierter Inhalt direkt ausgeführt (
… | base64 -d | sh), ist nicht zu erkennen, was läuft — das braucht immer deine Freigabe.
Protokoll
Jede Sperre und jede Freigabe landet im lokalen Ereignisprotokoll (Geheimnisse geschwärzt). Die Benachrichtigungsglocke oben rechts zeigt offene Freigaben.
Ganz abschalten
Unter Einstellungen → Guardrails → „Guardrails aktiv“ schaltest du alles auf einmal ab: keine Regel greift, kein Commit-Scan — Agenten führen alles ungeprüft aus. Gedacht für Umgebungen, in denen nichts kaputtgehen kann (z. B. eine Wegwerf-VM). Der Kosmos zeigt die Dateizugriffe trotzdem weiter.
Grenzen
- Der Agenten-Hook gilt für Claude Code, Codex und Gemini. Für Kimi und Hermes im Terminal greifen die Guardrails bei deinen Eingaben; in Threads (Kimi, Hermes) über die Freigabe-Karten.
- Was in einer Skriptdatei steht, die der Agent erst schreibt und dann startet, sehen die Regeln nicht. Guardrails schützen vor Versehen und einfachen Tricks, nicht vor jeder Absicht.
- Der Commit-Scan erkennt eindeutige Muster. Ein Kennwort wie
hallo123im Klartext fällt nicht auf. - Guardrails ersetzen kein Backup und keinen Blick auf den Diff vor dem Commit.