Mehr als 40.000 ungeschützte Instanzen eines populären KI-Agenten-Frameworks waren öffentlich zugänglich – inklusive API-Schlüssel, OAuth-Token und monatelanger Gesprächshistorien. Das ist keine Prognose, sondern ein dokumentierter Vorfall aus dem Februar 2026. KI-Agenten, die Kalender verwalten, E-Mails beantworten und Browser steuern, arbeiten mit vollen Zugriffsrechten auf digitale Systeme – und fast ohne Sicherheitsarchitektur.
Niels Provos, langjähriger Sicherheitsingenieur (u.a. Google), hat darauf eine konkrete Antwort entwickelt: IronCurtain, ein Open-Source-Framework, das KI-Agenten von Grund auf in eine kontrollierte Sicherheitsarchitektur einbettet. In diesem Artikel erfahren Sie, warum Agenten-Sicherheit eine eigene Architektur braucht – und wie IronCurtain diese Lücke technisch schließt.
🔒 Die vier Kernprinzipien von IronCurtain
Sandbox-Isolation
Der Agent läuft in einer abgeschlossenen Umgebung (V8-Isolate oder Docker-Container) ohne direkten Systemzugriff. Was außerhalb passiert, bleibt außerhalb.
MCP-Proxy als Engpass
Jede Aktion – Datei lesen, Code ausführen, Web-Request – läuft durch einen einzigen kontrollierten Kanal. Kein Bypass, kein direkter Systemaufruf.
Credential-Trennung
Der Agent sieht niemals echte API-Schlüssel oder OAuth-Token. Der MITM-Proxy tauscht synthetische Schlüssel erst beim Weiterleiten gegen die realen aus.
Deterministische Policy
Berechtigungen werden in natürlicher Sprache definiert und in unveränderliche Regeln kompiliert. Die Entscheidung „erlauben / blockieren / eskalieren" trifft kein Sprachmodell, sondern der Regelcompiler.
Das Problem: Agenten mit Systemzugriff und ohne Sicherheitsnetz
Autonome KI-Agenten (englisch: Agentic AI) – also Systeme, die selbstständig Aufgaben planen, Werkzeuge aufrufen und mehrere Schritte ohne menschliche Zwischenschritte ausführen – sind kein Zukunftsszenario mehr. Sie verwalten Dateisysteme, führen Code aus, versenden E-Mails und initiieren Zahlungen. Das Problem: Ihre Sicherheitsarchitektur wurde in den meisten verfügbaren Frameworks nachträglich ergänzt, nicht von Anfang an eingebaut.
Sicherheitsforscher haben im Februar 2026 mehr als 8.000 MCP-Server (Model Context Protocol – die Standardschnittstelle, über die KI-Agenten externe Werkzeuge aufrufen) öffentlich im Internet gefunden, ohne jede Authentifizierung. Über denselben Protokollstandard wurden kritische Schwachstellen in Claude Code publik: Angreifer konnten durch manipulierte Repository-Konfigurationsdateien Remote Code Execution auslösen, bevor der Nutzer auch nur einen Sicherheitsdialog zu Gesicht bekam.
Die eigentliche Gefahr lässt sich in einem Satz beschreiben: Prompt Injection – das Einschleusen von Angriffsanweisungen in Daten, die der Agent verarbeitet (E-Mails, Webseiten, Dokumente) – kann einen KI-Agenten dazu bringen, Aktionen im Sinne eines Angreifers auszuführen. Nicht weil das Modell bösartig ist, sondern weil es seinen Kontext nicht von externen Eingaben unterscheiden kann.
IronCurtain: Sicherheit als Architekturprinzip
IronCurtain begegnet diesem Problem nicht mit Hinweisen ans Modell, sondern mit strukturellen Grenzen. Der zentrale Gedanke: Jede Aktion des Agenten läuft durch einen einzigen kontrollierten Engpass – einen MCP-Proxy –, der als Policy-Engine entscheidet, ob eine Aktion erlaubt, blockiert oder zur menschlichen Freigabe eskaliert wird. Der Agent hat keinen direkten Systemzugriff; er kann ausschließlich über diesen Kanal mit der Außenwelt kommunizieren.
Das Framework unterstützt zwei Betriebsmodi mit unterschiedlichen Sicherheitsmodellen:
Code Mode: Der Agent schreibt TypeScript, nicht Systembefehle
Im Code Mode schreibt der Agent TypeScript-Schnipsel, die in einer isolierten V8-Laufzeitumgebung (derselben JavaScript-Engine wie in Chrome) ausgeführt werden. Diese Isolate haben keinen Zugriff auf Dateisystem, Netzwerk oder Umgebungsvariablen. Die einzige Möglichkeit, etwas zu tun, sind typisierte Funktionsaufrufe, die auf MCP-Operationen gemappt werden – und die alle durch die Policy-Engine laufen. Für den Agenten sehen diese Aufrufe aus wie normale API-Aufrufe; in Wirklichkeit entscheidet jede einzelne Aktion die Policy.
Docker Mode: Vollständige Agenten in einem Netzwerk-losen Container
Für Agenten, die eine vollständige Shell brauchen – etwa Claude Code –, läuft der Docker Mode. Der Agent wird in einem Container mit --network=none und ohne erhöhte Berechtigungen isoliert. Er hat genau zwei Wege nach außen: einen Unix-Socket zum MCP-Proxy und einen zweiten zu einem TLS-MITM-Proxy, der LLM-API-Anfragen verarbeitet. Der reale API-Schlüssel kommt dabei nie in den Container; der Agent erhält einen synthetischen Schlüssel, den der MITM-Proxy vor der Weiterleitung tauscht. Diese Zugangsdaten-Trennung (Credential Separation) ist ein entscheidender Unterschied zu bestehenden Ansätzen, bei denen Agenten ihre eigenen Schlüssel halten.
Policy in natürlicher Sprache statt YAML-Konfigurationen
Sicherheitsregeln in maschinenlesbarer Form zu schreiben überfordert die meisten Organisationen – und führt dazu, dass Berechtigungen pauschal freigegeben werden. IronCurtain löst das mit einem ungewöhnlichen Ansatz: Die Policy-Sprache ist Deutsch oder Englisch.
Eine typische Konfiguration könnte lauten: „Der Agent darf lokale Git-Operationen lesen und schreiben. Für alle Remote-Operationen wie Push oder Fetch ist meine Freigabe erforderlich." IronCurtain kompiliert diese Anweisung in deterministische Regeln, die von der Policy-Engine ausgewertet werden – ohne dass das Modell selbst an der Entscheidung beteiligt ist. Ein LLM übersetzt einmalig bei der Kompilierung; in der Laufzeit entscheidet ausschließlich der kompilierte, deterministisch arbeitende Regelsatz.
Das ist kein kleines Detail: Sicherheits-Policy darf nicht stochastisch sein. Ein Sprachmodell, das heute eine gefährliche Anfrage korrekt blockiert, könnte sie morgen bei anderem Kontext durchlassen. Determinismus ist hier die einzige belastbare Grundlage.
Für Situationen ohne klare Policy-Entscheidung kann ein optionaler Auto-Approver eingeschaltet werden, der erkennt, wenn explizite Nutzeranweisungen eine Aktion bereits autorisieren – etwa „Push die Änderungen zu origin" als Freigabe für einen git push. Diese Funktion ist opt-in und verkleinert bewusst die Angriffsfläche für Prompt Injection, indem sie nur auf bereinigten Eskalationsinformationen und dem ursprünglichen Nutzerauftrag arbeitet.
Was IronCurtain heute kann – und wo die Grenzen liegen
IronCurtain ist ein Research-Prototyp. Die Kernsicherheitsarchitektur – Sandbox-Isolation, Policy-Engine, Credential-Trennung, Audit-Log – ist funktionsfähig und stabil. Drumherum ist noch Entwicklungsarbeit im Gange. Die folgende Übersicht hilft Entscheidern, die aktuelle Reife realistisch einzuschätzen:
| Heute verfügbar | Angekündigt / In Arbeit (Herstellerangaben) |
|---|---|
| Sandbox-Isolation (V8-Isolate & Docker) | Weitere vorkonfigurierte MCP-Server |
| MCP-Proxy mit Allow / Deny / Escalate | Claude-Code-Integration (funktioniert, noch rau) |
| Policy-Kompilierung aus Klartext | Erweiterte Testszenarien für Policy-Verifikation |
| Credential Separation (MITM-Proxy) | Stabilisierung der Claude-Code-Integration |
| Dateisystem, Git, Web-Suche, Web-Fetch | Dokumentation & Community-Feedback-Runden |
| Signal-Integration (Ende-zu-Ende-verschlüsselt) | – |
| Audit-Log aller Policy-Entscheidungen | – |
Wichtiger als die Feature-Liste ist, was IronCurtain explizit nicht verspricht:
Prompt Injection ist kein gelöstes Problem. IronCurtain kann den Explosionsradius einschränken, wenn ein Agent durch injizierte Anweisungen manipuliert wird – die Sandbox-Grenzen gelten auch dann. Aber es kann den Angriff selbst nicht verhindern. Wer einen Agenten mit E-Mail-Zugriff betreibt, muss damit rechnen, dass bösartige Inhalte versuchen werden, ihn umzulenken.
Kontext-Drift ist real. Modelle weichen in langen Sitzungen auch ohne böswillige Eingaben von ihren ursprünglichen Anweisungen ab. IronCurtain adressiert das teilweise: Wenn die Policy-Engine eine Aktion blockiert, gibt sie den Ablehnungsgrund zurück – ein Signal, das das Modell tendenziell wieder zur ursprünglichen Aufgabe zurückführt. Ein vollständiges Gegengewicht zu Kontext-Drift ist das nicht.
Die Policy-Kompilierung ist kein formaler Beweis. Ein LLM, das Ihre Klartext-Policy in Regeln übersetzt, kann Nuancen falsch interpretieren. IronCurtain generiert Testszenarien, die Lücken und Widersprüche aufdecken sollen – ein sinnvolles Verfahren, aber kein mathematisch garantiertes. Vor dem Produktiveinsatz empfiehlt sich eigenes Testing mit repräsentativen Szenarien.
Relevanz für Unternehmen im DACH-Raum
Für Entscheider, die den Einsatz von KI-Agenten im Unternehmen evaluieren, stellt IronCurtain ein konkretes Denkmuster bereit – unabhängig davon, ob das Framework direkt eingesetzt wird oder nicht:
Szenario 1: Entwicklungsteam mit Claude Code
Ein Software-Team nutzt Claude Code als Coding-Assistenten. Ohne Absicherung hat der Agent vollen Zugriff auf das Dateisystem, alle Environment-Variablen (inklusive API-Schlüssel) und kann Code direkt ausführen. Mit IronCurtain im Docker Mode wird Claude Code in einem Container ohne Netzwerkzugang isoliert; Dateizugriffe sind auf definierte Verzeichnisse beschränkt; Remote-Git-Operationen eskalieren zur Freigabe. Der Mehraufwand für das Entwicklungsteam: minimal. Der Sicherheitsgewinn bei einer Kompromittierung durch manipulierte Repository-Dateien: erheblich.
Szenario 2: Automatisierter Dokumenten-Agent im Mittelstand
Ein Produktionsunternehmen plant, einen Agenten für die Verarbeitung eingehender Lieferanten-E-Mails einzusetzen: Extraktion von Bestelldaten, Abgleich mit dem ERP-System, Ablage von Dokumenten. Genau dieses Szenario – E-Mail-Verarbeitung kombiniert mit Dateisystem- und Systemzugriff – ist das klassische Prompt-Injection-Risikoprofil. IronCurtain kann hier sicherstellen, dass der Agent ausschließlich in vordefinierten Verzeichnissen schreibt, keine externen Verbindungen ohne Freigabe aufbaut und Aktionen oberhalb eines definierten Schwellenwerts (z.B. Schreiben ins ERP) eskaliert.
DSGVO-Perspektive
KI-Agenten, die personenbezogene Daten verarbeiten, unterliegen den Anforderungen der DSGVO – insbesondere Datensparsamkeit und Zweckbindung. IronCurtain adressiert das strukturell: Der Agent hat ausschließlich Zugriff auf das, was die Policy explizit erlaubt. Das ist kein Ersatz für eine Datenschutzfolgenabschätzung, aber es ermöglicht eine präzisere, nachweisbare Zugriffsbeschränkung als die übliche Praxis, Agenten mit vollen Systemberechtigungen laufen zu lassen.
Einordnung: IronCurtain und die breitere Debatte
IronCurtain ist nicht das einzige Projekt, das Agenten-Sicherheit adressiert. Anthropic baut Sicherheitskontrollen direkt in Claude Code ein; Microsoft hat Sicherheitsprinzipien für MCP-Deployments veröffentlicht; OWASP listet Prompt Injection als größtes Einzelrisiko für LLM-Anwendungen. Der Unterschied: IronCurtain ist das bisher einzige Open-Source-Framework, das Sandbox-Isolation, Policy-Engine und Credential-Trennung in einer installierbaren Architektur verbindet.
Die Einschätzung von The Meridiem, einem Technologieanalyse-Dienst, bringt es auf den Punkt: Wenn der Bewertungsrahmen von „Ist das sicher?" zu „Welche Grenzen brauchen wir für sicheren Betrieb?" wechselt, wird die Technologie einsetzbar. IronCurtain verschiebt diese Perspektive in die Praxis.
Sicherheitsforscher Dino Dai Zovi und Michal Zalewski – beide ausgewiesene Experten im Bereich Offensive Security – haben den Architekturansatz von Provos konzeptionell bewertet und ihr grundsätzliches Einverständnis signalisiert. Das ist kein Security-Audit, aber ein belastbares Signal, dass der Ansatz im Kern solide ist.
Fazit und Handlungsempfehlung
IronCurtain löst das KI-Agenten-Sicherheitsproblem nicht vollständig – das wäre unrealistisch. Es liefert aber eine architektonische Grundlage, die drei der wichtigsten Angriffsvektoren strukturell adressiert: unkontrollierte Systemzugriffe, exponierte Zugangsdaten und nicht nachvollziehbare Berechtigungen.
Für Unternehmen, die heute KI-Agenten pilotieren oder evaluieren, ist IronCurtain in erster Linie ein Referenzmodell: So könnte eine Agenten-Infrastruktur aussehen, die Sicherheit als Designprinzip behandelt – nicht als Nachgedanken.
✅ Was Unternehmen jetzt tun sollten
- Bestehende Agenten-Infrastruktur prüfen: Welche KI-Agenten laufen bereits – produktiv oder im Pilot? Mit welchen Berechtigungen? Wer prüft, welche Aktionen sie ausführen? Eine ehrliche Bestandsaufnahme deckt typischerweise mehr ungeschützte Zugriffe auf als erwartet.
- Policy-Anforderungen definieren, bevor der nächste Agent ausgerollt wird: Was darf der Agent lesen, was schreiben, welche Aktionen erfordern eine menschliche Freigabe? Diese Fragen sollten vor dem Deployment geklärt sein – nicht danach. IronCurtains Klartext-Ansatz ist ein nützliches Denkmodell für diese Diskussion, unabhängig vom gewählten Framework.
- IronCurtain-Prototyp in der Entwicklungsumgebung testen: Der Einstieg ist niederschwellig (
npx @provos/ironcurtain, Node.js 22+, Docker). Ein kontrolliertes Experiment in einer isolierten Dev-Umgebung – etwa mit Claude Code auf einem internen Repository – gibt konkrete Erfahrungen mit Sandbox-Grenzen und Policy-Kompilierung, ohne Produktivsysteme zu berühren.
Für Entwicklerinnen und Entwickler: IronCurtain lässt sich mit npx @provos/ironcurtain direkt ausprobieren. Der Quellcode liegt unter github.com/provos/ironcurtain; ausführlichere Architekturdokumentation findet sich auf ironcurtain.dev. Node.js 22 oder höher und Docker sind Voraussetzungen für den vollen Funktionsumfang.
Weiterführend auf AI-Fabrik: Agentic Payments in Europa – was passiert, wenn KI-Agenten autonom Zahlungen auslösen können, und welche Governance-Anforderungen das mit sich bringt. Sowie unser Artikel zur LLM-Evaluierung, der zeigt, wie Unternehmen die Qualität und das Sicherheitsverhalten von KI-Systemen systematisch messen.
