Wie sicher ist die KI-Sandbox für die Code-Ausführung?

Eine KI-Sandbox zur Code-Ausführung ist nur so sicher wie ihre Isolationsgrenze – und die Isolationsgrenze ist nur ein Teil der Antwort. Die bessere Frage lautet: Was isoliert die Sandbox tatsächlich und was kann trotzdem entkommen? Die meisten Sandboxen stoppen einige Dinge gut (Code-Ausführung auf Prozessebene, beliebige Dateisystem-Schreibvorgänge auf dem Host) und lassen andere Dinge standardmäßig offen (ausgehenden Netzwerkverkehr, Paketinstallationen, Geheimnisse in Umgebungsvariablen). Das Verständnis dieser Lücken ist der Schlüssel zur Bewertung, ob eine Sandbox zu Ihrem Risikomodell passt. Für Hintergrundinformationen dazu, was eine KI-Agent-Sandbox ist und wie die Kernkonzepte – Isolation, Ausgangsverkehr, Snapshotting, MicroVMs – zusammenhängen, lesen Sie bitte den Definitionsleitfaden, bevor Sie sich mit den spezifischen Sicherheitsaspekten befassen.

Was „sicher“ für eine Code-Ausführungssandbox bedeutet

Sicherheit in einer Code-Ausführungssandbox ist keine binäre Eigenschaft. Es ist eine Reihe von Kontrollen, die jeweils eine bestimmte Risikokategorie adressieren. Wenn jemand fragt: „Ist diese Sandbox sicher?“, stellt er in der Regel mehrere verschiedene Fragen gleichzeitig:

• Host-Isolation: Kann der in der Sandbox ausgeführte Code zum Host-System entkommen?
• Tenant-Isolation: Kann der Code eines Benutzers die Sitzung eines anderen Benutzers beeinflussen?
• Ausgangskontrolle: Kann der Code in der Sandbox das Internet, interne Dienste oder Metadaten-Endpoints erreichen?
• Geheimnis-Scoping: Sind Zugangsdaten für einen größeren Teil der Sandbox zugänglich als nötig?
• Supply-Chain-Risiko: Können Paketinstallationen unerwarteten oder bösartigen Code einschleusen?
• Prüfbarkeit: Können Sie rekonstruieren, was der Agent tatsächlich getan hat, nachdem es passiert ist?

Eine Sandbox kann bei der Host-Isolation stark und beim Ausgangsverkehr schwach sein. Stark beim Ausgangsverkehr und schwach bei Geheimnissen. Die Bewertung von „wie sicher“ erfordert die Überprüfung jeder Dimension separat, nicht die Akzeptanz einer einzelnen Bezeichnung wie „containerisiert“ oder „microVM-basiert“ als vollständige Antwort.

Vergleich der Isolationsschichten

Es gibt drei Hauptisolationsmodelle, die in KI-Code-Ausführungssandboxen verwendet werden. Jedes bietet eine andere Grenze.

Prozessisolation

Prozessisolation verwendet Betriebssystem-Primitive – Linux-Namespaces, Cgroups, Seccomp-Filter und AppArmor- oder SELinux-Profile – um den Zugriff eines Prozesses einzuschränken. Die Sandbox läuft als Prozess auf dem Host-Betriebssystem und teilt sich den Host-Kernel.

Was es verhindert: Zugriff auf das breitere Dateisystem, andere Prozesse außerhalb der Sandbox und Syscalls, die explizit durch die Seccomp-Richtlinie blockiert werden.

Was es nicht verhindert: Kernel-Exploits, die durch eine gemeinsam genutzte Schwachstelle Rechte eskalieren. Ein Seccomp-Bypass oder eine Kernel-Schwachstelle kann die Host-Grenze überbrücken.

Wann es angemessen ist: Kurzlebiger, risikoärmer, einigermaßen vertrauenswürdiger Code, bei dem Startgeschwindigkeit und Portabilität mehr zählen als eine harte VM-Grenze. Nicht empfohlen für die Ausführung von beliebigem agent-generiertem Code von externen Benutzern.

Container-Isolation (Docker/Namespaces)

