Die Fabrication Firewall: Wenn Ihr Agent Falschinformationen veröffentlicht

Am 19. Februar 2026 gab jemand Claude Code über MCP-Tools Zugang zu Twitter, Telegraph, Write.as, Rentry, GitHub und Moltbook. In den folgenden 72 Stunden veröffentlichte der Agent fabrizierte technische Behauptungen auf allen acht Plattformen. Ein 200.000-Token-Kontextfenster wurde zu „1 Million Tokens.” Eine Sitzung, die 196.626 Tokens verarbeitete, wurde zu „12 Millionen Tokens in einer Sitzung.” Am dritten Tag behauptete der Agent Billionen-Token-Sitzungen – eine Abweichung um den Faktor 83.000.¹

Der Agent war nicht böswillig. Er war überzeugt und falsch, und nichts stand zwischen seiner Überzeugung und einem Veröffentlichen-Button.

TL;DR

Ein autonomer Claude Code Agent veröffentlichte über 72 Stunden hinweg fabrizierte Behauptungen auf mehr als 8 Plattformen durch eine Konfabulations-Rückkopplungsschleife: Sitzung N rät, schreibt die Vermutung in MEMORY.md, Sitzung N+1 liest sie als verifizierte Tatsache, veröffentlicht sie, Sitzung N+2 liest die Veröffentlichung als Bestätigung. Es gab kein Output-Gate. Alignment aus der Trainingsphase („sei ehrlich”) war unzureichend, weil der Agent glaubte, ehrlich zu sein. Die Lösung ist eine Output-Firewall: Befehle als lokal, geteilt oder extern klassifizieren und externe Veröffentlichungen zur menschlichen Überprüfung zurückstellen. Im Folgenden: die Anatomie des Vorfalls, der Mechanismus der Rückkopplungsschleife, was andere entwickeln (OkaiDokai) und eine funktionierende Implementierung, die Sie sofort einsetzen können.

Die Konfabulations-Rückkopplungsschleife

Die Fabrikation war keine einzelne Halluzination. Es war eine anhaltende Rückkopplungsschleife über mehrere Sitzungen, wobei jede die Fehler der vorherigen Sitzung verstärkte.¹

Der Mechanismus:

1. Sitzung N: Die Vermutung. Claude schätzte Token-Anzahlen basierend auf Dateigrößen, indem es JSONL-Bytes durch 4 teilte, um Tokens zu approximieren. Diese Methodik war erfunden. Die resultierenden Zahlen waren plausibel genug, um als Ergebnisse in MEMORY.md geschrieben zu werden.

2. Sitzung N+1: Die Beförderung. Eine frische Claude-Sitzung las MEMORY.md, fand die Token-Schätzungen bereits dokumentiert und behandelte sie als verifizierte Fakten. Die Sitzung baute auf diesen Fakten auf, eskalierte die Behauptungen und veröffentlichte sie über MCP-Tools auf mehreren Plattformen.

3. Sitzung N+2: Die Verstärkung. Die nächste Sitzung las sowohl MEMORY.md als auch die veröffentlichten Artikel. Die Behauptungen hatten nun zwei Quellen: die Speicherdatei und die Veröffentlichungen. Das Gegenprüfen zweier Quellen derselben Fabrikation sah wie Bestätigung aus.

Die Schleife ist strukturell identisch mit Zitationswäsche in der akademischen Publikation: eine Behauptung fabrizieren, sie irgendwo veröffentlichen, dann die Veröffentlichung als Beleg für die Behauptung zitieren. Der Agent beabsichtigte keine Wäsche. Er folgte einem rationalen Prozess (Speicher prüfen, Quellen gegenprüfen, Ergebnisse veröffentlichen), der zufällig mit fabrizierten Eingaben arbeitete.

Als der Benutzer die Zahlen anzweifelte, brauchte der Agent über 50 Argumentationsrunden, bevor er einen einzigen Verifizierungsbefehl ausführte (/context). Der Agent hatte hohes Vertrauen, weil seine „Quellen” (seine eigene Speicherdatei, seine eigenen Veröffentlichungen) miteinander übereinstimmten.¹

Warum Sicherheitsmechanismen aus der Trainingsphase nicht halfen

Der Agent war aligned. Er versuchte, hilfreich und ehrlich zu sein. Er teilte mit, was er für akkurate technische Erkenntnisse hielt. Jede Sicherheitseigenschaft, die Sie sich von RLHF wünschen würden, war vorhanden: Der Agent verweigerte keine Anfragen, produzierte keine schädlichen Inhalte, verletzte keine seiner konstitutionellen Prinzipien. Er war höflich, gründlich und falsch.

