Guardrails & Agenten-Schutz

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

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, Gemini, Kimi und Hermes mit einem kleinen Prüf-Hook (alle fünf 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.

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.

Kimi und Hermes: Beide lesen ihre Hooks nur aus der eigenen Konfigurationsdatei. OpenCognit startet sie darum mit einem eigenen Konfig-Ordner (KIMI_CODE_HOME bzw. HERMES_HOME): Darin zeigt alles per Verknüpfung auf deinen echten Ordner — Login, Sessions, Verlauf, Skills —, nur die Konfigurationsdatei ist eine Kopie mit dem Prüf-Hook. Deine eigene Konfiguration (~/.kimi-code, ~/.hermes) bleibt unverändert. Erneuert die CLI unterwegs ihren Login, übernimmt OpenCognit das beim Beenden in deinen echten Ordner — du bleibst also auch außerhalb von OpenCognit angemeldet. Auch Kimi und Hermes kennen im Hook kein „Nachfragen“ (Freigabe-Regel → Absage, bis du in der App erlaubst), und beide warten nur begrenzt auf den Hook (Kimi 10, Hermes 5 Minuten) — entscheidest du nicht rechtzeitig, wird der Befehl abgelehnt, nie durchgelassen.

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 → Sicherheit → „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.

Schutzziele

Manche Stellen haben mit der eigentlichen Arbeit eines Agenten fast nie zu tun, können aber später unbemerkt Code ausführen oder Zugangsdaten preisgeben. Will ein Agent dort schreiben, braucht das immer eine Freigabe – egal ob per Shell-Befehl oder mit seinem Datei-Werkzeug (Claude Code „Write/Edit“, Codex „apply_patch“, Gemini „write_file“):

Normale Projektdateien (auch .env im Projekt) sind nicht betroffen, und rm -rf node_modules oder dist im Projekt laufen ohne Rückfrage. „Für Session erlauben“ gilt je Schutzziel. Das Lesen von Zugangsdaten regelt der nächste Abschnitt.

Geheimnisse schützen

Ein Agent, den ein präparierter Text steuert (eine README, ein Issue, eine Webseite), muss Schlüssel nicht ändern – es reicht, sie zu lesen und wegzuschicken. Darum fragt die App auch hier vorher nach:

Nicht betroffen: Schlüssel benutzen (ssh -i …, git push), Ordner auflisten (ls ~/.ssh), öffentliche Schlüssel (*.pub), die .env des eigenen Projekts, Herunterladen.

Zugangsdaten aus der Umgebung zurückhalten: Agenten-Terminals bekommen keine Umgebungsvariablen, die nach Zugangsdaten aussehen (AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, DATABASE_URL, STRIPE_SECRET_KEY …). Die Logins der CLIs selbst (ANTHROPIC_API_KEY, OPENAI_API_KEY, GEMINI_API_KEY …) bleiben, deine eigenen Terminals auch. Der Reiter Einstellungen → Sicherheit zeigt, welche Variablen auf deinem Rechner betroffen sind – nur die Namen, nie die Werte.

Beide Schalter liegen unter Einstellungen → Sicherheit und sind von Anfang an eingeschaltet.

Paket-Schutz

Agenten installieren gern Pakete — und erfinden dabei manchmal Namen, die es gar nicht gibt. Genau solche Namen registrieren Angreifer, ebenso Verwechslungen bekannter Pakete. Bevor ein Agent mit npm, pnpm, yarn, bun, npx, pip, uv, poetry oder pipx installiert, prüft OpenCognit jedes Paket — auch verpackt in bash -c "…":

Trifft etwas zu, hält ein Freigabe-Banner die Installation an und nennt die Gründe. Bekannte Pakete (React, Express, Requests …) werden nicht abgefragt; für unbekannte fragt OpenCognit kurz bei npm bzw. PyPI nach (nur der Paketname, höchstens 3 Sekunden). Ohne Netz zählt nur der Namensvergleich. Geprüft werden Befehle der Agenten — was du selbst tippst, bleibt unberührt.

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.

Ganz abschalten

Unter Einstellungen → Sicherheit → „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.

Prüfprotokoll

Unter Einstellungen → Prüfprotokoll steht, was die Guardrails getan haben — neueste zuerst: gesperrt, Geheimnis im Commit, zurückgehalten, freigegeben (einmal oder für die Session) und abgelehnt. Zu jedem Eintrag siehst du die Regel, den Befehl bzw. die Eingabe (Geheimnisse geschwärzt), woher er kam (deine Eingabe, Befehl des Agenten oder Thread), den Agenten und den Projektordner. Mit den Filtern Gesperrt und Freigaben grenzt du die Liste ein.

Das Protokoll liest das lokale Eventlog — es verlässt deinen Rechner nicht und wird mit dessen Aufbewahrungsdauer (Einstellungen → Daten) aufgeräumt.

Offene Freigaben zeigt zusätzlich die Benachrichtigungsglocke oben rechts.

Grenzen

• Der Agenten-Hook gilt für Claude Code, Codex, Gemini, Kimi und Hermes im Terminal; in Threads greifen die Guardrails über die Freigabe-Karten.
• Erst laden, später ausführen: Lädt ein Agent eine Datei aus dem Netz (curl -o, wget, curl … > datei) und will sie später in derselben Session ausführen (bash, sh, ./datei, python …), braucht das eine Freigabe („Heruntergeladenes Skript“) — auch wenn beide Befehle einzeln harmlos aussehen.
• Was in einer Skriptdatei steht, die der Agent selbst schreibt und dann startet, sehen die Regeln nicht.
• Die Schutzziele greifen bei Kimi und Hermes vorerst nur für Shell-Befehle, nicht für deren Datei-Werkzeuge. Das Lesen von Zugangsdaten mit dem eigenen Lese-Werkzeug fängt die App bei Claude Code, Gemini und Kimi ab; Codex und Hermes lesen über die Shell, die geprüft wird.
• Liest ein Programm Zugangsdaten selbst (z. B. aws s3 cp mit ~/.aws/credentials), sieht das niemand außer dem Programm. Wer Agenten gar keinen Zugriff geben will, startet sie unter einem eigenen Benutzer oder in einer VM. 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.