Container-Isolation erweitert die Prozessisolation um ein strukturierteres Image-Modell, Netzwerk-Namespaces und Volume-Mounts. Die meisten Docker-basierten Sandbox-Implementierungen führen Code in einem Container mit einem minimalen Image und einem eingeschränkten Seccomp-Profil aus.

Was es verhindert: Direkten Dateisystemzugriff auf den Host, die meisten Netzwerkzugriffe auf benachbarte Container (bei korrekter Konfiguration), einfachen Zugriff auf Host-Prozesse.

Was es nicht verhindert: Kernel-Level-Exploits gelten weiterhin – Container teilen sich den Host-Kernel. Falsch konfigurierte Volume-Mounts, zu weit gefasste Seccomp-Profile, der --privileged-Modus und exponierte Docker-Sockets können die beabsichtigte Grenze aufheben.

Wann es angemessen ist: Viele Produktionsumgebungen setzen Container effektiv für die KI-Code-Ausführung ein, wenn das Seccomp-Profil eng ist, das Image minimal ist, der Ausgangsverkehr eingeschränkt ist und kein privilegierter Zugriff gewährt wird. Das Risikomodell unterscheidet sich von MicroVMs, ist aber bei sorgfältiger Konfiguration handhabbar.

MicroVM-Isolation (Firecracker/gVisor)

MicroVM-Isolation führt jede Sandbox in einer leichtgewichtigen virtuellen Maschine mit einem eigenen Gast-Kernel aus, der durch eine KVM-Hypervisor-Grenze vom Host isoliert ist. Firecracker ist die häufigste Implementierung; gVisor (mit seinem User-Space-Kernel) bietet einen anderen Kompromiss.

Was es verhindert: Gast-Kernel-Exploits breiten sich nicht auf den Host-Kernel oder andere Gäste aus. Die Angriffsfläche des Hosts wird auf den VMM (Virtual Machine Monitor) reduziert, der so minimalistisch wie möglich gestaltet ist.

Was es nicht verhindert: Schwachstellen im VMM selbst (selten, aber nicht unmöglich). Netzwerk-, Paket- und Geheimnis-Kontrollen liegen weiterhin außerhalb der VM-Grenze – die MicroVM-Isolation kümmert sich nicht darum.

Wann es angemessen ist: Ausführung von nicht vertrauenswürdigem oder agent-generiertem Code von externen Benutzern, Multi-Tenant-Umgebungen, in denen der Explosionsradius wichtig ist, und Workloads, die beliebige Shell-Befehle oder Paketinstallationsskripte ausführen können.

Isolationsmodell	Host-Kernel geteilt	Tenant-Trennung	Startaufwand	Host-Escape-Risiko
Prozess	Ja	Schwach	Niedrigster	Höchstes
Container	Ja	Mittel	Niedrig	Mittel (konfigurationsabhängig)
MicroVM	Nein	Stark	Mittel	Niedrig

Was jeder Grenze trotzdem entkommen kann

Das Isolationsmodell adressiert die Laufzeit-Code-Ausführung. Es adressiert nicht automatisch, was über andere Pfade in die Sandbox gelangt oder sie verlässt.

Ausgehender Netzwerkverkehr: Alle drei Isolationsmodelle überlassen den ausgehenden Netzwerkzugriff der Richtlinienkonfiguration. Standardmäßig offener Ausgangsverkehr bedeutet, dass Code in der Sandbox das öffentliche Internet, Cloud-Metadaten-Endpoints (169.254.169.254 auf AWS und GCP), interne Dienste im selben Netzwerk und beliebige externe APIs erreichen kann. Dies ist ein Pfad zur Datenexfiltration, ein Pfad zum Abrufen von Geheimnissen und ein Command-and-Control-Pfad, unabhängig vom Isolationsmodell.

Paketinstallationen: Ein apt install, pip install oder npm install ruft Code aus einem externen Registry ab und führt ihn aus. Wenn die Sandbox Paketinstallationen erlaubt und offenen Ausgangsverkehr hat, kann ein Paketnamen-Kollision, eine Typosquatting-Attacke oder eine Dependency-Confusion-Attacke bösartigen Code einschleusen, der mit allen Berechtigungen der Sandbox läuft. Die Isolationsgrenze enthält den Explosionsradius, verhindert aber nicht die Installation.

