4 Punkte von GN⁺ 2026-02-04 | 1 Kommentare | Auf WhatsApp teilen
  • Bietet eine sichere Linux-MicroVM-Umgebung zur sicheren Ausführung nicht vertrauenswürdigen Codes
  • Verhindert durch Schutz von Geheimschlüsseln und Kontrolle des Netzwerkzugriffs während der Codeausführung das Risiko von Datenabfluss bei von LLMs generiertem oder von Nutzern bereitgestelltem Code
  • Mit dem Befehl sandbox.deploy() ist eine direkte Bereitstellung auf Deno Deploy aus der Entwicklungsumgebung möglich, ohne separaten Build- oder Authentifizierungsprozess
  • Mit Volumes und Snapshots lassen sich Cache, Datenbanken und Entwicklungsumgebungen schnell reproduzieren
  • Geeignet für Code-Ausführungsumgebungen mit Sicherheitsanforderungen wie AI-Agenten, Plugin-Systeme und CI-Runner

Überblick über Deno Sandbox

  • Deno Sandbox bietet die Ausführung nicht vertrauenswürdigen Codes in einer leichtgewichtigen Linux-MicroVM in der Deno-Deploy-Cloud
    • Erstellung über das JavaScript- oder Python-SDK möglich, Boot-Zeit unter 1 Sekunde
    • Direkte Interaktion über SSH, HTTP und VS Code möglich
  • Ziel ist es, Sicherheitsprobleme bei externen Aufrufen inklusive API-Schlüsseln zu lösen, wenn Code von LLMs generiert oder von Nutzern bereitgestellt wird
  • In der Sandbox ausgeführter Code wird durch Systemisolierung und eine mehrschichtige Defense-in-depth-Architektur geschützt

Secrets That Can’t Be Stolen

  • In der Sandbox-Umgebung werden Geheimschlüssel nicht als echte Umgebungsvariablen offengelegt
    • Innerhalb des Codes ist nur auf Placeholder-Strings zugreifbar
    • Die echten Schlüssel werden nur bei ausgehenden Anfragen an freigegebene Hosts eingefügt
  • Beispielsweise wird OPENAI_API_KEY nur bei Anfragen an api.openai.com aktiviert und bei einem Abfluss an andere Domains unwirksam gemacht
  • Dadurch lassen sich Versuche zur Schlüsselentwendung durch Prompt Injection oder schädlichen Code verhindern
Anzeige

Network Egress Control

  • Die Sandbox blockiert Netzwerkanfragen außerhalb der Liste erlaubter Hosts (allowNet)
    • Beispiel: ["api.openai.com", "*.anthropic.com"]
  • Der gesamte Netzwerkverkehr wird an der VM-Grenze blockiert, und Richtlinien werden über einen Outbound-Proxy ähnlich coder/httpjail angewendet
  • Künftig sind Analysen ausgehender Verbindungen sowie programmierbare Hooks zur Inspektion und Modifikation von Anfragen geplant
  • In Kombination mit Denos --allow-net-Flag lässt sich eine doppelte Netzwerksicherheitsschicht aufbauen

Sandbox to Production

  • Mit dem Befehl sandbox.deploy() ist eine direkte Bereitstellung von der Sandbox auf Deno Deploy möglich
    • Ohne separaten CI-Build oder Authentifizierungsprozess kann die Entwicklungsumgebung sofort in eine serverlose Produktion überführt werden
    • Im Beispielcode wird my-app mit der Option production: true bereitgestellt und anschließend die URL ausgegeben
  • So ist eine automatisch skalierbare serverlose Bereitstellung mit einem einzigen Aufruf möglich

Persistence

  • Standardmäßig ist die Sandbox flüchtig (ephemeral), für zustandsbehaftete Nutzung werden jedoch folgende Funktionen angeboten
    • Volumes: Lese-/Schreib-Storage für Cache, Datenbanken und Nutzerdaten
    • Snapshots: Schreibgeschützte Images einschließlich Toolchains oder Basis-Volumes
  • Wird nach apt-get install ein Snapshot erstellt, können danach alle Sandboxes sofort mit einer vorinstallierten Umgebung booten
  • Mit Snapshot-basierten Volumes lässt sich in wenigen Sekunden eine neue Entwicklungsumgebung erstellen
