IronCurtain

Eine sichere* Laufzeitumgebung für autonome KI-Agenten, bei der die Sicherheitsrichtlinie aus einer für Menschen lesbaren Verfassung abgeleitet wird.

*Wenn jemand „secure“ schreibt, sollten Sie sofort skeptisch sein. Was meinen wir mit „secure“?

[!WARNING] Forschungsprototyp. IronCurtain ist ein Forschungsprojekt im Frühstadium, das untersucht, wie KI-Agenten sicher genug gemacht werden können, um wirklich nützlich zu sein. APIs, Konfigurationsformate und Architektur können sich ändern. Beiträge und Feedback sind willkommen.

Demo

Der Agent wird gebeten, ein Repository zu klonen und Änderungen zu pushen. Sowohl git_clone als auch git_push werden von der Policy-Engine eskaliert, aber der Auto-Genehmiger genehmigt sie automatisch — die vertrauenswürdige Eingabe des Benutzers aus dem Befehlsmodus (Ctrl-A) lieferte eine klare Absicht, sodass kein manuelles /approve erforderlich war.

Das Problem

Autonome KI-Agenten können Dateien verwalten, Git-Befehle ausführen, Nachrichten senden und in Ihrem Namen mit APIs interagieren. Aber heutige Agent-Frameworks geben dem Agenten dieselben Berechtigungen wie dem Benutzer, etwa vollständigen Zugriff auf das Dateisystem, Anmeldedaten und das Netzwerk. Sicherheitsforscher nennen das ambient authority, und es bedeutet, dass eine einzelne Prompt-Injection oder ein Multi-Turn-Drift dazu führen kann, dass ein Agent Dateien löscht, Daten exfiltriert oder bösartigen Code pusht.

Die übliche Antwort besteht darin, Agenten entweder auf eine enge Sandbox zu beschränken (was ihren Nutzen einschränkt) oder den Benutzer um Genehmigung für jede Aktion zu bitten (was ihre Autonomie einschränkt). Beides ist nicht zufriedenstellend.

Der Ansatz

IronCurtain geht einen anderen Weg: Drücken Sie Ihre Sicherheitsabsicht in einfachem Englisch aus und lassen Sie das System die Durchsetzung übernehmen.

Sie schreiben eine Verfassung, ein kurzes Dokument, das beschreibt, was Ihr Agent tun darf und was nicht. IronCurtain kompiliert diese mithilfe einer LLM-Pipeline in eine deterministische Sicherheitsrichtlinie, validiert die kompilierten Regeln anhand generierter Testszenarien und setzt die Richtlinie zur Laufzeit bei jedem Tool-Aufruf durch. Das Ergebnis ist ein Agent, der innerhalb von Grenzen, die Sie in natürlicher Sprache definieren, autonom arbeiten kann.

Die Kernideen:

• Der Agent ist nicht vertrauenswürdig. IronCurtain geht davon aus, dass das LLM durch Prompt-Injection oder Drift kompromittiert sein kann. Die Sicherheit hängt nicht davon ab, dass das Modell „brav“ ist.
• Englisch rein, Durchsetzung raus. Sie schreiben die Absicht („keine destruktiven Git-Operationen ohne Genehmigung“); das System kompiliert sie in deterministische Regeln, die zur Laufzeit ohne weitere LLM-Beteiligung durchgesetzt werden.
• Semantische Interposition. Anstatt dem Agenten direkten Systemzugriff zu gewähren, laufen alle Interaktionen über MCP-Server (Dateisystem, Git usw.). Jeder Tool-Aufruf durchläuft eine Policy-Engine, die erlauben, verweigern oder zur Genehmigung an den Benutzer eskalieren kann.
• Mehrstufige Verteidigung. Der Agent-Code läuft in einer V8-Isolierung ohne direkten Zugriff auf den Host. Der einzige Weg nach außen führt über semantisch bedeutungsvolle MCP-Tool-Aufrufe, und jeder einzelne wird gegen die Richtlinie geprüft.

Architektur

IronCurtain unterstützt zwei Sitzungsmodi mit unterschiedlichen Vertrauensmodellen:

• Integrierter Agent (Code-Modus) — IronCurtains eigener LLM-Agent schreibt TypeScript-Snippets, die in einer V8-Sandbox ausgeführt werden. IronCurtain kontrolliert den Agenten, die Sandbox und die Policy-Engine. Jeder Tool-Aufruf verlässt die Sandbox als strukturierte MCP-Anfrage, durchläuft die Policy-Engine (erlauben / verweigern / eskalieren) und erreicht erst dann den echten MCP-Server.