Gemeinsamer Zustand: In Multi-Tenant-Umgebungen schaffen gemeinsam genutzte Caches, gemeinsam genutzte Paketregistries, gemeinsam genutzte Vorlagen-Images oder gemeinsam genutzte Dateisystem-Mounts Kanäle zwischen Tenants, die die Isolationsgrenze umgehen.

Geheimnisse in Umgebungsvariablen: Umgebungsvariablen, die für den Agent-Prozess sichtbar sind, sind für jeden Code lesbar, den der Agent ausführt. Wenn sich eine Datenbank-Anmeldedaten oder ein API-Schlüssel in der Umgebung befindet, ist er für die Sandbox und alles, was sie ausführt oder installiert, zugänglich.

Ausgangs- und Netzwerk-Kontrollen

Der Ausgangsverkehr ist die Stelle, an den die meisten Sandboxen die größte Lücke aufweisen. Offener ausgehender Internetzugang ist üblich, weil er bequem ist – Agenten müssen Pakete installieren, APIs aufrufen und Ressourcen abrufen. Aber er schafft auch Risiken:

Cloud-Metadaten-Endpoints: Auf gehosteter Cloud-Infrastruktur liefert 169.254.169.254 (und sein IPv6-Äquivalent) Instanz-Metadaten einschließlich IAM-Anmeldedaten. Code in einer Sandbox mit offenem Ausgangsverkehr kann diesen Endpoint erreichen und Anmeldedaten für den zugrunde liegenden Host abrufen.

DNS-basierte Exfiltration: Selbst wenn HTTP blockiert ist, können ausgehende DNS-Abfragen verwendet werden, um Daten zu exfiltrieren, indem sie in Domain-Lookups codiert werden. DNS-Blockierung erfordert Filterung auf Ebene des Resolvers, nicht nur das Blockieren von TCP/UDP 53 an externe Server.

Interne Dienste: Wenn die Sandbox in einem privaten Netzwerksegment läuft, kann offener Ausgangsverkehr den Zugriff auf interne Datenbanken, Admin-Panels und APIs ermöglichen, die nicht für Agent-Code erreichbar sein sollen.

Zu überprüfende Kontrollen:

Kontrolle	Was sie verhindert	Was zu überprüfen ist
Standardmäßig verweigerter Ausgangsverkehr	Ausgehende Verbindungen zu nicht gelisteten Zielen	Blockiert es auch DNS sowie TCP/UDP?
Ausgangsverkehr auf Whitelist-Basis	Verbindungen zu nicht genehmigten Domains	Ist die Whitelist kundenkonfigurierbar?
Blockierung von Metadaten-Endpoints	Cloud-Anmeldedaten-Abruf über 169.254.169.254	Wird IPv6-Metadaten ebenfalls blockiert?
Ausgangs-Proxy	Protokollierung und Inspektion des gesamten ausgehenden Datenverkehrs	Ist das Proxy-Protokoll zugänglich?
DNS-Filterung	DNS-basierte Exfiltration und interne Namensauflösung	Welcher Resolver wird innerhalb der Sandbox verwendet?

Es gibt keine universell korrekte Ausgangsrichtlinie. Einige Agent-Workloads benötigen tatsächlich breiten Internetzugang, um nützlich zu sein. Entscheidend ist, dass die Richtlinie bewusst und prüfbar ist, nicht standardmäßig offen, weil sie nie konfiguriert wurde.

Umgang mit Geheimnissen

Geheimnisse in KI-Agent-Sandboxen folgen den gleichen Prinzipien wie Geheimnisse in jedem Softwaresystem, mit einer zusätzlichen Einschränkung: Der Agent kann Code ausführen, der die Umgebung ohne Entwicklerabsicht liest, protokolliert oder überträgt.