Anzeige

Technical Details

  • Regionen: Amsterdam, Chicago
  • vCPU: 2
  • Arbeitsspeicher: 768MB ~ 4GB
  • Lebensdauer: vorübergehend (ephemeral) oder timeout-basiert, bei Bedarf verlängerbar
  • Maximale Lebensdauer: 30 Minuten
  • Boot-Zeit: unter 1 Sekunde
  • Geeignete Einsatzfälle: Code-Ausführung für AI-Agenten, sichere Plugin-Systeme, temporäre CI-Runner, Ausführungsumgebungen für von Nutzern bereitgestellten Code

Pricing

  • Im Deno-Deploy-Tarif enthalten mit nutzungsbasierter Abrechnung
    • CPU-Zeit: $0.05/h (40 Stunden im Pro-Tarif enthalten)
    • Arbeitsspeicher: $0.016/GB-h (1000 GB-h im Pro-Tarif enthalten)
    • Volume-Storage: $0.20/GiB-month (5 GiB im Pro-Tarif enthalten)
  • Für den Enterprise-Tarif ist eine separate Anfrage möglich

Get Started

1 Kommentare

 
GN⁺ 2026-02-04
Hacker-News-Kommentare
  • Interessant ist, dass man weder Deno noch JavaScript überhaupt verwenden muss
    Über das Python-SDK deno-sandbox lassen sich Sandboxes erstellen sowie Befehle ausführen und Dateien lesen bzw. schreiben
    Es wurde bestätigt, dass das API-Protokoll auf WebSocket basiert

    • Dass die Sandbox nicht lokal, sondern in der Cloud läuft, war anfangs nicht klar
  • Beeindruckend ist, wie Deno Sandbox mit Secrets umgeht
    Im Code selbst sind statt echter Schlüssel nur Platzhalter sichtbar, und der echte Schlüssel wird nur bei Anfragen an freigegebene Hosts eingefügt
    Selbst wenn bösartiger Code versucht, diesen Platzhalter nach außen zu exfiltrieren, ist er nutzlos

    • Wenn der Proxy jedoch nur einfache String-Ersetzung macht, stellt sich die Frage, ob ein Angreifer nicht einen der freigegebenen Hosts dazu bringen könnte, den Schlüssel zurückzuechoen
      Falls der Proxy auch in der Antwortrichtung den Schlüssel wieder ersetzt, wäre das schwieriger, aber wohl immer noch keine perfekte Verteidigung
      Eine proxybasierte Secret-Injektion mit Kontextverständnis könnte sicherer sein
    • Das erinnert an Flys Tokenizer
      Dabei verarbeitet die Anwendung die Schlüssel nicht direkt, sondern der Proxy fügt den API-Key stattdessen hinzu und reduziert so das Risiko von Security-Exposure
    • Auch im offiziellen Blog von Deno wird diese Idee vorgestellt
      Secrets that can’t be stolen
      Bösartiger Code kann Secrets zwar nicht dauerhaft stehlen, aber weiterhin missbräuchliche Requests mit diesem Schlüssel senden
      Das ist ähnlich wie bei XSS: httpOnly-Cookies lassen sich nicht lesen, aber Requests mit ihnen können trotzdem gesendet werden
    • Wahrscheinlich handelt es sich um einen MITM-Proxy, der HTTPS-Anfragen abfängt
      In diesem Fall könnten Funktionen wie Certificate Pinning schwierig werden
    • Ich frage mich, wie Fälle behandelt werden, in denen Header-Ersetzung nicht möglich ist, etwa bei TCP-basierten DB-Verbindungen
      Ich würde auch gern fragen, ob vielleicht etwas wie Vault ergänzt wird
  • Laut dem Deno-Team nehmen zuletzt plattformartige Services zu, die von LLMs erzeugten Code direkt ausführen
    Damit solcher Code externe APIs aufrufen kann, braucht er echte Zugangsdaten und Netzwerkzugriff
    Reines Sandboxing reicht nicht aus; Netzwerkkontrolle und Secret-Schutz werden gemeinsam benötigt
    Deno Sandbox bietet beides, und sobald der Code bereit ist, kann er direkt nach Deno Deploy ausgerollt werden

    • Jedes Mal, wenn ich den Satz „Das ist keine einfache Plugin-Sandbox, sondern eine AI-Code-Execution-Plattform“ lese, denke ich instinktiv: „Das ist AI
  • Unser Team hat ebenfalls eine ähnliche Sandbox-Umgebung selbst mit Firecracker + Go aufgebaut
    Wegen Anforderungen an die Datensouveränität müssen wir nur innerhalb der EU bereitstellen, daher kann es überall deployt werden, wo Hardware-Virtualisierung möglich ist
    Damit das LLM nicht direkt mit Zugangsdaten arbeitet, erzeugen wir spontan eine CLI mit begrenztem Scope und stellen sie bereit
    Das LLM ruft sie einfach wie einen Bash-Befehl auf
    Da aktuelle Modelle als Coding Assistants trainiert sind, ist dieser Ansatz deutlich natürlicher und effizienter

  • Der Secret-Ersetzungsansatz ist interessant, aber ich frage mich, ob er in der Praxis bei nötigen Schlüsseltransformationen wie OAuth 1, JWT, HMAC nicht kaputtgeht
    Wenn der Schlüssel außerdem Teil des Payloads ist, könnten durch die Ersetzung auch HTTP-Probleme wie ein Content-Length-Mismatch entstehen
    Außerdem hilft so ein Ansatz nicht gegen andere Angriffe wie SQL-Injection
    Letztlich wirkt das eher wie eine teilweise Abschwächung als wie eine vollständige Schutzmaßnahme

  • Es gibt einen kostenlosen Tarif, deshalb hätte ich wie bei Glitch Lust, damit zu experimentieren, aber ich bin vorsichtig, weil solche kostenlosen Services meiner Erfahrung nach oft irgendwann eingestellt werden

  • Das Design mit Secret-Platzhaltern wirkt wie eine gute Entscheidung
    Allerdings gibt es inzwischen einfach zu viele Sandbox-Produkte — Modal, Daytona, Fly, Cloudflare, Deno usw.
    Ich frage mich, was Leute tatsächlich in Produktion verwenden

    • Tatsächlich sind die meisten dieser Services im Grunde nur VM-Wrapper, sodass man so etwas auch direkt mit EC2 oder dem GCP-SDK bauen könnte
    • Factory, Nvidia, Perplexity, Manus und andere nutzen E2B in Produktion; angeblich wurden damit bisher mehr als 200 Millionen Sandboxes ausgeführt
  • Es heißt, dass die von Deno Sandbox bereitgestellten leichtgewichtigen Linux-microVMs in der Deno-Deploy-Cloud laufen,
    und die zentrale Frage ist, ob das auch in einer selbst gehosteten Linux-Umgebung laufen kann

    • Allerdings setzen die meisten Anbieter auf eine Lock-in-Strategie
      Wenn sie alles vollständig Open Source freigeben würden, könnten AWS oder GCP es einfach kopieren
      Es fühlt sich am Ende so an, als würde man eine Burg in der Sandbox anderer bauen, aber realistisch betrachtet ist das wohl das einzige tragfähige Geschäftsmodell
  • Wenn man Claude Pro oder den Max-Plan in so einer Umgebung nutzt, mache ich mir Sorgen, dass durch die ständig wechselnden IPs Anthropic das als Mehrfachnutzung missverstehen und den Zugriff sperren könnte
    Ich frage mich auch, warum Sessions auf 30 Minuten begrenzt sind

    • Angeblich ist eine Verlängerung der Session-Laufzeit bereits geplant. Dafür seien interne technische Anpassungen nötig, weshalb es etwas dauere
    • Ich selbst nutze es auf diese Weise über ungefähr 50 IPs hinweg, und bisher gab es keine Probleme
      Anthropic scheint einfach Heuristiken dafür zu verwenden, ob gerade ein Mensch direkt damit arbeitet
    • Ich frage mich, ob der Zweck dieser Nutzung darin besteht, über ein Monatsabo direkten API-Zugriff zu versuchen, oder ob etwas anderes dahintersteckt