OpenCognitOpenCognitDOCS

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

StufeWas passiertBeispiele (mitgeliefert)
BlockDer Befehl wird abgelehnt.git reset --hard, rm -rf /, git clean -fdx, DROP TABLE, TRUNCATE
FreigabeDer Befehl wartet, bis du ihn in OpenCognit erlaubst.git push, git push --force, npm publish, Deployments, Datenbank-Migrationen, curl … | sh
WarnungDer 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):

  1. Bevor Claude einen Shell-Befehl ausführt, fragt es den Hook.
  2. Der Hook fragt OpenCognit — über eine lokale Verbindung, nur für diese Session gültig.
  3. 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 wie your-api-key oder process.env.TOKEN lösen nichts aus
  • Heiklen Dateien: .env (Vorlagen wie .env.example sind 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/timeout davor, 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 hallo123 im Klartext fällt nicht auf.
  • Guardrails ersetzen kein Backup und keinen Blick auf den Diff vor dem Commit.