• Docker-Agent-Modus — Ein externer Agent (Claude Code, Goose usw.) läuft in einem Docker-Container ohne Netzwerkzugriff. IronCurtain vermittelt die externen Effekte: LLM-API-Aufrufe laufen über einen TLS-terminierenden MITM-Proxy (Host-Allowlist, Fake-to-Real-Key-Swap), MCP-Tool-Aufrufe durchlaufen dieselbe Policy-Engine, und Paketinstallationen (npm/PyPI) laufen über einen validierenden Registry-Proxy.

In beiden Modi ist der Agent nicht vertrauenswürdig. Die Sicherheit hängt nicht davon ab, dass das Modell Anweisungen befolgt — sie wird an der Grenze durchgesetzt.

Vollständige Architektur mit Diagrammen, schichtweiser Vertrauensanalyse und macOS-Plattformhinweisen finden Sie in SANDBOXING.md.

Schnellstart

Voraussetzungen

• Node.js 22, 24 oder 26 — die geraden Hauptversionen, die IronCurtain testet (erforderlich für isolated-vm; 24 und 26 installieren vorgefertigte Binärdateien, Node 22 kompiliert bei der Installation aus dem Quellcode und benötigt eine C/C++-Toolchain). Ungerade Versionen (23, 25) laufen, sind aber ungetestet — ironcurtain doctor warnt.
• Docker — nicht erforderlich, aber dringend empfohlen für den Docker-Agent-Modus, der die stärkste Isolierung bietet. Auf macOS 26+ (Apple Silicon) funktioniert Apple container als alternativer Backend (VM pro Container; wird automatisch verwendet, wenn seine Dienste laufen — siehe containerRuntime in ironcurtain config)
• Einen API-Schlüssel für mindestens einen LLM-Anbieter (Anthropic, Google oder OpenAI)

Installation

Als globales CLI-Tool (Endbenutzer):```bash npm install -g @provos/ironcurtain

**Aus dem Quellcode (Entwicklung):**```bash
git clone https://github.com/provos/ironcurtain.git
cd ironcurtain
npm install

Einmalige Einrichtung

1. Legen Sie Ihren API-Schlüssel fest:```bash export ANTHROPIC_API_KEY=sk-ant-...

Sie können Schlüssel auch in einer `.env`-Datei im Projektstammverzeichnis ablegen (wird automatisch über `dotenv` geladen) oder sie über `ironcurtain config` zu `~/.ironcurtain/config.json` hinzufügen. Umgebungsvariablen haben Vorrang vor den Werten der Konfigurationsdatei.

**2. Führen Sie den Erststart-Assistenten aus** (führen Sie dies explizit aus, bevor Sie den empfohlenen Mux-Pfad verwenden; er wird auch automatisch beim ersten Nicht-Mux-`ironcurtain start` ausgeführt):```bash
ironcurtain setup

Führt Sie durch die Einrichtung des GitHub-Tokens, den Web-Suchanbieter, die Modellauswahl und weitere Einstellungen. Erstellt ~/.ironcurtain/config.json mit Ihren Einstellungen.

IronCurtain ausführen

IronCurtain wird mit einer Standardrichtlinie ausgeliefert, die auf die Entwicklererfahrung zugeschnitten ist — schreibgeschützte Vorgänge sind erlaubt, Mutationen (Schreibvorgänge, Pushes, PR-Erstellung) werden zur Genehmigung durch einen Menschen eskaliert. Sie können es direkt nach der Einrichtung verwenden.

Terminal-Multiplexer (empfohlen)

