Zuletzt aktualisiert am: 28. September 2026
Ein KI-Coding-Agent, der lokal auf dem Rechner läuft, hat dieselben Rechte wie die Entwicklerin oder der Entwickler selbst: Zugriff auf Dateien, Netzwerk, Zugangsdaten. Genau das macht ihn zum Sicherheitsrisiko. Das Team hinter ESACA, kurz für European Sovereign Agentic Coding Appliance, hat deshalb eine Sandbox gebaut, die einen entscheidenden Kniff hat: Der Agent bekommt Zugangsdaten grundsätzlich nie zu sehen, auch nicht für Dienste, die er nutzen darf. Vorgestellt hat die Lösung kürzlich Trình Đức Trần vom ESACA-Team, am Beispiel eines internen HR-Projekts.
Hinter ESACA stehen mgm technology partners und Fsas Technologies, ein Unternehmen von Fujitsu. Die Initiative ermöglicht souveränes, KI-gestütztes Programmieren, bei dem Code und Daten das eigene Rechenzentrum nie verlassen. Genau hier setzt die neue Sandbox an. Sie isoliert den Coding-Agenten konsequent von seiner Umgebung. Er läuft in einer eigenen, abgeschotteten Umgebung, nicht direkt auf dem Rechner der Entwicklerin oder des Entwicklers. Jeder Zugriff auf Dateien, Netzwerk oder Zugangsdaten muss ausdrücklich freigegeben werden. Die Sandbox selbst ist generisch angelegt und funktioniert bereits heute mit unterschiedlichen Coding-Agenten, darunter Claude Code und OpenCode. Mehr zum Kooperationsstart lesen
Warum ein Coding-Agent nicht einfach auf dem Rechner laufen sollte
Ein Coding-Agent wird meist wie ein gewöhnliches Entwicklungswerkzeug installiert. Das passiert direkt auf dem Arbeitsplatzrechner. Technisch bedeutet das: Der Agent sieht dieselben Dateien wie sein Nutzer. Er kann auf dasselbe Netzwerk zugreifen. Im Zweifel hat er auch Zugriff auf lokal gespeicherte Zugangsdaten. Das betrifft etwa Git-Repositories, interne Tools oder Cloud-Dienste. Für ein Skript, das autonom Code schreibt und testet, ist das ein erhebliches Risiko. Das gilt unabhängig davon, wie zuverlässig das Modell arbeitet. Ein einziger falsch verstandener Befehl reicht aus. Auch eine kompromittierte Abhängigkeit genügt, damit sensible Daten das Unternehmen verlassen.
Wie die ESACA-Sandbox Zugriffe kontrolliert
Die Lösung des ESACA-Teams kapselt den Agenten in einer eigenen Sandbox. Standardmäßig hat er dort keinen Zugriff auf Dateien, Netzwerk oder Zugangsdaten. Für jedes Projekt legen Entwicklerinnen und Entwickler gezielt fest, welche Verzeichnisse der Agent sehen darf. Sie legen auch fest, mit welchen externen Diensten er sprechen darf. Das kann eine interne Wissensdatenbank sein, das Ticketsystem oder ein sogenannter MCP-Server, kurz für Model-Context-Protocol-Server. Jede ausgehende Anfrage aus der Sandbox läuft zunächst durch eine sogenannte Egress-Proxy-Komponente. Das ist eine Kontrollstelle, die jede ausgehende Verbindung filtert. Sie prüft, ob das Ziel der Anfrage auf der freigegebenen Liste steht. Alles andere blockiert sie. So bekommt der Agent genau den Ausschnitt der Außenwelt, den ein Projekt braucht. Nicht mehr, nicht weniger.
Zugangsdaten, die der Agent nie zu sehen bekommt
Besonders relevant ist das für Zugangsdaten. Passwörter, API-Schlüssel und Tokens bleiben in einem sogenannten Secret Vault, einem gesicherten digitalen Tresor für Zugangsdaten, auf dem Host-Rechner. Sie wandern nie in die Sandbox selbst. Erst kurz bevor eine freigegebene Anfrage rausgeht, kommt das Zugangstoken ins Spiel. Die Egress-Proxy-Komponente fügt es genau dann ein. Der Coding-Agent bekommt das Geheimnis also zu keinem Zeitpunkt zu Gesicht. Folglich kann er es weder versehentlich in generiertem Code hinterlassen noch an einen anderen Dienst weiterreichen.
„Wir setzen den Agenten in eine Box, in der er standardmäßig keinen Zugriff auf Dateien, Netzwerk oder Zugangsdaten hat“, sagt Trần. „Die Zugangsdaten bekommt der Coding-Agent zu keinem Zeitpunkt zu sehen, sie bleiben immer auf der eigenen Maschine.“
In wenigen Klicks vom A12-Projekt zur sicheren Agenten-Umgebung
Dieser Schutz soll im Alltag aber nicht zur Hürde werden. Deshalb hat das ESACA-Team eine Integrationsschicht für die A12 AI Low Code Plattform gebaut. Aus einem bestehenden A12-Projekt entsteht so in etwa fünf bis sechs Klicks eine fertig konfigurierte Sandbox. Ihr Coding-Agent bringt bereits alle relevanten A12-Plugins mit, dazu die A12-Wissensdatenbank und passende Standard-Zugriffsregeln. Genau diesen Weg ist auch das eingangs erwähnte HR-Projektteam gegangen. Es hat seine Sandbox dabei live demonstriert.
Auch die A12-Integration unterstützt inzwischen beide Coding-Agenten, Claude Code und OpenCode. Ausgeliefert wird ESACA über zwei Wege: eine Desktop-Anwendung und ein Kommandozeilen-Werkzeug. Beide erzeugen dieselbe Sandbox und laufen unter Windows, macOS und Linux. Für den Einstieg gibt es vorkonfigurierte Voreinstellungen mit sinnvollen Standard-Zugriffen. Diese lassen sich bei Bedarf jederzeit erweitern oder einschränken.
Was das für Ihre Organisation bedeutet
Sandboxing ist damit kein zusätzliches Sicherheitsformular, das den Entwicklungsalltag bremst. Es ist vielmehr ein technischer Mechanismus, der direkt in den Arbeitsablauf eingebaut ist. Entwicklerinnen und Entwickler behalten die Geschwindigkeit eines KI-Coding-Agenten. Die IT-Abteilung behält die Kontrolle darüber, was die eigene Infrastruktur überhaupt verlassen darf. Viele Organisationen müssen sich an Vorgaben wie NIS-2, ISO 27001, BaFin-Anforderungen oder die DSGVO halten. Für sie ist das ein wichtiger Unterschied. Es ist der Unterschied zwischen einer vagen Zusicherung und einem echten, technisch erzwungenen Kontrollpunkt. Laut Planung des Teams kommt die Sandbox noch in diesem Jahr. Sie soll dann eine erweiterte KI-Integration bieten, gemeinsam mit der Anbindung weiterer Coding-Agenten.
- Wie ESACA speziell für KRITIS-Unternehmen und Behörden Datenabfluss verhindert, zeigt der Artikel Agentic Coding ohne Datenabfluss: ESACA für KRITIS-Unternehmen und Behörden.
- Wie sich diese Sandbox in das Gesamtbild von ESACA einfügt, zeigt die Workbench. Sie ist die Produktionsumgebung für Coding-Agenten, mit verbindlichem Freigabeprozess und Audit-Trail. Die hier beschriebene Sandbox bildet dafür die technische Grundlage für kontrollierte Ausführung.
- Den größeren Zusammenhang zwischen KI und digitaler Souveränität erklärt der Artikel Digitale Souveränität bei KI: Europa muss jetzt handeln.
Sie möchten ESACA und die Sandbox für Coding-Agenten in Ihrer eigenen Umgebung sehen?
Häufig gestellte Fragen
Was ist die ESACA-Sandbox?
Eine isolierte Umgebung für einen KI-Coding-Agenten. Standardmäßig hat er dort keinen Zugriff auf Dateien, Netzwerk oder Zugangsdaten des Host-Rechners. Zugriffe werden projektbezogen freigegeben. Eine Egress-Proxy-Komponente kontrolliert sie.
Welche Coding-Agenten unterstützt die Sandbox aktuell?
ESACA unterstützt bereits heute Claude Code und OpenCode, sowohl generisch als auch für die A12-Integration.
Wie verhindert die Sandbox, dass Zugangsdaten in die falschen Hände geraten?
Zugangsdaten bleiben auf dem Host-Rechner. Die Egress-Proxy-Komponente fügt das passende Token erst kurz vor dem Versand ein. Der Agent selbst sieht das Geheimnis nie.
Auf welchen Systemen läuft die ESACA-Sandbox?
Sie ist über eine Desktop-Anwendung und ein Kommandozeilen-Werkzeug verfügbar. Beide nutzen dieselbe Sandbox und laufen unter Windows, macOS und Linux.
Wie lässt sich die Sandbox mit einem A12-Projekt verbinden?
Aus einem bestehenden A12-Projekt entsteht in etwa fünf bis sechs Klicks eine fertig konfigurierte Sandbox. Sie bringt einen A12-aware Coding-Agenten mit, dazu passende Plugins und Standard-Zugriffsregeln.
