Google Cloud Run Sandboxes: Zero-Trust-Isolation für KI-Code in Millisekunden

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · Baut Cloud- und Plattform-Infrastruktur für US- und EU-Teams

Die kurze Antwort

Was hat Google konkret veröffentlicht?

Am 10. Juli 2026 überführte Google Cloud auf dem WeAreDevelopers World Congress Cloud Run Sandboxes in die öffentliche Preview. Eine Sandbox ist eine leichtgewichtige, isolierte Ausführungsgrenze, die Sie nahezu sofort innerhalb einer bestehenden Cloud-Run-Dienstinstanz erzeugen. Statt einen separaten Container-Cluster aufzusetzen oder für einen spezialisierten Micro-VM-Dienst zu zahlen, erstellt Ihre Anwendung eine wegwerfbare, abgeschottete Umgebung auf der Rechenleistung, die sie ohnehin hat, führt darin etwas ungeprüften Code aus und räumt sie wieder ab.

Das Problem, das es adressiert, ist konkret und zunehmend verbreitet: Wie führen Sie Code sicher aus, den ein LLM geschrieben oder ein Nutzer eingereicht hat, ohne Ihre Host-Anwendung, Ihre Daten und Ihre Google-Cloud-Zugangsdaten zu gefährden? Google versteht dies als Antwort auf einen Wandel im Anwendungsdesign, bei dem es zur Routine wird — und nicht mehr die exotische Ausnahme ist —, ein Modell Code schreiben und ausführen zu lassen, sei es für Datenanalyse, Browsing oder Automatisierung. Es ist dasselbe Muster, das uns immer wieder begegnet, wenn Kunden uns bitten, agentische Funktionen zu bauen: Der Agent ist nur nützlich, wenn er handeln kann, und Handeln bedeutet oft, Code auszuführen, den Sie nicht geschrieben haben und dem Sie nicht vollständig vertrauen können.

Google nennt drei konkrete Anwendungsfälle. LLM-Code-Interpreter lassen ein Modell Python, R oder SQL schreiben und ausführen, um einen Datensatz zu analysieren, Diagramme zu erzeugen oder anspruchsvolle Berechnungen on demand durchzuführen. Headless-Browser geben einem Agenten einen abgeschotteten Ort, um Seiten zu scrapen, Screenshots zu erstellen und Web-Workflows zu automatisieren. Und ganz klassischer von Nutzern eingereichter Code — Plugins, Skripte, Wettbewerbsbeiträge — kann laufen, ohne zum Einfallstor in Ihren Dienst zu werden. Die Sandboxes werden außerdem in Googles Agent Development Kit (ADK) integriert: Ein neuer CloudRunSandboxCodeExecutor lässt einen auf Cloud Run laufenden ADK-Agenten Code in einer einzigen Zeile ausführen, und Anwendungen können Sandboxes auch direkt per Standard-Subprocess-Aufrufen erzeugen.

Wie funktioniert die Isolation?

Das Sicherheitsmodell ruht auf drei Grenzen, und es lohnt sich, sie genau zu verstehen, weil sie definieren, was die Funktion schützt und was nicht. Die erste ist die Isolation der Zugangsdaten: Eine Sandbox kann die Umgebungsvariablen des Cloud-Run-Dienstes nicht lesen und den Google-Cloud-Metadatenserver nicht aufrufen. Das ist entscheidend, denn der Metadatenserver ist der übliche Weg, über den ein Workload seine Service-Account-Tokens bezieht; davon abgeschnitten hat im Sandbox laufender Code keinen Pfad zu Ihrer Identität oder Ihren Secrets, selbst wenn er danach sucht.