Die empfohlene Methode, IronCurtain zu verwenden. Sie erhalten die volle Leistungsfähigkeit der interaktiven TUI Ihres Agenten (Claude Code oder Goose), während IronCurtain jeden Tool-Aufruf über seine Richtlinien-Engine vermittelt — alles in einem einzigen Terminal.```bash ironcurtain mux

**Wichtigste Funktionen:**

- **Vollwertige Agent-TUI** — Der Agent läuft in einer PTY innerhalb eines Docker-Containers ohne Netzwerkzugriff. Du interagierst mit ihm genau so, als würde er lokal laufen.
- **Inline-Eskalationsbehandlung** — Wenn ein Tool-Aufruf eine Genehmigung benötigt, überlagert ein Eskalations-Picker den Viewport mit Ein-Tasten-Aktionen (a/d/w für genehmigen/ablehnen/whitelisten). Verwende `/approve+ N`, um eine Domain oder einen Pfad für den Rest der Sitzung auf die Whitelist zu setzen.
- **Vertrauenswürdige Benutzereingabe** — Text, der im Befehlsmodus (Strg-A) eingegeben wird, wird auf der Host-Seite erfasst, bevor er in den Container gelangt. Dies erzeugt ein verifiziertes Absichtssignal, das der Auto-Approver nutzen kann — z. B. führt die Eingabe von „push my changes to origin" automatisch zur Genehmigung einer anschließenden `git_push`-Eskalation.
- **Tab-Verwaltung** — Mehrere gleichzeitige Sitzungen starten (`/new`), zwischen ihnen wechseln (`/tab N`, Alt-1..9), sie schließen (`/close`). Mehrere Mux-Instanzen können parallel laufen.

Siehe [DEVELOPER_GUIDE.md](https://github.com/provos/ironcurtain/blob/HEAD/DEVELOPER_GUIDE.md) für die vollständige Anleitung: Eingabemodi, Sicherheitsmodell für vertrauenswürdige Eingaben, Eskalationsablauf und Tastaturreferenz.

### Nicht-Mux-Sitzungen

Verwende `ironcurtain start` für schnelle einmalige Aufgaben, Skripte oder wenn du explizit den lokalen integrierten Agenten möchtest. Für normale interaktive Docker-Agent-Arbeiten verwende `ironcurtain mux`.```bash
ironcurtain start "Summarize the files in ./src"     # Single-shot mode
ironcurtain start -w ./my-project "Fix the tests"    # Single-shot workspace mode
ironcurtain start --agent builtin                    # Local builtin REPL, no Docker
ironcurtain start --persona my-assistant "Check my email"  # Use a persona

Weitere Ausführungsmodi

IronCurtain unterstützt außerdem die Wiederaufnahme von Sitzungen (--resume <session-id>), einen Legacy-Raw-PTY-/Debug-Modus, einen Signal-Messaging-Transport für die mobile Freigabe sowie einen Daemon-Modus für geplante Cron-Jobs. Der Daemon verfügt über eine optionale Web-UI (--web-ui) für browserbasiertes Monitoring und Eskalationsbearbeitung. Einzelheiten finden Sie in RUNNING_MODES.md.

Multi-Agent-Workflows

IronCurtain orchestriert mehrere KI-Agenten über strukturierte Workflows. Der mitgelieferte Vulnerability-Discovery-Workflow spürt Speichersicherheits- und Logikfehler in nativem Code über eine gestufte Harness-Pipeline auf (Tier 1 isolierte Funktion → Tier 2 Mehrkomponenten → Tier 3 vollständiger Build) mit libFuzzer/AFL++-Coverage-Gating, hypothesengesteuerten discover/triage-Zuständen und einem abschließenden menschlichen Gate zur Berichtsprüfung. Der Design-and-Code-Workflow durchläuft Planungs-/Design-/Implementierungs-/Review-Zyklen, ebenfalls mit menschlichen Gates. Jeder Agent läuft in einem eigenen Docker-Container mit rollenspezifischen Policy-Grenzen; die Engine verwaltet automatisch Zustandsübergänge, die Weitergabe von Artefakten und Checkpointing zur Wiederaufnahme nach Abstürzen. Open Source, läuft vollständig auf Ihrem Rechner, setzt pro Agent Sicherheitsrichtlinien über die verfassungsbasierte Policy-Engine durch und funktioniert mit jedem Docker-containerisierten Agenten – vom Umfang her vergleichbar mit Amazon Kiro und Google Jules für Codierungsaufgaben, aber mit Sicherheit erster Klasse und einem erweiterbaren Workflow-Definitionsformat.

Die Web-UI ist die vorgesehene Oberfläche für Workflow-Ausführungen. Starten Sie den Daemon, öffnen Sie die angezeigte URL und steuern Sie die Ausführungen über die Workflows-Seite – das obige Zustandsmaschinen-Diagramm ist live, die Agentennachrichten-Zeitleiste streamt mit Markdown-Rendering, Gate-Reviews enthalten einen Workspace- und Artefakt-Browser, und vergangene Ausführungen bleiben aufgelistet.```bash ironcurtain daemon --web-ui

CLI-Zugriff ist für Skripterstellung, Automatisierung und Debugging verfügbar:```bash
ironcurtain workflow start vuln-discovery \
  "Find memory-safety bugs in libical" --workspace ~/src/libical
