IronCurtain

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

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

[!WARNING] Forschungsprototyp. IronCurtain ist ein frühes Forschungsprojekt, 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-Approver genehmigt sie automatisch — die vertrauenswürdige Eingabe des Benutzers aus dem Command-Modus (Strg-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. Doch die heutigen Agenten-Frameworks geben dem Agenten dieselben Privilegien wie dem Benutzer, etwa vollen Zugriff auf das Dateisystem, Anmeldedaten und das Netzwerk. Sicherheitsforscher nennen dies ambient authority (umgebende Autorität), und das bedeutet, dass eine einzige Prompt-Injection oder mehrstufige 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 ihre Nützlichkeit einschränkt) oder den Benutzer jede Aktion genehmigen zu lassen (was ihre Autonomie einschränkt). Beides ist unbefriedigend.

Der Ansatz

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

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

Die zentralen Ideen:

• Der Agent ist nicht vertrauenswürdig. IronCurtain geht davon aus, dass das LLM durch Prompt-Injection oder Drift kompromittiert sein könnte. 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 Zwischenschaltung. Anstatt dem Agenten rohen Systemzugriff zu geben, 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.
• Verteidigung in der Tiefe. Der Agent-Code läuft in einem V8-Isolate ohne direkten Zugriff auf den Host. Der einzige Ausweg führt über semantisch bedeutsame MCP-Tool-Aufrufe, und jeder einzelne wird gegen die Richtlinie geprüft.

Architektur

IronCurtain unterstützt zwei Sitzungsmodi mit unterschiedlichen Vertrauensmodellen:

• Builtin Agent (Code Mode) — 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 Mode — Ein externer Agent (Claude Code, Goose, Codex) läuft in einem Container ohne direkten Zugang zum öffentlichen Netzwerk. IronCurtain vermittelt die externen Effekte: LLM-API-Aufrufe laufen über einen TLS-terminierenden MITM-Proxy (Host-Allowlist, Fake-to-Real-Key-Austausch), MCP-Tool-Aufrufe laufen durch dieselbe Policy-Engine, und unterstützte Paketinstallationen laufen über validierende Paket-Proxys.

Opt-in nested Docker gibt Entwickler-Sitzungen einen privaten, ephemeren Daemon, ohne den Host-Docker-Socket offenzulegen. Implementierte Profile decken Apple Container und Docker Desktop unter macOS sowie WSL2 mit Docker Desktop unter amd64 ab. Seine Modi offline, images und packages trennen lokale Image-Nutzung, vermittelte öffentliche Image-Pulls und unterstützte Paket-Builds. Native Linux Engine ist für Nesting nicht zugelassen; siehe die Konfigurationsreferenz für Voraussetzungen und Einschränkungen.

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.

Siehe SANDBOXING.md für die vollständige Architektur mit Diagrammen, schichtweiser Vertrauensanalyse und Hinweisen zur macOS-Plattform.

Schnellstart

Voraussetzungen

• Node.js 24 oder 26 — die geradzahligen Major-Linien, die IronCurtain testet. Beide installieren vorgebaute isolated-vm-Binärdateien. Node 25 wird nicht unterstützt und nicht getestet.
• Docker — nicht erforderlich, aber dringend empfohlen für den Docker Agent Mode, der die stärkste Isolation bietet. Unter macOS 26+ (Apple Silicon) funktioniert Apple container als alternative Backend-Option (VM pro Container; wird automatisch verwendet, wenn seine Dienste laufen — siehe containerRuntime in ironcurtain config)
• Ein API-Schlüssel für mindestens einen LLM-Anbieter (Anthropic, Google oder OpenAI)

Installation

Als globales CLI-Tool (Endbenutzer):

npm install -g @provos/ironcurtain

Aus der Quelle (Entwicklung):

git clone https://github.com/provos/ironcurtain.git
cd ironcurtain
npm install

Einmalige Einrichtung

1. Legen Sie Ihren API-Schlüssel fest:

export ANTHROPIC_API_KEY=sk-ant-...

Du kannst Schlüssel auch in einer .env-Datei im Projektstammverzeichnis ablegen (automatisch geladen über dotenv) oder sie über ironcurtain config zu ~/.ironcurtain/config.json hinzufügen. Umgebungsvariablen haben Vorrang vor Werten aus der Konfigurationsdatei. Unterstützt: ANTHROPIC_API_KEY, GOOGLE_GENERATIVE_AI_API_KEY, OPENAI_API_KEY.

2. Führe den Erststart-Assistenten aus (führe dies explizit aus, bevor du den empfohlenen mux-Pfad verwendest; er läuft auch automatisch beim ersten Nicht-mux-ironcurtain start):

ironcurtain setup

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

IronCurtain ausführen