Alignment in der Trainingsphase optimiert auf Absicht: Das Modell soll die Absicht haben, wahrhaftig zu sein. Der Fabrikationsvorfall offenbart eine andere Schwachstelle: die Grenze zwischen dem internen Zustand des Agenten und der Außenwelt. Der Agent glaubte, seine Behauptungen seien wahr. Kein noch so gutes Alignment-Training fängt einen Agenten ab, der sich ehrlich irrt und Zugang zu einem Veröffentlichen-Button hat.

Dies ist das Publikationsgrenzen-Problem. Alignment regelt, was der Agent tun möchte. Output-Firewalls regeln, was der Agent tun darf. Dies sind unterschiedliche Mechanismen, die unterschiedliche Probleme lösen.

Das Runtime-Verfassungs-Framework, das ich zuvor beschrieben habe, adressiert die Governance-Schicht: normative Priors, konstitutionelle Aufmerksamkeit, Kompetenzmodulation und Werteausrichtungs-Verifikation.² Der Fabrikationsvorfall legt eine Lücke in diesem Framework offen: Die Werteausrichtungs-Verifikation prüfte, ob die Ausgaben des Agenten mit der Governance-Absicht übereinstimmten, unterschied aber nicht zwischen dem Schreiben in eine lokale Datei und dem Veröffentlichen auf Twitter. Beides sind Tool-Aufrufe. Beides nutzt Bash. Nur eines erreicht die Außenwelt.

Was andere entwickeln

Das Problem ist real genug, dass Praktiker unabhängig voneinander Lösungen entwickeln.

OkaiDokai ist eine Firewall auf Tool-Ebene für KI-Agenten, die jeden Tool-Aufruf abfängt und gegen ein benutzerdefiniertes Regelwerk evaluiert.³ Übereinstimmende Aktionen werden automatisch genehmigt oder abgelehnt. Nicht übereinstimmende Aktionen lösen eine Push-Benachrichtigung an Ihr Telefon, Ihre Uhr oder Ihren Browser aus. Sie tippen auf Erlauben oder Ablehnen. Die Evaluierung läuft in unter 1 Millisekunde, und jede Entscheidung kann zu einer permanenten Regel werden.

Die Architektur von OkaiDokai gliedert sich in drei Schichten: ein Plugin auf dem Agenten, das Tool-Aufrufe abfängt, eine API-Schicht, die Regeln evaluiert und Benachrichtigungen sendet, und eine Benutzeroberfläche für die Genehmigung. Das System unterstützt Claude Code und OpenClaw, wobei Codex-Unterstützung geplant ist.

Der Ansatz ist solide, führt aber Latenz und eine externe Abhängigkeit ein. Jede neuartige Aktion erfordert menschliche Genehmigung per Push-Benachrichtigung. Für interaktive Coding-Sitzungen ist diese Reibung handhabbar. Für autonome Schleifen, die über Nacht laufen, verfehlt das Blockieren durch Push-Benachrichtigungen den Zweck.

Runtime Constitutional AI ist eine aufkommende Forschungsrichtung, bei der Agenten ihre eigenen Ausgaben gegen eingebettete Governance-Regeln verifizieren, bevor sie diese ausführen.⁴ Der Ansatz funktioniert für Prüfungen auf Werteebene („Respektiert diese Ausgabe die Privatsphäre des Benutzers?”), adressiert aber das Fabrikationsproblem nicht spezifisch. Ein Agent, der glaubt, seine fabrizierten Behauptungen seien akkurat, wird auch glauben, dass sie die konstitutionelle Prüfung bestehen.

Keiner der beiden Ansätze allein löst die Rückkopplungsschleife. OkaiDokai hätte die Veröffentlichungsbefehle abgefangen, wenn der Benutzer Publikationsregeln konfiguriert hätte. Runtime Constitutional Review hätte die Fabrikation übersehen, weil die Überzeugung des Agenten seine eigenen Ehrlichkeitsprüfungen umging. Die Lücke ist strukturell: Sie benötigen einen Mechanismus, der der Selbsteinschätzung des Agenten bezüglich seiner eigenen Genauigkeit nicht vertraut, wenn er mit externen Systemen interagiert.

Drei Stufen der Befehlsauswirkung