Die zweite ist ausgehender Netzwerkverkehr, standardmäßig verweigert. Von Haus aus hat eine Sandbox keinerlei ausgehenden Netzwerkzugriff; muss der Code eine API erreichen, aktivieren Sie den Egress explizit für diesen Aufruf, statt eine Tür offenzulassen. Für alle, die schon einmal beobachtet haben, wie schädlicher Code Daten exfiltrieren oder „nach Hause telefonieren“ will, ist eine standardmäßig verweigernde Netzwerkhaltung genau die richtige Form. Die dritte ist ein sicheres Dateisystem-Overlay: Die Sandbox sieht das Dateisystem Ihres Containers schreibgeschützt — sie kann also Ihre installierten Pakete, Laufzeiten und Binaries nutzen —, schreibt aber alles in ein isoliertes, temporäres In-Memory-Overlay, das am Ende der Ausführung verworfen wird. Nichts, was der Code schreibt, überlebt, und nichts, was er tut, verändert Ihren laufenden Dienst.

Zwei betriebliche Fakten runden das Bild ab. Zur Performance: Sandboxes starten in Millisekunden, und Googles Demo ließ 1.000 davon einen vollständigen Start-Ausführ-Stopp-Zyklus bei durchschnittlich 500 ms je Sandbox durchlaufen — schnell genug, um Sandboxing pro Anfrage realistisch zu machen, statt nur als Batch-Trick. Zu den Kosten: Da sie auf der bereits Ihrer Instanz zugewiesenen CPU und dem Arbeitsspeicher laufen und nicht auf dedizierten VMs, gibt es laut Google keinen Aufpreis für die Nutzung, und während der öffentlichen Preview ist sie kostenlos. Dieses Preismodell ist die leise Schlagzeile: Isolierte Code-Ausführung bedeutete bisher, pro Aufruf einen spezialisierten Sandbox-Host zu bezahlen; sie in Serverless-Compute zu falten, für das Sie ohnehin zahlen, verändert die Ökonomie.

Warum ist das jetzt relevant?

Sichere Code-Ausführung ist still und leise zu einem der tragenden Probleme der Agenten-Ära geworden. Jedes ernsthafte Agenten-Framework stößt irgendwann an dieselbe Wand: Um nützlich zu sein, muss der Agent Code ausführen, und beliebigen Code neben Ihrer Anwendung laufen zu lassen ist der Weg, auf dem Sie Ihre Daten oder Ihr Cloud-Konto verlieren. Teams haben das mit gVisor, Firecracker-Micro-VMs, spezialisierten Sandbox-Startups oder aufwändiger Kubernetes-Isolation gelöst — was alles funktioniert und alles echter Engineering- und echter Betriebsaufwand ist. Eine verwaltete Sandbox, die innerhalb Ihrer bestehenden Serverless-Laufzeit lebt, senkt diese Hürde für eine große Klasse von Anwendungen.

Es ist auch Teil eines sichtbaren Trends über die großen Clouds hinweg. Google liefert Isolations-Primitive für Agenten an beiden Enden seines Compute-Spektrums aus — eine GKE Agent Sandbox für Kubernetes-lastige Workloads und nun Cloud Run Sandboxes für die Serverless-Seite. Wenn Ihre Plattformstrategie auf Kubernetes setzt, passt womöglich der GKE-Weg; sind Sie bereits Serverless-first auf Cloud Run, holen die neuen Sandboxes Sie dort ab, wo Sie stehen. So oder so lautet das Signal: Die Hyperscaler behandeln „führe diesen ungeprüften Code sicher aus“ nun als erstklassige Plattformfähigkeit statt als etwas, das jedes Team neu erfindet.

Was das für US- & EU-Softwareteams bedeutet

Zieht man den Launch ab, bleiben drei dauerhafte Konsequenzen. Die erste: Isolierte Ausführung ist jetzt der erwartete Standard für Code-ausführende Agenten. Wenn Sie eine KI-Funktion bauen, die Code schreibt und ausführt, ist es nicht mehr vertretbar, ihn im selben Prozess laufen zu lassen — das Werkzeug zu seiner Isolation ist günstig und verfügbar. Denken Sie die Ausführungsgrenze von Anfang an mit; Isolation nach einem Vorfall nachzurüsten ist der teure Weg, und der Vorfall ist die Art, die in einem Breach-Report endet.