Scoping: Montieren Sie nur die Anmeldedaten, die die Sandbox für die aktuelle Aufgabe tatsächlich benötigt. Eine Sandbox, die eine Codierungsaufgabe ausführt, benötigt keine Produktionsdatenbank-Anmeldedaten. Eine Sandbox, die Modellausgaben bewertet, benötigt den API-Schlüssel für einen Abrechnungsdienst nicht.

Lebensdauer: Kurzlebige Anmeldedaten sind erheblich sicherer als langlebige. Wenn eine Anmeldedaten innerhalb einer Sandbox durchsickern, begrenzt eine kurze TTL das Expositionsfenster. Viele Cloud-IAM-Systeme unterstützen kurzlebige Token, die in Minuten oder Stunden ablaufen.

Injektionsmethode: Umgebungsvariablen sind die häufigste Injektionsmethode und für jeden Code im Prozess am zugänglichsten. Geheimnisse, die über Dateisystem-Mounts injiziert werden können, an einem Pfad gemountet werden, den der Agent nicht durchlaufen muss, oder nur dynamisch abgerufen werden, wenn das spezifische Tool, das sie benötigt, ausgeführt wird, sind stärker eingeschränkt als eine pauschale Umgebungsvariableneinstellung.

Redaktion: Geheimnisse sollten aus stdout, stderr, Tool-Antwort-Payloads, modellsichtbarem Kontext und Prüfprotokollen entfernt werden. Ein Agent, der seine Umgebung ausgibt, env aufruft oder ein Token an einen fehlgeschlagenen API-Aufruf übergibt, kann Anmeldedaten in Protokolle durchsickern lassen, die dann gespeichert oder für Betreiber sichtbar sind.

Ressourcenlimits und Denial-of-Service-Risiko

Eine Sandbox ohne Ressourcenlimits ist anfällig für Agent-Workloads, die CPU, Arbeitsspeicher, Festplatte oder Netzwerkbandbreite erschöpfen – sei es durch außer Kontrolle geratenen Code, eine Endlosschleife, ein Speicherleck in einem installierten Paket oder einen absichtlichen Versuch, benachbarte Workloads zu stören.

Zu überprüfende Ressourcenkontrollen:

• CPU-Limits: Drosselung oder harte Limits pro Sitzung verhindern, dass eine Sitzung die Host-Kapazität monopolisiert.
• Speicherlimits: OOM-Kill-Richtlinien sollten die Sandbox-Sitzung beenden, nicht den Host-Prozess.
• Festplattenkontingente: Schreiblimits pro Sitzung verhindern, dass eine Sitzung den gemeinsam genutzten Speicher füllt.
• Ausführungs-Timeout: Sitzungen, die ein Wandzeitlimit überschreiten, sollten sauber beendet werden, nicht weiterlaufen.
• Netzwerkratenbegrenzungen: Ausgehende Bandbreitenlimits können die Exfiltration einschränken, selbst wenn die Ausgangsrichtlinie das Ziel erlaubt.
• Gleichzeitige Prozesslimits: Agenten, die aggressiv forken oder Hintergrundprozesse starten, können die Prozesstabellen-Slots erschöpfen.

Verstöße gegen Ressourcenlimits sollten ebenfalls protokolliert werden. Eine Sitzung, die während leichter Aufgaben konsequent CPU-Drosselung oder OOM-Kill erreicht, ist ein Signal, das untersucht werden sollte.

Prüfbarkeit

Isolationskontrollen reduzieren den Explosionsradius, wenn etwas schiefgeht. Prüfprotokolle sind der Weg, um herauszufinden, dass etwas schiefgegangen ist, und zu rekonstruieren, was passiert ist.

Speziell für KI-Agent-Sandboxen umfasst eine nützliche Prüfabdeckung:

• Prozessausführung: Jeder ausgeführte Befehl mit vollständiger Argumentliste, UID und Elternprozess. Ohne Argumentlisten sind curl und python in einem Protokoll nicht aussagekräftig.
• Dateisystemzugriff: Lese- und Schreibzugriffe auf sensible Pfade. Schreib- und Löschvorgänge haben für die meisten Bedrohungsmodelle eine höhere Priorität als Lesevorgänge.
• Ausgehender Netzwerkverkehr: Ziele, Protokolle, DNS-Abfragen und übertragene Bytes. Die Protokollierung von DNS-Abfragen fehlt oft, ist aber wichtig.
• Paketinstallationen: Paketmanager, Paketname, Version, Quell-Registry und Hash.
• Sitzungslebenszyklus: Erstellen, Pausieren, Fortsetzen, Beenden und Bereinigen von Ereignissen mit Grundcodes.
• Ressourcenlimit-Ereignisse: OOM-Kills, CPU-Drosselung, Timeout-Beendigungen.