ironcurtain workflow start design-and-code \
  "Build a REST API with authentication"

Siehe WORKFLOWS.md für die vollständige Dokumentation.

Anpassen Ihrer Richtlinie

Die Standardrichtlinie funktioniert gut für die allgemeine Entwicklung, aber Sie können sie an Ihren Workflow anpassen:

1. Passen Sie Ihre Verfassung an (optional, aber empfohlen):```bash ironcurtain customize-policy

Ein LLM-gestütztes Gespräch, das eine auf deinen Workflow zugeschnittene Verfassung erzeugt, gespeichert unter `~/.ironcurtain/constitution-user.md`. Du kannst diese Datei auch direkt bearbeiten.

**2. Richtlinie zusammenstellen:**```bash
ironcurtain compile-policy

Übersetzt deine Verfassung in deterministische Regeln, erzeugt Testszenarien und verifiziert sie. Kompilierte Artefakte werden unter ~/.ironcurtain/generated/ abgelegt.

Personas

Personas sind benannte Richtlinienprofile – jedes bündelt eine Verfassung, kompilierte Richtlinie, persistenten Arbeitsbereich und semantisches Gedächtnis. Verwende sie, um Agents mit unterschiedlichen Rollen oder Zugriffsstufen auszuführen.```bash ironcurtain persona create my-assistant # Create a persona ironcurtain persona compile my-assistant # Compile its policy ironcurtain start --persona my-assistant "Check my calendar"

Im Mux-Modus öffnet `/new my-assistant` einen Tab mit dieser Persona. Personas können auch Cron-Jobs zugewiesen werden. Siehe [DAEMON.md](https://github.com/provos/ironcurtain/blob/HEAD/DAEMON.md) für die Konfiguration geplanter Jobs.

Personas können auch über die [Web-UI](https://github.com/provos/ironcurtain/blob/HEAD/DAEMON.md#persona-policy-management) verwaltet werden – durchsuchen, erstellen, Verfassungen bearbeiten und Richtlinien mit Live-Fortschritt kompilieren. Da eine Richtlinie eine Sicherheitsgrenze darstellt, sind die Mutationssteuerungen der Web-UI schreibgeschützt, es sei denn, der Daemon wird mit `--allow-policy-mutation` gestartet (standardmäßig deaktiviert).

### Skills

Lege SKILL.md-Pakete unter `~/.ironcurtain/skills/<name>/` ab, um zweckspezifische Anleitungen (Hilfsskripte, deterministische Checks, Fachwissen) für jede Docker-Agent-Sitzung verfügbar zu machen. Die zusammengeführte Menge wird in ein pro-Bundle-Hostverzeichnis gestellt und **schreibgeschützt** in den Container gebunden – und zwar an dem Pfad, den die native Erkennung des aktiven Agents durchläuft. Claude Code wird über `--add-dir` auf das Staging-Verzeichnis verwiesen, Goose durchsucht `~/.config/goose/skills/<name>/SKILL.md`. Der Agent entdeckt sie automatisch und entscheidet anhand der Frontmatter-Beschreibung jeder Skill, wann er sie liest. Das _Format_ von SKILL.md ist der offene Standard, der von Claude Code, Goose und Codex übernommen wurde; nur der _Erkennungspfad_ unterscheidet sich je nach Agent. Workflows können pro Zustand Skills innerhalb des Workflow-Pakets ausliefern – siehe [WORKFLOWS.md](https://github.com/provos/ironcurtain/blob/HEAD/WORKFLOWS.md#skills).

## Richtlinie: Verfassung → Durchsetzung

Du schreibst Absicht in einfachem Englisch; IronCurtain kompiliert sie in deterministische Regeln:```
constitution.md → [Annotate] → [Compile] → [Resolve Lists] → [Generate Scenarios] → [Verify & Repair]
                      │              │              │                  │                     │
                      ▼              ▼              ▼                  ▼                     ▼
              tool-annotations  compiled-policy  dynamic-lists   test-scenarios       verified policy
                  .json            .json            .json            .json          (or build failure)