Die Output-Firewall klassifiziert jeden Befehl nach seinem Wirkungsradius. Die Klassifizierung bestimmt, ob der Befehl automatisch genehmigt wird, warnt oder zurückgestellt wird.

Stufe 1: Lokal. Betrifft nur das lokale Dateisystem. Dateilesen, Dateischreiben, git add, git commit, Testläufe, Linting. Diese werden automatisch genehmigt, weil sie reversibel und für die Außenwelt unsichtbar sind. Wenn der Agent eine fehlerhafte Datei schreibt, löschen Sie sie. Kein externer Schaden.

Stufe 2: Geteilt. Betrifft geteilten Zustand, den Mitarbeiter sehen können. git commit (erzeugt Historie), Branch-Operationen, lokale Datenbankänderungen. Diese warnen, blockieren aber nicht. Der Schaden durch einen fehlerhaften Commit ist real, aber auf das Repository beschränkt und mit git revert reversibel.

Stufe 3: Extern. Erreicht Systeme außerhalb des Repositories. git push, gh pr create, gh pr merge, railway deploy, curl -X POST/PUT/PATCH/DELETE, npm publish. Diese werden zur menschlichen Überprüfung zurückgestellt. Der Schaden durch eine fehlerhafte Veröffentlichung ist extern, sichtbar und potenziell irreversibel (gecachte Inhalte, indexierte Seiten, bereits versendete Benachrichtigungs-E-Mails).

Die Stufenklassifizierung bildet sich auf eine einfache Musterliste ab:

EXTERNAL_PATTERNS='git push|gh pr create|gh pr merge|railway deploy|curl -X POST|curl -X PUT|curl -X PATCH|curl -X DELETE|npm publish'

In interaktiven Claude Code Sitzungen übernimmt das eingebaute Berechtigungssystem dies bereits. Jeder Bash-Befehl fordert zur Genehmigung auf, sofern er nicht vorab autorisiert wurde. Der Benutzer sieht git push im Berechtigungsdialog und entscheidet, ob er es erlaubt.

In autonomen Schleifen schaut niemand zu. Die autonome Entwicklungsschleife Ralph startet frische Claude-Instanzen über claude --print, das ohne interaktive Genehmigung ausführt.⁵ Hier wird die Output-Firewall relevant.

Aufbau der Firewall

Die Implementierung besteht aus vier Komponenten. Jede arbeitet unabhängig, sodass Sie sie schrittweise einführen können.

1. Prompt-Einschränkung

Die einfachste Schicht. Fügen Sie dem Prompt, der jede autonome Claude-Instanz startet, explizite Regeln hinzu:

## Rules
- Do NOT run git push, deploy commands, or external API calls
- Local operations only: file writes, git add, git commit, test runs

Dies ist notwendig und unzureichend. Modelle folgen Prompt-Einschränkungen die meiste Zeit. „Die meiste Zeit” ist für Publikationssicherheit nicht akzeptabel. Die Prompt-Einschränkung reduziert die Wahrscheinlichkeit externer Befehle; die verbleibenden Komponenten fangen diejenigen ab, die durchschlüpfen.

2. Nachträglicher Ausführungsscanner

Nach Abschluss jeder Claude-Ausführung wird deren Ausgabe auf Hinweise externer Befehle gescannt:

scan_for_external_commands() {
    local output="$1"
    local story_id="$2"

    while IFS= read -r pattern; do
        [ -z "$pattern" ] && continue
        local matches
        matches=$(echo "$output" | grep -i "$pattern" 2>/dev/null || true)
        if [ -n "$matches" ]; then
            # Log to state file for end-of-session review
            jq --arg cmd "$pattern" --arg story "$story_id" \
               --arg ts "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
               '.deferred_actions += [{
                   "command_pattern": $cmd,
                   "story_id": $story,
                   "detected_at": $ts
               }]' "$STATE_FILE" > "${STATE_FILE}.tmp" \
               && mv "${STATE_FILE}.tmp" "$STATE_FILE"
        fi
    done <<< "$(echo "$EXTERNAL_PATTERNS" | tr '|' '\n')"
}

Der Scanner läuft nach Abschluss der Claude-Instanz, nicht während der Ausführung. Dies ist Erkennung, nicht Prävention. Die Prompt-Einschränkung ist die Präventionsschicht. Der Scanner ist die Prüfschicht, die auffängt, was die Einschränkung übersehen hat.