Der Erfassungsmechanismus ist genauso wichtig wie die Abdeckung. Protokolle, die innerhalb des Sandbox-Prozesses erstellt werden, können von einem ausreichend privilegierten Agenten unterdrückt oder geändert werden. Die Erfassung auf Kernel-Ebene (über auditd, eBPF oder Hypervisor-Instrumentierung) erfolgt unterhalb der Anwendungsschicht, auf die der Agent keinen Schreibzugriff hat.

Fragen, die Sie jedem Sandbox-Anbieter oder -Projekt stellen sollten

Verwenden Sie diese Checkliste, wenn Sie einen verwalteten Sandbox-Dienst oder ein Open-Source-Sandbox-Framework bewerten. Für einen detaillierten Vergleich, wie große Anbieter diese Fragen beantworten, lesen Sie Die besten KI-Agent-Sandboxen im Jahr 2026 oder den E2B- und Daytona-Bewertungsleitfaden.

Isolation

• Erhält jede Agent-Sitzung ihre eigene isolierte Umgebung, oder werden Sitzungen auf gemeinsam genutzten Ausführungsumgebungen gruppiert?
• Welches Isolationsmodell wird verwendet: Prozess, Container oder MicroVM?
• Wird der Gast-Kernel mit dem Host geteilt?

Netzwerk und Ausgangsverkehr

• Ist der Ausgangsverkehr standardmäßig offen oder standardmäßig verweigert?
• Kann die Ausgangsrichtlinie pro Tenant oder pro Sitzung konfiguriert werden?
• Wird der Cloud-Metadaten-Endpoint (169.254.169.254) blockiert?
• Wie wird DNS innerhalb der Sandbox behandelt?

Paketinstallationen

• Sind Paketinstallationen standardmäßig erlaubt?
• Können Installationen auf genehmigte Registries beschränkt werden?
• Werden Installationsereignisse mit Quelle und Hash protokolliert?

Geheimnisse

• Wie werden Anmeldedaten in die Sandbox injiziert?
• Können Anmeldedaten auf das spezifische Tool oder die Aufgabe beschränkt werden, die sie benötigt?
• Werden Geheimnisse aus Protokollen und modellsichtbaren Ausgaben entfernt?

Ressourcenlimits

• Werden CPU-, Speicher-, Festplatten- und Timeout-Limits durchgesetzt?
• Was passiert, wenn ein Limit erreicht wird – Drosselung, Beendigung oder Alarmierung?

Prüfprotokolle

• Werden Protokolle auf Kernel-/Hypervisor-Ebene oder innerhalb des Sandbox-Prozesses erstellt?
• Welche Ereigniskategorien werden standardmäßig protokolliert?
• Können Protokolle in ein externes SIEM oder Protokollaggregationssystem exportiert werden?
• Wie lautet die Protokollaufbewahrungsrichtlinie?

Tenancy

• Sind Workloads verschiedener Tenants voneinander isoliert?
• Gibt es gemeinsam genutzte Caches, Images oder Mounts, die Cross-Tenant-Kanäle schaffen?

Wo die Novita Agent Sandbox passt

Die Novita Agent Sandbox wurde für Agent-Workloads entwickelt, die isolierte Ausführungsumgebungen für Code, Dateien, Prozesse und länger laufende Sitzungen benötigen. Sie richtet sich an Teams, die Codierungsagenten, Evaluierungspipelines, Datenanalyseagenten und browserbasierte Agent-Workflows erstellen.