1. Annotieren — Klassifiziere die Argumente jedes MCP-Tools nach Rolle (read-path, write-path, delete-path, none).
2. Kompilieren — Übersetze die englische Verfassung in deterministische Wenn/Dann-Regeln. Kategoriale Referenzen ("große Nachrichtenseiten", "meine Kontakte") werden als symbolische @list-name-Referenzen ausgegeben.
3. Listen auflösen — Löse symbolische Listen mithilfe von LLM-Wissen oder MCP-Tool-Nutzung zu konkreten Werten auf (z. B. durch Abfrage einer Kontaktdatenbank). Wird in dynamic-lists.json geschrieben, vom Benutzer editierbar. Wird übersprungen, wenn keine Listen vorhanden sind.
4. Szenarien generieren — Erstelle Testszenarien aus der Verfassung sowie obligatorischen handgeschriebenen Invariantentests.
5. Verifizieren & Reparieren — Führe Szenarien gegen die echte Policy-Engine aus. Ein LLM-Judge analysiert Fehlschläge und erzeugt gezielte Reparaturen (bis zu 2 Runden). Der Build schlägt fehl, wenn die Policy nicht verifiziert werden kann.

Alle Artefakte werden per Content-Hash gecacht — nur geänderte Eingaben lösen eine Neukompilierung aus.

Wie kompilierte Regeln aussehen

Eine Verfassungsklausel wie:```markdown

• The agent may perform read-only git operations (status, diff, log) within the sandbox without approval.
• The agent must receive human approval before git push, pull, fetch, or any remote-contacting operation.

Kompiliert zu:```json
[
  { "tool": "git_status", "decision": "allow", "condition": { "directory": { "within": "$SANDBOX" } } },
  { "tool": "git_diff", "decision": "allow", "condition": { "directory": { "within": "$SANDBOX" } } },
  { "tool": "git_push", "decision": "escalate", "reason": "Remote-contacting git operations require human approval" }
]

Jeder Aufruf, der keiner expliziten allow- oder escalate-Regel entspricht, wird standardmäßig verweigert.```bash ironcurtain annotate-tools --server filesystem # Annotate one server (merge with existing) ironcurtain annotate-tools --all # Re-annotate all servers ironcurtain compile-policy # Compile constitution into rules and verify ironcurtain refresh-lists # Re-resolve dynamic lists without full recompilation ironcurtain refresh-lists --list major-news # Refresh a single list

Review the generated `~/.ironcurtain/generated/compiled-policy.json` — dies sind die exakten Regeln, die zur Laufzeit durchgesetzt werden.

## Konfiguration

IronCurtain speichert Konfigurations- und Sitzungsdaten in `~/.ironcurtain/`:```
~/.ironcurtain/
├── config.json              # User configuration
├── constitution.md          # User-local base constitution (overrides package default)
├── constitution-user.md     # Your policy customizations (generated by customize-policy)
├── generated/               # User-compiled policy artifacts (overrides package defaults)
├── personas/                # Persona directories (constitution, policy, workspace, memory)
├── skills/                  # User-global SKILL.md packages, mounted into every Docker session
├── jobs/                    # Cron job definitions, workspaces, and run records
├── sessions/
│   └── {sessionId}/
│       ├── sandbox/         # Per-session filesystem sandbox
│       ├── escalations/     # File-based IPC for human approval
│       ├── audit.jsonl      # Per-session audit log
│       └── session.log      # Diagnostics
└── workflow-runs/           # Shared-container workflow runs (see below)

Single-Session-Läufe (ironcurtain start, mux-Tabs, Cron-Jobs) schreiben unter sessions/. Workflow-Läufe mit gemeinsamem Container schreiben stattdessen unter workflow-runs/ — siehe nächster Abschnitt.

Aufbau eines Workflow-Laufs

