Modal startet Sidecars, um vertrauenswürdigen und nicht vertrauenswürdigen Code in Sandboxes zu trennen

Das Problem: vertrauenswürdiger Code in Sandboxes

Nach Angaben von Modal nutzen Kunden Sandboxes, um nicht vertrauenswürdigen Code auszuführen, den ihre nachgelagerten Nutzer oder inzwischen fast ausschließlich Agenten geschrieben haben. Isolationstechnologien wie gVisor und Firecracker hätten das klassische Problem, eine Plattform von ihren Nutzern abzuschirmen, vor fast acht Jahren gelöst, so das Unternehmen. Die schwierigere Frage sei heute, wie sich Nutzer vor ihrem eigenen Code schützen lassen.

Als Ursache nennt das Unternehmen eine Designgewohnheit. Frühe Coding-Agenten wie Claude Code seien dafür gebaut worden, auf dem Laptop des Nutzers zu laufen, sodass das Harness nie von seinen Tool-Aufrufen getrennt wurde. Dieses Muster sei auf entfernte Sandboxes übertragen worden. Läuft ein Harness innerhalb seiner Sandbox, liegen Zugangsdaten neben generiertem Code, der Agent kann nicht vertrauenswürdige Inhalte wie Pakete und Repos lesen, und alles in der Sandbox kann Netzwerkaufrufe absetzen.

Modal bringt das mit dem in Verbindung, was Simon Willison die „lethal trifecta“ nennt: Ein Agent mit Zugriff auf private Daten, Kontakt mit nicht vertrauenswürdigen Inhalten und der Fähigkeit zur externen Kommunikation lässt sich dazu verleiten, diese Daten preiszugeben.

Warum bisherige Lösungen nicht reichen

Modal beschreibt zwei gängige Gegenmittel, die jeweils einen Schenkel der Trifecta entfernen. Das erste verlagert das Harness aus der Sandbox und trennt so das „Gehirn“ des Agenten von seinen „Händen“, ein Muster, das laut Modal Anthropic und OpenAI propagieren. Der Preis: Jede Agentenoperation erfordert dann einen Netzwerkaufruf, und bei Agenten mit vielen Tool-Aufrufen summieren sich diese kleinen Verzögerungen. Außerdem sei bei einem Coding-Agenten die Codebasis selbst ein privates Datum, sodass das Risiko des Datenabflusses bestehen bleibe.

Das zweite Mittel sind Kontrollen für ausgehenden Netzwerkverkehr wie Domain-Allowlists, Credential-Injection und dynamische Aktualisierungen der Egress-Richtlinien. Modal zufolge sind sie für die meisten Kunden wirksam, aber nicht für alle flexibel genug. Als Beispiel nennt das Unternehmen Ramp, das neben seinem Agenten einen komplexen Dienst betreiben wollte, der Secrets injiziert und zugleich externe Aufrufe überwacht. Standardlösungen zur Secret-Injection deckten diesen Fall nicht vollständig ab.

Modal nennt drei Anforderungen an eine vollständige Lösung: nicht vertrauenswürdigen und vertrauenswürdigen Code strikt trennen, die Latenz für operationsintensive Agenten minimieren und flexibel genug bleiben für Programme, die noch niemand absehen kann.

So funktionieren Sidecars

Ein Sidecar läuft neben einer Sandbox und bleibt zugleich von ihr isoliert. Vertrauenswürdige Software kann darüber Zugangsdaten injizieren, Datenverkehr weiterleiten, Daten schwärzen, Harness-Logik ausführen oder den Agenten beobachten. Das Design ist von Kubernetes-Sidecar-Containern und dem Datadog Agent inspiriert.

• Isolation: Sidecars nutzen dieselbe Grenze wie separate Sandboxes, also gVisor oder VMs, je nach der an Sandbox.create() übergebenen Runtime.
• Latenz: Container auf demselben Host kommunizieren über ein internes Bridge-Netzwerk per TCP/UDP, und jeder ist über seinen Namen erreichbar. Modals interne Benchmarks zeigen einen p50-Wert von 0,58 ms pro Aufruf für ein Sidecar gegenüber 2,6 ms für eine separate Sandbox über HTTPS. Bei p99 liegen die Werte bei 1,4 ms und 44 ms. Bei 100 Aufrufen beträgt die Gesamtzeit 0,6 s gegenüber 1,2 s.
• Erstellung: Sidecars werden dynamisch über das Modal SDK erzeugt. Code innerhalb der Sandbox kann sie weder erstellen noch ändern.
• Ressourcen: Sandboxes und Sidecars teilen sich CPU und Arbeitsspeicher, was laut Modal kosteneffizienter ist, als Prozesse auf mehrere Sandboxes zu verteilen. Eine Sandbox kann bis zu 250 Sidecars betreiben.
• Netzwerkrichtlinie: Jeder Sidecar hat eine eigene Richtlinie für ausgehenden Verkehr, und der ausgehende Verkehr der Sandbox lässt sich zwingend über einen Proxy-Sidecar leiten.
• Lebenszyklus: Sidecars lassen sich jederzeit beenden und ersetzen, und ihr Dateisystem kann per Snapshot gesichert werden, um eine weitere Sandbox oder einen weiteren Sidecar zu starten. Wird die Sandbox beendet, stoppen auch alle ihre Sidecars.

Ramps individueller Egress-Proxy

Ramps Hintergrund-Coding-Agent Inspect schreibt laut Modal über 75 Prozent aller gemergten Pull Requests bei Ramp, wobei jede Sitzung in einer eigenen Modal Sandbox läuft. Ramp hat auf Basis von Sidecars einen individuellen Egress-Proxy gebaut, der neben jeder Inspect-Sandbox läuft und den ausgehenden Datenverkehr überwacht und steuert.

Zach Bruggeman, Principal Software Engineer bei Ramp, sagte: „Wir können ausgehenden Verkehr zwingend über den Proxy leiten, sodass nichts daran vorbeikommt, und weil er auf demselben Host läuft, kostet uns das keinen zusätzlichen Netzwerk-Hop.“

Verfügbarkeit und Einordnung

Sidecars sind als Beta verfügbar, Details zur Einrichtung und bekannte Einschränkungen stehen in der Modal-Dokumentation. Das Unternehmen hat Beispiele veröffentlicht, wie sich ein Agent-Harness von der Codeausführung trennen lässt, wie eine App und ihre unterstützenden Dienste in getrennten Containern laufen und wie sich HTTPS-Verkehr einer Sandbox mit einem Proxy-Sidecar filtern lässt.

Für Teams, die Agenten in Sandboxes betreiben, lautet das Versprechen: Sicherheitskontrollen müssen nicht mehr bei jeder Operation einen Remote-Aufruf bedeuten, und Teams können eigene vertrauenswürdige Dienste bauen, statt auf Funktionen des Anbieters zu warten. Die Latenzwerte stammen aus Modals eigenen Benchmarks.