Wenn du in den vergangenen zwei Jahren schon einmal mit Claude Code, Codex, Copilot und Co. experimentiert hast oder sogar täglich damit arbeitest, ist dir sicherlich schon die ein oder andere Marotte von KI-Agenten aufgefallen: Selbstständiges Suchen und Herunterladen von Inhalten aus dem Internet, der Versuch, ad-hoc undurchsichtigen Code in Python oder Bash auf deinem System auszuführen, oder neue Dateien in deinem Projekt, die du zuerst gar nicht bemerkt hast. Hinzu kommen gerade in den vergangenen Monaten Meldungen über KI-Agenten, die aus ihren Umgebungen heraus andere Server gezielt angegriffen haben, wie zum Beispiel in diesem Vorfall von OpenAI und Hugging Face.
Ganz egal ob es sich nun konkret um Anekdoten, das versehentliche Teilen von API-Tokens oder Firmen- und Kundendaten mit KI-Agenten oder zu eigenständige LLMs in den Tiefen des Internets handelt, all diese Fälle vereinen zwei Schwachstellen:
- KI-Agenten haben in den Umgebungen, auf denen sie ausgeführt werden, oft weitreichende Berechtigungen, wenn diese nicht von vornherein präzise eingeschränkt werden; Ad-hoc ausgeführte Scripts und abgelegte Dateien sind oft unübersichtlich und auf den ersten Blick schwer einzuordnen.
- Gerade bei der Nutzung sogenannter Frontier-Modelle von Anthropic, OpenAI, xAI und Co können sensible Daten abfließen und für weiteres Training der Modelle genutzt werden – oft ist ein individueller oder organisationsweiter Opt-Out notwendig, um das zu verhindern.
In diesem Artikel gucken wir uns deswegen an, wie du mit sbx, OpenCode und einer datenschutzkonformen AI-Lösung wie NWS Managed AI Models sichere und souveräne KI-Agenten betreiben kannst, die diese Schwachstellen erheblich eindämmen können. Das Ergebnis ist eine isolierte Sandbox mit kontrolliertem Netzwerkzugriff, nicht extrahierbaren Secrets und einem DSGVO-konform LLM, das in einem deutschen, ISO27001-zertifizierten Rechenzentrum betrieben wird.
sbx und OpenCode im Überblick
sbx ist ein CLI-Projekt von Docker, um KI-Agenten dedizierte Sandboxes in Form von isolierten Micro-VMs zur Verfügung zu stellen. Es ist nicht Open-Source, aber kostenlos für private und kommerzielle Zwecke nutzbar und auf GitHub und für viele Paketmanager zur Installation verfügbar. Mit sbx werden wir im Laufe dieses Artikels ein kontrolliertes Umfeld für unsere KI-Agenten schaffen, in dem sie frei schalten und walten können.
OpenCode ist ein Open-Source AI Coding Agent, manchmal auch Agent Harness genannt, vergleichbar mit Claude Code oder Gemini CLI. Das Projekt wird auf GitHub kontinuierlich weiterentwickelt und ermöglicht es deinen KI-Agenten, sich mit einer Vielzahl kostenloser und kostenpflichtiger LLMs zu verbinden. Mit OpenCode werden wir in diesem Artikel unsere KI-Agenten betreiben.
Vorbereitungen und Installation
Folgende Dinge müssen wir vorbereiten, bevor wir mit sbx und OpenCode experimentieren können:
- einen Account bei Docker (die Nutzung von sbx erfordert einen eingeloggten Docker-Account, die Nutzung selbst ist kostenlos)
- beide CLIs müssen auf unserem System installiert sein. Die Installationsanweisungen für viele Umgebungen findest du hier:
- ein Verzeichnis, in dem wir mit unseren KI-Agenten arbeiten können, zum Beispiel
secure-sandbox/ - [Optional] einen API-Key für die Nutzung der NWS Managed AI Models, die wir in diesem Artikel nutzen werden (alternativ bietet OpenCode auch die Nutzung kostenloser Modelle an oder du verbindest dich mit einem bereits von dir genutzten Provider)
Konfiguration von NWS Managed AI Models
Möchtest du gehostete AI-Modelle von NWS in OpenCode nutzen, musst du außerdem eine Datei opencode.json in deinem Arbeitsverzeichnis erstellen:
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"nws-ai": {
"npm": "@ai-sdk/openai-compatible",
"name": "NWS Managed AI",
"options": {
"baseURL": "https://api.ai.nws.netways.de/qwen/v1",
"apiKey": "{env:NWS_AI_API_KEY}"
},
"models": {
"qwen3.8-27B": {
"name": "Qwen3.8-27B"
}
}
}
}
}Mit dieser Konfiguration kannst du die von uns gehosteten Modelle in OpenCode nutzen – NWS Managed AI Models sind noch nicht als offizieller Provider in OpenCode verfügbar, wir arbeiten aber daran.
Initialisierung von sbx
Bevor wir unsere erste Sandbox mit sbx starten, ist es außerdem ratsam, die Global Network Policy für alle Sandboxes auf unserem System zu initialisieren:
sbx policy init balancedDas Balanced Profil erlaubt Sandboxes den Zugriff auf die APIs der gängigen LLM-Anbieter und anderer Seiten, die für die Entwicklung mit KI-Agenten sinnvoll sind (z.B. GitHub).
Definition von Secrets für Sandboxes
Die in der Konfiguration erwähnte Umgebungsvariable NWS_AI_API_KEY, aus der OpenCode später den API-Key für die Kommunikation mit den gehosteten LLMs ausliest, können wir im Anschluss direkt in sbx als Custom Secret definieren:
sbx secret set-custom \
--env NWS_AI_API_KEY \
--host api.ai.nws.netways.de \
--value <API_KEY>
sbx secret lsDie Liste aller Secrets in sbx sollte im Anschluss etwa so aussehen:
CUSTOM SECRETS
SCOPE TARGETS ENV PLACEHOLDER SECRET
(global) api.ai.nws.netways.de NWS_AI_API_KEY sbx-cs-zn6uAnmceeAMBbIG uNr2Qv******...******k0ihFür einige andere Anbieter von LLMs gibt es vorgefertigte Secret-Formate, die du anstelle von NWS mittels sbx secret set statt sbx secret set-custom setzen kannst.
Der erste Start
Sind alle Vorbereitungen abgeschlossen, können wir unsere sichere und souveräne Sandbox für unseren KI-Agenten zum ersten Mal starten:
sbx run opencode --detached
── RESOLVE SETUP
resolving configuration…
sandbox opencode-secure-sandbox
agent opencode
workspace /Users/daniel/repositories/private/secure-sandbox (rw)
skills /Users/daniel/Library/Application Support/com.docker.sandboxes/sandboxes/agent-skills → /home/agent/.config/opencode/skills · 0 folders · (ro)
image docker/sandbox-templates:opencode-docker
cpu 10
memory 8 GiB
✓ configuration resolved
── PREPARE IMAGE
→ pull docker/sandbox-templates:opencode-docker
✓ image ready
Warning: no OpenAI credentials available. opencode will start logged-out.
To set credentials on the host before creating sandboxes, run one of:
sbx secret set openai --oauth # Sign in with ChatGPT (recommended)
sbx secret set openai # OpenAI API key (reads from stdin)
── CREATE SANDBOX
✓ Created sandbox opencode-secure-sandbox
Starting opencode agent in sandbox 'opencode-secure-sandbox'...
Workspace: /Users/daniel/repositories/private/secure-sandbox
c0431097-7889-47d4-90a2-debc457aa9b0Die erste Ausführung dauert einen Moment, da sbx zuerst die Umgebung selbst herunterladen muss.
Diese enthält entsprechend unseres Befehls OpenCode. In der Ausgabe des Befehls finden wir außerdem die zugewiesenen Ressourcen der Sandbox, welche Skills und Verzeichnisse mit ihr geteilt wurden, und den Namen und die ID der Sandbox.
Diesen Namen (bzw. die ID) können wir nutzen, um zuerst einmal zu prüfen, ob das von uns definierte Secret innerhalb der Sandbox entsprechend propagiert wurde:
sbx exec -it opencode-secure-sandbox env | grep NWS_AI_API_KEY
NWS_AI_API_KEY=sbx-cs-zn6uAnmceeAMBbIGDie Umgebungsvariable existiert innerhalb unserer Sandbox und entspricht dem für das Secret definierten Platzhalter (s.o.); Unser KI-Agent arbeitet also nie mit dem eigentlichen API-Key.
Jetzt sind alle Voraussetzungen gegeben, um eine interaktive Session in OpenCode innerhalb der Sandbox zu starten, und uns einmal etwas umzuschauen:
sbx run --name opencode-secure-sandboxEs öffnet sich das OpenCode-Terminal. Hier geben wir /models ein, bestätigen mit Enter, suchen im Anschluss nach NWS und wählen aus den angezeigten Ergebnissen das Modell Qwen3.8-27B von NWS Managed AI, das wir in unserer opencode.json definiert haben.
Im Anschluss können wir unsere erste Anfrage an das LLM stellen – in der Theorie; Schickst du eine erste Nachricht an Qwen, bleibt eine Antwort aus und es erscheint folgende Fehlermeldung:
Forbidden: Blocked by network policy: domain api.ai.nws.netways.de:443
detail: no matching allow rule — blocked by default deny policyDoch warum?
Policies in sbx
Unsere Sandbox tut, was sie soll: Sie isoliert unseren KI-Agenten von unserer restlichen Umgebung, und, fast noch wichtiger, von fremden Umgebungen (z.B. dem Internet). Im während der Einrichtung von sbx gesetzten Balanced Profil für unsere Sandboxes ist der API-Endpunkt von NWS Managed AI Models nicht enthalten – wir müssen ihn also nachträglich in einem zweiten Terminal hinzufügen:
sbx policy allow network api.ai.nws.netways.deDie gesetzte Policy greift für alle Sandboxes, auch bereits laufende. Mit dem Parameter --sandbox kannst du Policies auf bestimmte Sandboxes beschränken. Schicke eine weitere Nachricht an das LLM in deiner laufenden OpenCode-Sandbox – dieses Mal solltest du eine Antwort erhalten.
Policies kannst du noch deutlich granularer gestalten, zum Beispiel indem du nur einzelne erlaubte HTTP-Methoden oder Anfragepfade freigibst. Wildcards werden hierbei ebenfalls unterstützt.
Für Zugriff auf Dateien auf deinem System sieht die Isolation der Sandbox etwas anders aus: Das Arbeitsverzeichnis, aus dem du die Sandbox erstellt hast, wird automatisch als schreibbares Verzeichnis in deine Sandbox gemountet und auch dort zum Arbeitsverzeichnis. Zusätzlich kannst du weitere Pfade angeben, die ebenfalls gemountet werden. Als Beispiel können wir uns den folgenden Befehl zur Erstellung einer neuen Sandbox anschauen:
sbx create opencode \
./demo-app \
./demo-design:ro \
./demo-app/package-lock.json:roDieser Befehl…
- …erstellt eine neue Sandbox für OpenCode als genutzten KI-Agenten
- …mountet das Verzeichnis
demo-app/als schreibbares Arbeitsverzeichnis - …mountet das Verzeichnis
demo-design/als nicht schreibbares Verzeichnis - …mountet die Datei
package-lock.jsonim schreibbaren Arbeitsverzeichnis als nicht schreibbare Datei
Wir können unseren KI-Agenten also feingranular Zugriff auf genau die Verzeichnisse und Dateien geben, die sie für ihre Arbeit benötigen – allerdings nur bei der Erstellung der Sandbox
Die Architektur von sbx im Überblick
Gerade die Einschränkungen der Sandboxes im Netzwerkbereich und die Verwendung von definierten Secrets kann einen anfangs auf dem falschen Fuß erwischen. Wie kann die Sandbox mit NWS Managed AI Models kommunizieren, wenn sie doch nachweislich nicht auf den eigentlichen API-Key zugreifen kann? Und wie funktioniert die Einschränkung erlaubter Netzwerkkommunikation durch definierte Policies?
Die Antwort auf beide Fragen liefert die Architektur von sbx auf unserem System:
Jede definierte Sandbox auf unserem System entspricht einer isolierten MicroVM – Dateien, Dienste und sonstige Artefakte, die in ihr angelegt oder ausgeführt werden, sind persistent, auch über Neustarts der jeweiligen Sandbox hinweg. Sämtlicher Netzwerkverkehr aus der Sandbox wird beim Verlassen der isolierten Umgebung gegen die definierten Network Policies geprüft und im Anschluss an einen Proxy auf unserem eigentlichen System weitergeleitet.
Dieser Proxy ist es auch, der unseren API-Key für NWS Managed AI Models aus dem Credential Store auf unserem System in die Anfrage injiziert. Bis zu diesem Punkt enthielt die Anfrage lediglich den in der Sandbox verfügbaren Platzhalter.
Durch diese Architektur erreicht sbx eine gute Balance aus Sicherheit und Flexibilität: Netzwerkanfragen können granular freigegeben werden und Secrets werden ordentlich auf Systemebene verwaltet und können bei Bedarf einzelnen Sandboxes zur Verfügung gestellt werden.
Die Sandboxes selbst können ihre Berechtigungen nicht eigenständig erweitern – die Bewertung, ob der Zugriff auf Dienste über das Netzwerk oder auf Secrets aus einer Sandbox heraus erfolgen darf, geschieht außerhalb der jeweiligen Sandbox.
Spaß im Sandkasten mit sicheren und souveränen KI-Agenten
Für den Umfang dieses Artikels reichen die bisher gezeigten Eigenschaften von sbx und OpenCode allemal, das Ende der Möglichkeiten ist allerdings noch lange nicht erreicht: So beinhalten die von Docker bereitgestellten Sandboxes zum Beispiel alle eine voll funktionale Docker-Umgebung – du kannst also ganze Testumgebungen innerhalb deiner Sandboxes provisionieren und deinen KI-Agenten so noch mehr Mittel zur Hand geben, autonom zu entwickeln.
Haben sich die spezifischen Konfigurationen in deinem Umgang mit sbx Sandboxes einmal herauskristallisiert, kannst du diese außerdem in sogenannten Kits spezifizieren und diese auch deinen Kollegen verfügbar machen – so bleiben deine Sandboxes deklarativ reproduzierbar und das gesamte Team arbeitet mit dem gleichen Stand, den gleichen Einschränkungen und Sicherheitsmaßnahmen. Und wenn du mehrere verschiedene Sandboxes parallel betreibst oder zwischen ihnen hin und her wechselst, ist eventuell sbx‘ Terminal User Interface (TUI) interessant für dich.
sbx und OpenCode lösen sicherlich nicht alle Probleme, die man momentan im Umgang mit KI-Agenten beobachten kann, und niemand kann sicher wissen, zu welchen Mitteln wir in 1-2 Jahren zur Absicherung von KI-unterstützter Softwareentwicklung greifen werden. Das Konzept von isolierten MicroVMs mit konfigurierbaren Freigaben für Secrets, Netzwerkverkehr und Zugriff auf Dateisysteme in Kombination mit souveränen, datenschutzkonformen LLMs wie den NWS Managed AI Models ist allerdings auf jeden Fall ein Schritt in die richtige Richtung, und das Experimentieren mit sbx hat uns intern viel Spaß gemacht – wir sind gespannt, was du davon hältst!
Wenn du deine bestehende Sandbox nach Ende dieses Artikels löschen möchtest, geht das mit einem der folgenden Befehle:
# Liste alle Sandboxes
sbx ls
# Lösche eine Sandbox
sbx rm <name>
# Setze sbx komplett zurück
sbx reset
0 Kommentare