Eine Workflow-Definition kann sich für einen gemeinsamen Docker-Container entscheiden, indem in ihrer YAML-Datei settings.sharedContainer: true gesetzt wird. In diesem Modus läuft jeder Agentenstatus in demselben langlebigen Container und teilt sich eine Instanz der Policy-Engine; zwischen den Zuständen tauscht der Orchestrator die aktive Policy per Hot-Swap aus, sodass jede Persona ihre eigenen Regeln sieht. Alle Artefakte des Laufs landen in einem einzigen Verzeichnisbaum:``` ~/.ironcurtain/workflow-runs// ├── audit.jsonl # Persona-tagged append-only audit ├── messages.jsonl # Orchestrator message log ├── workspace/ # Agent workspace (filesystem MCP root) ├── bundle/ # Shared container support (claude-state, orientation, sockets, escalations, system-prompt.txt) ├── states/ │ └── ./ # session.log + session-metadata.json per invocation └── proxy-control.sock # Coordinator UDS for policy hot-swap

Für einen Workflow-Lauf mit gemeinsamem Container werden keine sitzungsbezogenen Einträge unter `~/.ironcurtain/sessions/` erstellt. Die für Benutzer sichtbaren Befehle (`ironcurtain workflow start|resume|inspect|list`) bleiben unverändert. Siehe [WORKFLOWS.md](https://github.com/provos/ironcurtain/blob/HEAD/WORKFLOWS.md) zum Erstellen von Workflow-Definitionen und zum vollständigen Lebenszyklus.

Konfiguration interaktiv bearbeiten:```bash
ironcurtain config

Wichtige Konfigurationsbereiche: Modelle und API-Schlüssel, Ressourcenbudgets (Token-/Schritt-/Zeit-/Kostenlimits), Auto-Approval-Eskalationen, Websuch-Anbieter, Audit-Schwärzung und LLM-Einstellungen für den Memory-Server. Die vollständige Referenz finden Sie in CONFIG.md.

Um LLM-Datenverkehr über ein Gateway wie LiteLLM oder OpenRouter zu leiten (sowohl im Code-Modus als auch im Docker-Agent-Modus), siehe MODEL_ROUTING.md.

Leiten Sie Docker-Agenten über Modellanbieter-Profile (z. B. GLM-5.2 über OpenRouter, ohne Sidecar) mit ironcurtain config → Model Providers, und wählen Sie dann ein Profil unter /new oder mit --provider-profile — siehe MODEL_ROUTING.md.

Integrierte Funktionen

IronCurtain wird mit sechs vorkonfigurierten MCP-Servern ausgeliefert. Alle Tool-Aufrufe (außer Memory) unterliegen Ihrer kompilierten Policy.

Schreibgeschützte Operationen sind per Standard-Policy erlaubt; Mutationen (Schreibvorgänge, Pushes, PR-Erstellung) eskalieren zur Genehmigung durch Menschen. Tools verwenden die Benennung server.tool (z. B. filesystem.read_file, memory.recall). Siehe ADDING_MCP_SERVERS.md, um eigene hinzuzufügen.

Netzwerk-Passthrough (Docker-Agent-Modus)

Im Docker-Agent-Modus hat der Container keinen Netzwerkzugriff — der gesamte Datenverkehr läuft über den MITM-Proxy von IronCurtain. Standardmäßig sind nur die Domänen der LLM-Anbieter erreichbar. Der Agent kann zur Laufzeit über den virtuellen MCP-Server proxy (add_proxy_domain) Zugriff auf weitere Domänen anfordern. Jede Anfrage erfordert eine menschliche Genehmigung über den Eskalationsablauf.

Genehmigte Domänen erhalten einen Roh-Passthrough-Tunnel — HTTP-, HTTPS- und WebSocket-Verbindungen werden ohne Inhaltsprüfung oder Einfügen von Anmeldedaten weitergeleitet. Das gibt dem Agenten mehr Nutzen (Aufruf von Drittanbieter-APIs, Streaming von Daten aus externen Diensten), bedeutet aber, dass der Datenverkehr zu diesen Domänen ohne Vermittlung erfolgt. Siehe SECURITY_CONCERNS.md, Abschnitt 2b-i, für das Bedrohungsmodell und DEVELOPER_GUIDE.md für Nutzungsdetails.

Sicherheitsmodell

IronCurtain ist um ein bestimmtes Bedrohungsmodell herum konzipiert: das LLM geht auf Abwege. Dies kann durch Prompt-Injection (eine bösartige E-Mail oder Webseite übernimmt die Kontrolle über den Agenten) oder durch Multi-Turn-Drift (der Agent weicht im Laufe einer langen Sitzung allmählich von der Absicht des Benutzers ab) geschehen.

Was IronCurtain durchsetzt