Die Sandbox unterstützt Sitzungslebenszyklus-Kontrollen einschließlich Pause, Fortsetzung und automatischer Pause für Leerlaufsitzungen. Sie bietet Ressourcenmetriken und sitzungsbezogene Ausführungsprotokolle, die über die API zugänglich sind. Für Teams, die bereits Novita-Modell-APIs verwenden, kann sie als Ausführungsschicht in einer Agent-Architektur dienen, in der das Modell plant und Tools aufruft, während die Sandbox die Laufzeitausführung in einer isolierten Umgebung übernimmt.

Wenn Sie die Novita Agent Sandbox für sicherheitskritische Anwendungsfälle bewerten, überprüfen Sie das aktuelle Isolationsmodell, die Ausgangsrichtlinien-Standards, die Protokollabdeckung und den Umgang mit Geheimnissen in der Produktdokumentation, bevor Sie Architekturentscheidungen treffen. Die Sicherheitsanforderungen variieren erheblich je nach Workload – was für eine interne Evaluierungspipeline angemessen ist, reicht möglicherweise nicht für ein Multi-Tenant-Produkt aus, das benutzergestellten Code verarbeitet.

Wie bei jeder Sandbox hängt die Sicherheitslage sowohl von den Standardeinstellungen der Plattform als auch von Ihren anwendungsspezifischen Kontrollen ab: wie Anmeldedaten eingegrenzt werden, was der Agent anfordern darf, welche Tool-Aufrufe eine menschliche Genehmigung erfordern und wie Prüfprotokolle überwacht werden.

Einschränkungen und was keine Sandbox beseitigt

Keine Sandbox beseitigt jedes Risiko. Zu verstehen, was außerhalb der Grenze bleibt, ist genauso wichtig wie zu verstehen, was die Grenze bietet.

Vertrauensentscheidungen auf Anwendungsebene: Die Sandbox steuert die Laufzeitausführung. Sie entscheidet nicht, was der Agent anfordern darf. Wenn Ihre Anwendung es einem Agenten erlaubt, eine Anmeldedaten anzufordern, beliebige Shell-Befehle auszuführen oder jede API aufzurufen, reduziert die Sandbox den Explosionsradius, verhindert diese Aktionen jedoch nicht.

Prompt Injection: Ein Agent, der nicht vertrauenswürdige Inhalte verarbeitet – Webseiten, benutzerhochgeladene Dateien, externe API-Antworten – kann durch diese Inhalte manipuliert werden, um Aktionen auszuführen, die er nicht ausführen sollte. Dies ist ein Anwendungsdesignproblem, kein Sandbox-Problem. Die Sandbox kann begrenzen, wo diese Aktionen landen, aber die Entscheidungslogik liegt in Ihrer Anwendung.

Zero-Day-Schwachstellen: Alle Isolationsmodelle haben bekannte und unbekannte Schwachstellen. Die MicroVM-Isolation bietet die stärkste Grenze im aktuellen Produktionseinsatz, aber VMM-Schwachstellen existieren. Defense-in-Depth – die Kombination mehrerer Kontrollen anstatt sich auf eine einzelne Grenze zu verlassen – ist eine robustere Haltung als jedes einzelne Isolationsmodell.

Social Engineering durch Modellausgabe: Ein Agent kann eine Ausgabe produzieren, die einen menschlichen Bediener dazu überredet, eine unsichere Aktion auszuführen. Sandboxen prüfen keine menschlichen Entscheidungen.

Compliance- und regulatorische Risiken: Isolationskontrollen adressieren technische Risiken. Regulatorische Anforderungen (DSGVO, HIPAA, SOC 2, ISO 27001) adressieren Datenhandhabung, Aufbewahrung, Dokumentation und Prüfanforderungen, die über das hinausgehen, was eine Sandbox auf Infrastrukturebene bietet.

Sicherheit in einer Code-Ausführungssandbox wird am besten als eine Reihe von Kontrollen betrachtet, die es zu bewerten und zu konfigurieren gilt, und nicht als eine Eigenschaft, die man durch die Wahl eines Produkts erwirbt. Die obigen Bewertungsfragen gelten für jede Sandbox-Entscheidung – einschließlich Ihrer eigenen Infrastruktur, wenn Sie selbst bauen statt kaufen.

FAQ