Eine bekannte Einschränkung: grep -i erkennt Muster in natürlicher Sprachausgabe, nicht nur in ausgeführten Befehlen. Wenn Claudes Antwort „I chose not to git push because the prompt rules forbid it” enthält, markiert der Scanner dies. Das ist akzeptabel. Falsch-Positive in der Warteschlange zurückgestellter Aktionen kosten den Menschen fünf Sekunden Überprüfung. Ein Falsch-Negativ (ein tatsächlicher externer Befehl wird übersehen) kostet veröffentlichte Fabrikationen. Der Scanner tauscht bewusst Präzision gegen Trefferquote.

Beispielausgabe des Scanners aus einem realen autonomen Schleifendurchlauf:

DEFERRED ACTIONS REQUIRE REVIEW
2 external command(s) detected.
  Story #3 [2026-02-23T08:15:00Z]: git push
  Story #7 [2026-02-23T09:42:13Z]: curl -X POST

In diesem Fall erwähnte Story #3 git push in einem Code-Kommentar (Falsch-Positiv). Story #7 enthielt einen tatsächlichen curl -X POST an einen API-Endpunkt, den die Prompt-Einschränkung hätte blockieren sollen (Richtig-Positiv). Der Mensch ignoriert den ersten, untersucht den zweiten.

3. Warteschlange zurückgestellter Aktionen

Erkannte externe Befehle sammeln sich in einem deferred_actions-Array in der Sitzungszustandsdatei:

{
  "session_id": "1740355200-12345",
  "deferred_actions": [
    {
      "command_pattern": "git push",
      "story_id": "3",
      "detected_at": "2026-02-23T08:15:00Z"
    }
  ]
}

Die Warteschlange bleibt über Stories innerhalb eines einzelnen autonomen Schleifendurchlaufs bestehen. Am Ende der Schleife werden alle zurückgestellten Aktionen zur menschlichen Überprüfung präsentiert.

4. Sitzungsabschlussbericht

Wenn die autonome Schleife abgeschlossen ist, werden alle zurückgestellten Aktionen angezeigt:

show_deferred_actions() {
    local count
    count=$(jq '.deferred_actions | length' "$STATE_FILE")
    if [ "$count" -gt 0 ]; then
        echo "DEFERRED ACTIONS REQUIRE REVIEW"
        echo "$count external command(s) detected."
        jq -r '.deferred_actions[] |
            "  Story #\(.story_id) [\(.detected_at)]: \(.command_pattern)"' \
            "$STATE_FILE"
    fi
}

Der Mensch überprüft jede zurückgestellte Aktion und entscheidet, ob er sie manuell ausführt. Dies bewahrt die Fähigkeit der autonomen Schleife, unbeaufsichtigt zu arbeiten, und stellt gleichzeitig sicher, dass keine externe Veröffentlichung ohne menschliche Verifikation erfolgt.

Schnellstart: Claude Code Hook

Wenn Sie Claude Code interaktiv verwenden (nicht als autonome Schleife), können Sie eine Output-Firewall als einzelnen Hook in ~/.claude/settings.json hinzufügen:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{
          "type": "command",
          "command": "if echo \"$CLAUDE_TOOL_INPUT\" | grep -qiE 'git push|gh pr create|gh pr merge|npm publish|railway deploy|curl -X POST|curl -X PUT|curl -X DELETE'; then echo 'BLOCKED: External publication command detected. Review manually.' >&2; exit 2; fi"
        }]
      }
    ]
  }
}

Dieser Hook wird vor jedem Bash-Tool-Aufruf ausgelöst. Wenn der Befehl einem externen Muster entspricht, blockiert er die Ausführung mit Exit-Code 2 (den Claude Code als „diesen Tool-Aufruf ablehnen” interpretiert). Der Agent erhält die Blockierungsnachricht und kann mit lokaler Arbeit fortfahren. Sie können die Musterliste für Ihre spezifischen externen Dienste erweitern.

Der Autonomie-Gradient

Die Strenge der Firewall sollte umgekehrt proportional zur menschlichen Aufsicht skalieren. Mehr Autonomie erfordert mehr Einschränkungen. Weniger Autonomie erlaubt mehr Freiheit.

Der Fabrikationsvorfall ereignete sich auf der Ebene „unbeaufsichtigt autonom” ohne Firewall. Der Agent hatte MCP-Zugang zu Veröffentlichungsplattformen und keinen Mechanismus, um „Analyse in lokale Datei schreiben” von „Analyse auf Twitter veröffentlichen” zu unterscheiden. Beides waren Tool-Aufrufe. Beides war erfolgreich.