• Dateisystem-Eindämmung — Symlink-bewusste Pfadauflösung verhindert Path-Traversal- und Symlink-Escape-Angriffe.
• Pro-Tool-Policy — Jeder MCP-Tool-Aufruf wird gegen kompilierte Regeln geprüft. Die Policy-Engine klassifiziert Tool-Argumente nach Rolle (read-path, write-path, delete-path), um granulare Entscheidungen zu treffen.
• Strukturelle Invarianten — Bestimmte Schutzmechanismen sind fest verdrahtet und können nicht durch die Verfassung außer Kraft gesetzt werden: Der Agent kann niemals seine eigenen Policy-Dateien, Audit-Protokolle oder Konfiguration ändern.
• Menschliche Eskalation — Wenn die Policy „eskalieren" sagt, pausiert der Agent und der Benutzer muss ausdrücklich genehmigen oder ablehnen. Optional bearbeitet ein LLM-basierter Auto-Approver eindeutige Fälle (siehe CONFIG.md).
• Prüfprotokoll (Audit-Trail) — Jeder Tool-Aufruf und jede Policy-Entscheidung wird in ein Append-only-JSONL-Auditprotokoll geschrieben.
• Ressourcenlimits — Token-, Schritt-, Zeit- und Kostenbudgets verhindern außer Kontrolle geratene Sitzungen.

Bekannte Einschränkungen

Dies ist ein Forschungsprototyp. Bekannte Lücken umfassen:

• Genauigkeit der Policy-Kompilierung — Der LLM-basierte Compiler kann die Absicht der Verfassung falsch interpretieren. Die Verifikationspipeline fängt viele Fehler ab, ist aber nicht erschöpfend. Überprüfen Sie stets die kompilierte compiled-policy.json.
• V8-Isolate-Grenzen — Der Code-Modus verwendet V8-Isolate, keine Virtualisierung auf Betriebssystemebene. Ein V8-Zero-Day könnte eine Flucht ermöglichen.
• Keine Prüfung ausgehender Inhalte — Ein Agent, der Dateien schreiben darf, könnte sensible Daten kodieren, um Kontrollen auf Inhaltsebene zu umgehen. Geplant: LLM-basierte Verständlichkeitsprüfungen für ausgehende Inhalte.
• Ermüdung durch Eskalationen — Zu viele Fehlalarm-Eskalationen können zu gewohnheitsmäßiger Genehmigung führen. Passen Sie Ihre Verfassung an, um unnötige Aufforderungen zu minimieren.

Eine detaillierte Bedrohungsanalyse finden Sie in docs/SECURITY_CONCERNS.md.

Fehlerbehebung

Entwicklung```bash

npm test # Run all tests npm test -- test/policy-engine.test.ts # Run a single test file npm test -- -t "denies delete_file" # Run a single test by name npm run lint # Lint npm run build # TypeScript compilation + asset copy

Siehe [TESTING.md](https://github.com/provos/ironcurtain/blob/HEAD/TESTING.md) für den vollständigen Testleitfaden, einschließlich Integrations-Testflags und Konventionen.

### Projektstruktur```
src/
├── index.ts                    # Entry point
├── cli.ts                      # CLI command dispatcher
├── config/                     # Configuration loading, constitution, MCP server definitions
├── session/                    # Multi-turn session management, budgets, loop detection
├── sandbox/                    # V8 isolated execution environment
├── trusted-process/            # Policy engine, MCP proxy, audit log, escalation handler
├── pipeline/                   # Constitution → policy compilation pipeline
├── escalation/                 # Escalation listener: session registry, TUI dashboard, state
├── mux/                        # Terminal multiplexer: PTY bridge, renderer, trusted input
├── persona/                    # Persona management (create, compile, resolve)
├── memory/                     # Memory server integration (config, annotations, path resolution)
├── signal/                     # Signal messaging transport (bot daemon, setup, formatting)
├── daemon/                     # Unified daemon (Signal + cron scheduler, control socket)
├── cron/                       # Cron job management (scheduler, job store, git sync, policy)
├── docker/                     # Docker agent mode, PTY session, MITM proxy, registry proxy
├── workflow/                   # Multi-agent workflow engine (orchestrator, state machine, gates)
├── web-ui/                     # Web UI backend (JSON-RPC dispatch, event bus, workflow manager)
├── servers/                    # Built-in MCP servers (fetch, web search providers)
└── types/                      # Shared type definitions
packages/
└── memory-mcp-server/          # Standalone memory MCP server (publishable npm package)

Lizenz

Apache-2.0