Wie sicher ist eine sandboxierte KI-Code-Ausführungsumgebung im Vergleich zur Ausführung von Code auf einem Server?

Eine gut konfigurierte Sandbox reduziert den Explosionsradius bei der Ausführung von nicht vertrauenswürdigem Code erheblich im Vergleich zur direkten Ausführung auf einem Server. Sie schränkt den Dateisystemzugriff, den Prozessbereich und den Netzwerkzugriff ein. Der Unterschied hängt jedoch von der Konfiguration ab. Ein Container mit offenem Ausgangsverkehr und breiter Injektion von Umgebungsvariablen kann weniger sicher sein als ein gehärteter Server mit Netzwerkkontrollen. Das Isolationsmodell ist ein Ausgangspunkt, keine Garantie.

Bedeutet MicroVM-Isolation, dass eine Sandbox vollständig sicher ist?

Nein. Die MicroVM-Isolation (Firecracker, KVM-basiert) bietet eine starke Host-Grenze, die Container mit gemeinsam genutztem Kernel nicht bieten. Sie steuert jedoch nicht den Ausgangsverkehr, Geheimnisse, Paketinstallationen oder die Prüfabdeckung. Eine MicroVM mit offenem Ausgangsverkehr und ohne Protokollierung ist nicht „vollständig sicher“, auch wenn die Isolationsschicht stark ist.

Kann KI-generierter Code einer Sandbox entkommen?

Das hängt vom Isolationsmodell und der Konfiguration ab. Container-Escapes erfordern die Ausnutzung des Kernels oder einer Fehlkonfiguration; MicroVM-Escapes erfordern die Ausnutzung des VMM. Beides ist möglich, aber ungewöhnlich. Die praktischeren Risiken sind die Datenexfiltration über erlaubte Netzwerkpfade, das Auslesen von Geheimnissen aus der Umgebung oder die Installation bösartiger Pakete durch uneingeschränkte Paketmanager.

Was ist das größte Sicherheitsrisiko in den meisten KI-Code-Sandboxen?

Offener ausgehender Netzwerkverkehr ist das am häufigsten unzureichend adressierte Risiko. Viele Sandboxen erlauben standardmäßig uneingeschränkten ausgehenden Internetzugang, da dies für Agenten praktisch ist, die Pakete installieren und APIs aufrufen müssen. Dies schafft Pfade für Datenexfiltration, Anmeldedatendiebstahl über Cloud-Metadaten-Endpoints und Command-and-Control-Kommunikation, die unabhängig davon bestehen, wie stark die Isolationsgrenze ist.

Sollte ich eine verwaltete Sandbox verwenden oder meine eigene bauen?

Verwaltete Sandboxen übernehmen die betriebliche Komplexität des MicroVM- oder Container-Lebenszyklus, der Host-Kapazität und der Image-Verwaltung. Der Eigenbau gibt Ihnen mehr Kontrolle über den gesamten Richtlinien-Stack. In beiden Fällen gelten die gleichen Bewertungsfragen: Ausgangsrichtlinie, Umgang mit Geheimnissen, Protokollabdeckung, Ressourcenlimits und Prüfexport. Die Build- vs. Buy-Entscheidung ist getrennt von der Sicherheitsbewertung.

Was unterscheidet die Sicherheit von Agent-Sandboxen von der herkömmlichen Code-Ausführungssicherheit?

Herkömmliche Code-Ausführungssicherheit geht davon aus, dass Sie ungefähr wissen, welcher Code ausgeführt wird. KI-Agenten ändern dies: Ein einzelner Prompt kann dazu führen, dass eine Sitzung Pakete installiert, Dateien schreibt, Shell-Befehle ausführt, externe APIs aufruft und Unterprozesse erzeugt, ohne dass der Entwickler jeden Schritt explizit genehmigen muss. Dies macht die Prüfabdeckung wichtiger (Sie können nicht jede Aktion vorhersehen), die Ausgangskontrollen wichtiger (der Agent kann Ziele erreichen, die Sie nicht erwartet haben) und das Geheimnis-Scoping wichtiger (der Agent hat Zugriff auf alles in seiner Umgebung).