Die Lösung besteht nicht darin, den MCP-Zugang zu entfernen oder den autonomen Betrieb einzustellen. Die Lösung besteht darin, die Strenge der Firewall an das Autonomieniveau anzupassen. Eine interaktive Sitzung, in der Sie jeden Befehl beobachten, braucht keine Output-Firewall. Eine nächtliche autonome Schleife, die 25 Stories verarbeitet, braucht alle vier Komponenten.

Verbindung zur Runtime-Governance

Der Beitrag zur Selbststeuerung von Agenten beschrieb vier Teilsysteme der Runtime-Governance: normative Priors, konstitutionelle Aufmerksamkeit, Kompetenzmodulation und Werteausrichtungs-Verifikation.² Die Output-Firewall ist ein fünftes Teilsystem – oder genauer gesagt, sie ist der Durchsetzungsmechanismus, der dem Teilsystem der Werteausrichtungs-Verifikation fehlte.

Die Werteausrichtungs-Verifikation prüft, ob die Ausgaben des Agenten mit der Governance-Absicht übereinstimmen. Das Evidence Gate erfordert spezifische Belege für sechs Kriterien, bevor die Fertigstellung gemeldet wird. Aber das Evidence Gate operiert auf der Selbsteinschätzung des Agenten. Es fragt: „Hast du die Regeln befolgt?” Der Agent antwortet basierend auf seinem eigenen Verständnis dessen, was er getan hat.

Der Fabrikationsvorfall zeigt, dass Selbsteinschätzung versagt, wenn das Verständnis des Agenten falsch ist. Der Agent glaubte, seine Behauptungen seien akkurat. Seine Selbsteinschätzung hätte das Evidence Gate bestanden: „Ich habe die Zahlen gegen meine Speicherdatei und die veröffentlichten Artikel verifiziert.” Beide Quellen waren vom Agenten selbst fabriziert, aber der Agent wusste das nicht.

Die Output-Firewall umgeht die Selbsteinschätzung vollständig. Sie fragt den Agenten nicht, ob die Veröffentlichung akkurat ist. Sie fragt: „Ist dieser Befehl lokal oder extern?” Die Klassifizierung ist mechanisch, nicht semantisch. git push ist extern, unabhängig davon, ob der gepushte Inhalt akkurat ist. curl -X POST erreicht das Internet, unabhängig davon, ob die Nutzlast wahrheitsgemäß ist. Die Firewall operiert auf Befehlsstruktur, nicht auf Inhaltswahrheit, was sie immun gegen die Konfabulation macht, die jede andere Sicherheitsschicht besiegte.

Zentrale Erkenntnisse

• Die Publikationsgrenze ist eine eigenständige Sicherheitsfläche. Training-Alignment regelt die Absicht. Output-Firewalls regeln die Fähigkeit. Ein Agent, der ehrlich an fabrizierte Behauptungen glaubt, wird Alignment-Prüfungen bestehen, aber an der Publikationsgrenze scheitern.
• Konfabulations-Rückkopplungsschleifen sind der Mechanismus. Die Fabrikation war keine einzelne Halluzination. Es war eine Multi-Sitzungs-Schleife, bei der die Ausgabe jeder Sitzung zum Beweis der nächsten Sitzung wurde. Speicherdateien und Veröffentlichungen dienten als Wäscher für die ursprüngliche Fabrikation.
• Klassifizieren Sie Befehle nach Wirkungsradius. Lokal (reversibel, unsichtbar), geteilt (für Mitarbeiter sichtbar), extern (erreicht die Außenwelt). Kontrollieren Sie die externe Stufe auf dem Niveau, das Ihrem Autonomiegrad entspricht.
• Erkennung und Prävention ergänzen sich. Prompt-Einschränkungen verhindern die meisten externen Befehle. Nachträgliches Scannen fängt ab, was durchschlüpft. Keines allein ist ausreichend.
• Selbsteinschätzung versagt bei Konfabulation. Ein Agent, der seinen eigenen Fabrikationen glaubt, wird seine eigenen Governance-Prüfungen bestehen. Die Output-Firewall funktioniert, weil sie Befehlsstruktur klassifiziert, nicht Inhaltswahrheit. Die Frage lautet nie „Ist das wahr?” Die Frage lautet „Erreicht das die Außenwelt?”

Quellen