01
Der Client
Ein isolierter Arbeitsplatz für Coding-Agenten — auf dem eigenen Rechner oder im eigenen Cluster. Nichts geht hinaus, was nicht erlaubt wurde, und jeder Aufruf nach außen wird festgehalten.
Werkzeug · Hier wird gearbeitet
Sandbox
In der Sandbox arbeiten Ihre Teams mit Coding-Agenten, ohne etwas aus der Hand zu geben: Projekt und Agent laufen im einen Container, der gesamte ausgehende Verkehr im anderen. Dort liegen die echten Zugangsdaten — der Agent bekommt sie nie zu sehen. Und das gesamte Setup steckt in einer Konfiguration, die sich teilen lässt.
Drei Teile, ein Konzept
Mehr als eine Kiste um den Agenten
Eine Sandbox, die am Rand eines Laptops endet, macht lediglich eine selbst auferlegte Regel erträglich. Die Sandbox besteht aus drei Teilen, die sich erst zusammen auszahlen.
02
Die Konfiguration
Eine Datei beschreibt die gesamte Umgebung: Zugriffsregeln, Agents, Skills, Plugins, Werkzeuge und Versionen. Ein Setup hört auf, persönliches Wissen zu sein, und wird zu einem Artefakt, das man übergeben kann.
03
Der Hub
Jedes Projekt spielt seine Konfiguration zurück und zieht erprobte heraus. Sichtbar wird, welche Setups tatsächlich genutzt werden — statt dass gute Praxis dort bleibt, wo sie entstanden ist.
Wie die Isolation funktioniert
Ihre Geheimnisse liegen nicht beim Agenten
Sicherheit ist hier Architektur, nicht Richtlinie — der Agent wird nicht gebeten, sich zu benehmen, sondern dorthin gestellt, wo Fehlverhalten keine Wirkung hat.
Standardmäßig nichts erlaubt
Eine frische Sandbox erreicht nichts. Jedes Ziel wird als Regel geöffnet: Protokoll, Host, Pfad und, wo nötig, die Zugangsdaten, die dabei eingesetzt werden.
Zugangsdaten bleiben draußen
Die echten Geheimnisse liegen im Egress-Container, nicht im Arbeitsplatz. Dort stehen Platzhalter; eingesetzt wird erst auf dem Weg nach außen.
Getrennt gebaut
Eine Sandbox besteht aus zwei Containern: einer für Projekt und Agent, einer für allen ausgehenden Verkehr. Dieselbe Trennung trägt lokal wie im Cluster.
Alles ist belegt
Jede Entscheidung des Egress steht im Protokoll — erlaubt, eingesetzt, blockiert. Das ist die Grundlage für den Nachweis, den regulierte Umgebungen verlangen.
Im Einsatz
Was die Sandbox kann
Verfügbar für macOS, Windows und Linux — als Desktop-App und als Kommandozeile, die dieselben Sandboxen bedienen.
App und Kommandozeile
Anlegen, verbinden, Zugriffe prüfen — grafisch oder im Terminal. Beide Wege sprechen denselben lokalen Dienst, Sie können jederzeit wechseln.
Terminal eingebaut
Bis zu vier Shells je Sandbox, teilbar nach rechts und unten, per Tastatur erreichbar. Eine laufende Shell überlebt den Wechsel des Reiters.
Agenten mitgeliefert
OpenCode und Claude Code stecken in festgesetzten Versionen im Image. Die Sandbox öffnet den Agenten beim Start und nennt ihm die Werkzeuge, die er hat.
Erweiterungen wandern mit
Plugins, Skills, Agenten-Definitionen und Marketplaces werden auf dem Rechner erkannt und schreibgeschützt eingehängt. Ihr gewohntes Setup bleibt Ihr Setup.
MCP-Server ohne Tokenweitergabe
Der Server läuft in der Sandbox, sein Token bleibt draußen und wird erst am Rand eingesetzt. Die Übersicht zeigt außerdem, welcher Server überhaupt eine Regel hat.
Zugriffsregeln als Vorlagen
Für wiederkehrende Unternehmensdienste — Artefakt-Repository, Git über HTTPS — gibt es fertige Regelsätze. Eine neue Regel erreicht jede laufende Sandbox in etwa einer Sekunde.
Egress-Protokoll
Erlaubt, eingesetzt, blockiert — jede Entscheidung in der Reihenfolge, in der sie fiel. Fehlt ein Ziel, geben Sie es direkt aus dem Protokoll frei.
Images nach Maß
Fertige Presets, ein eigenes Image oder ein eigenes Dockerfile. Zusätzliche Pakete geben Sie beim Anlegen an, Ports und Umgebungsvariablen ebenso.
Verbrauch je Sandbox
Token-Verbrauch wird pro Sandbox und Agent gezählt, tagesweise über ein Jahr. Damit lässt sich beantworten, was ein Vorgehen tatsächlich kostet.
Im echten Projekt
Gebaut für gewachsene Codebasen
Erprobt an einem Unternehmensprojekt mit Gradle, pnpm und Python hinter einem internen Artefakt-Repository.
Ihr Verzeichnis, Ihre Ports
Das Projekt wird eingehängt, weitere Verzeichnisse kommen schreibgeschützt dazu, und veröffentlichte Ports erreichen Sie wie lokal.
Build-Ausgaben bleiben schnell
Verzeichnisse wie node_modules, target oder .venv liegen auf sandboxeigenen Volumes statt auf dem geteilten Dateisystem.
TLS läuft durch
curl, git, Java, pip, Node und uv vertrauen dem Proxy. Im Projekt muss niemand an Zertifikaten schrauben.
Einmal anmelden
Eine geteilte Agenten-Konfiguration gilt für alle Sandboxen. Persönliche Anmeldungen bleiben getrennt, Plugins und Skills werden schreibgeschützt geteilt.
Eine Systemprüfung kontrolliert die Umgebung vor dem ersten Start und sagt, was zu tun ist.
Vorkonfiguriert
Eine Sandbox, die mit dem Vorwissen Ihrer Kollegen startet
Eine Sandbox kommt mit den Werkzeugen, Regeln und dem Wissen, die der jeweilige Kontext braucht — damit der erste Tag mit Arbeiten vergeht und nicht mit Einrichten.
Pro Projekt
Werkzeuge, Versionen und Zugriffsregeln einer Codebasis, gepflegt von denen, die sie kennen. Neue Teammitglieder starten auf dem fertigen Setup.
Pro Rolle
Unterschiedliche Arbeit braucht unterschiedliche Werkzeuge. Ein Infrastruktur-Team und ein Implementierungs-Team teilen sich eine Basis, aber nicht dieselben Voreinstellungen.
Pro Domäne
Auf eine Branche zugeschnitten, mit ihren Regeln und ihrem Vokabular. Der Weg dorthin führt über die Konfigurationen, die aus den Projekten zurückkommen.
Der Kreislauf
Von einem guten Setup zum Unternehmensstandard
Man kann nicht von jeder Entwicklerin verlangen, sich ein sicheres, produktives Agenten-Setup selbst zu erarbeiten. Das macht einmal jemand mit der nötigen Tiefe — und alle anderen erben es.
01
Arbeiten
Ein Team arbeitet in der Sandbox und formt dabei das Setup, das zu seinem Projekt passt.
02
Festhalten
Das Setup wird als eine Konfiguration exportiert, statt im Kopf einer Person zu leben.
03
Teilen
Die Konfiguration geht in den Hub, wo andere Projekte sie finden und übernehmen können.
04
Verbessern
Sichtbar wird, was tatsächlich übernommen wird — und der Benchmark kann messen, ob es wirklich besser läuft.
Der Status quo
Cloud-Coding-Assistenten sind ein Risiko in regulierten Umgebungen
01
IP verlässt das Haus
Quellcode, Geheimnisse und Architektur-Know-how werden an US-Hyperscaler gesendet, typischerweise außerhalb Ihres eigenen Vertragsrahmens.
02
Compliance-Konflikt
Anforderungen aus NIS-2, BaFin/MaRisk, ISO 27001 und DSGVO lassen sich mit SaaS-Coding-Tools nicht verlässlich nachweisen.
03
Verbot oder Schatten-IT
Die Folge: Pauschale Verbote bremsen die Entwicklung, oder Teams nutzen Tools an der IT vorbei. Beides ist teuer.
Eine Sandbox schützt eine Entwicklerin.
Eine geteilte Konfiguration schützt ein Unternehmen.
Und macht es gleichzeitig schneller.