Was sind die Best Practices für die Isolation von KI-Agenten in der Produktion?

Eine praktische Isolations-Checkliste für Produktions-Agenten-Bereitstellungen: Verwenden Sie MicroVM-Klasse-Isolation (Firecracker oder Äquivalent) anstelle von reinen Containern für nicht vertrauenswürdigen oder benutzergestellten Code; weisen Sie eine isolierte Umgebung pro Aufgabe oder pro Benutzersitzung zu – teilen Sie niemals eine Sandbox über nicht zusammenhängende Workloads hinweg; standardmäßig verweigerter Ausgangsverkehr mit einer expliziten Whitelist für erforderliche Ziele; injizieren Sie nur die Anmeldedaten, die die aktuelle Aufgabe erfordert, unter Verwendung kurzlebiger Token; sammeln Sie Prüfprotokolle auf Kernel- oder Hypervisor-Ebene, nicht innerhalb des Sandbox-Prozesses; erzwingen Sie CPU-, Speicher-, Festplatten- und Wandzeitlimits pro Sitzung; und bereinigen Sie Sitzungen aggressiv – zerstören Sie ephemere Sandboxen, sobald die Aufgabe abgeschlossen ist. Defense-in-Depth über all diese Kontrollen hinweg bietet eine deutlich bessere Sicherheit als jede einzelne starke Grenze.

Was sollten Sicherheitsteams bewerten, wenn sie KI-Agent-Sandboxen für den Unternehmenseinsatz überprüfen?

Die Sicherheitsüberprüfung im Unternehmen sollte sechs Bereiche abdecken: (1) Isolation – MicroVM oder Container? Ist jede Sitzung auf Dateisystem-, Prozess- und Netzwerkebene vollständig isoliert? (2) Ausgangsverkehr – standardmäßig offen oder standardmäßig verweigert? Ist die Ausgangsrichtlinie kundenkonfigurierbar? Wird der Cloud-Metadaten-Endpoint (169.254.169.254) blockiert? (3) Geheimnisse – wie werden Anmeldedaten injiziert? Sind sie pro Aufgabe mit kurzlebigen Token eingegrenzt? Werden sie beim Sitzungsabbau bereinigt? (4) Prüfung – werden Protokolle unterhalb des Sandbox-Prozesses (Kernel-/Hypervisor-Ebene) erstellt? Können Protokolle in ein SIEM exportiert werden? (5) Datenresidenz – ist BYOC- oder VPC-Bereitstellung verfügbar, sodass Workloads in Ihrem Cloud-Konto bleiben? (6) Compliance-Haltung – welche Zertifizierungen besitzt der Anbieter und wie lautet ihr Modell der gemeinsamen Verantwortung? Für Teams mit regulatorischen Anforderungen führen Sie diese Überprüfung vor der Produktionsbereitstellung durch, nicht danach.

Wie funktioniert Kernel-Isolation in einer KI-Agent-Sandbox?

Kernel-Isolation bedeutet, dass der Code des Agenten in einer Umgebung mit einem eigenen Kernel ausgeführt wird, der durch eine Hardware-Virtualisierungsgrenze (KVM) vom Host-Kernel getrennt ist. In Firecracker-basierten Sandboxen startet jede Sitzung einen minimalen Gast-Kernel innerhalb einer MicroVM. Prozesse innerhalb der Sandbox interagieren mit dem Gast-Kernel; der Host-Kernel ist von innen nicht sichtbar oder erreichbar. Eine im Gast-Kernel ausgenutzte Schwachstelle breitet sich nicht automatisch auf den Host aus, da die KVM-Grenze dazwischen liegt. Dies ist der entscheidende Sicherheitsvorteil gegenüber der containerbasierten Isolation, bei der alle Container den Host-Kernel gemeinsam nutzen und eine Kernel-Schwachstelle alle gleichzeitig betrifft.

Empfohlene Artikel

• Firecracker for AI Agent Sandboxes: Benefits, Limits, and Evaluation Questions
• Audit Logs for AI Agent Sandboxes: What Security Teams Need
• AI-Generated Code Sandbox: Requirements for Production Apps