Die zweite: Isolation ist eine Kontrolle, kein Compliance-Zertifikat. Cloud Run Sandboxes kappen Zugangsdaten, Netzwerk und Persistenz und schließen damit die gefährlichsten Lücken — aber wenn Sie im FinTech-Bereich arbeiten oder regulierte Daten verarbeiten, gehören Ihnen weiterhin die härteren Fragen: welche Daten Sie in die Sandbox lassen, wohin Egress gehen darf, wie Sie protokollieren und prüfen, was der Agent ausgeführt hat, und wie all das auf DSGVO, SOC 2 oder die Regeln Ihrer Branche abbildet. Behandeln Sie die Sandbox als eine Ebene in einem Defense-in-Depth-Design und halten Sie sie in Ihrer normalen Sicherheitsprüfung, statt anzunehmen, eine verwaltete Funktion lasse das Bedrohungsmodell verschwinden.

Die dritte ist architektonisch und gilt providerübergreifend: Halten Sie die Ausführungsebene austauschbar. Cloud Run Sandboxes sind attraktiv, aber Alternativen sind es auch, und die Isolationslandschaft bewegt sich schnell. Setzen Sie die Code-Ausführung des Agenten hinter eine saubere Schnittstelle, sodass Sie sie heute auf Cloud Run betreiben und morgen verschieben können — zu GKE, zu einer anderen Cloud, zu einer selbst gehosteten Sandbox — ohne den Agenten neu zu schreiben. Diese Portabilität ist jetzt günstig zu bauen und später schmerzhaft nachzurüsten, und es ist dieselbe Disziplin, die jede Cloud-Plattform wartbar hält, wenn Anbieter ihre Konditionen und Fähigkeiten ändern.

Was jetzt zu tun ist

Hier die auslieferbare Fassung. Behandeln Sie Cloud Run Sandboxes als Anstoß, die Code-Ausführungs-Story Ihres Agenten richtig aufzusetzen — ob Sie diese konkrete Funktion nun übernehmen oder nicht.

1. Isolieren Sie Code-Ausführung standardmäßig. Wenn ein Agent oder Nutzer Code ausführen kann, sollte er niemals im Prozess Ihrer Anwendung mit Zugriff auf Ihre Zugangsdaten laufen.
2. Verweigern Sie Netzwerk und Secrets, dann gewähren Sie eng. Beginnen Sie bei null Egress und ohne Zugriff auf Zugangsdaten; öffnen Sie nur die konkreten Pfade, die eine Aufgabe wirklich braucht.
3. Halten Sie die Sandbox-Ebene austauschbar. Setzen Sie die Ausführung hinter eine Schnittstelle, sodass Cloud Run, GKE oder eine andere Sandbox sie tragen können, ohne den Agenten neu zu schreiben.
4. Protokollieren Sie, was der Agent ausgeführt hat. Erfassen Sie Eingaben, Code und Ausgaben für Audit und Incident-Review; ein verworfenes Overlay ist gute Hygiene, aber kein Audit-Trail.
5. Nehmen Sie es in Ihr Bedrohungsmodell auf. Eine verwaltete Sandbox ist eine Kontrolle; prüfen Sie sie zusammen mit Datenflüssen, Egress-Regeln und Ihren Compliance-Pflichten.
6. Pilotieren Sie, bevor Sie sich festlegen. Preview-Funktionen ändern sich; validieren Sie Latenz, Limits und Verhalten an Ihrem realen Workload, bevor sie auf einem kritischen Pfad sitzt.

Nichts davon ist Rechtsberatung, und Ihre genauen Pflichten hängen von Branche und Rechtsraum ab. Doch das strategische Signal ist klar: KI-geschriebenen Code sicher auszuführen wird auf den großen Clouds zu einem gelösten, günstigen Standard, und es gewinnen die Teams, die Isolation früh mitdenken, sie austauschbar halten und die Sandbox als eine Kontrolle in einer größeren Sicherheitshaltung behandeln.

Häufig gestellte Fragen

Quellen

Google Cloud Blog — Google Cloud Run sandboxes are in public preview
SecurityBrief Australia — Google Cloud puts Cloud Run sandboxes into preview
Google Cloud Documentation — Code execution in Cloud Run