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 ist: Was isoliert die Sandbox tatsächlich und was kann dennoch entweichen? Die meisten Sandboxes stoppen einige Dinge gut (Code-Ausführung auf Prozessebene, beliebige Dateisystem-Schreibvorgänge auf den Host) und lassen andere Dinge standardmäßig offen (abgehender Netzwerkverkehr, Paketinstallationen, Geheimnisse in Umgebungsvariablen). Diese Lücken zu verstehen, ist der Schlüssel zur Bewertung, ob eine Sandbox zu Ihrem Risikomodell passt.

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

Sicherheit in einer Code-Ausführungs-Sandbox ist keine binäre Eigenschaft. Es ist eine Reihe von Kontrollen, die jeweils eine bestimmte Risikokategorie adressieren. Wenn jemand fragt: „Ist diese Sandbox sicher?“, werden meist mehrere unterschiedliche Fragen auf einmal gestellt:

• Host-Isolation: Kann der innerhalb der Sandbox ausgeführte Code auf das Hostsystem entkommen?
• Mandantentrennung: Kann der Code eines Benutzers die Sitzung eines anderen Benutzers beeinträchtigen?
• Ausgangskontrolle: Kann der Code innerhalb der Sandbox das Internet, interne Dienste oder Metadaten-Endpoints erreichen?
• Geheimnis-Begrenzung: Sind Anmeldeinformationen für mehr Teile 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?

Eine Sandbox kann bei der Host-Isolation stark und bei der Ausgangskontrolle schwach sein. Stark bei der Ausgangskontrolle und schwach bei Geheimnissen. Die Bewertung „wie sicher“ erfordert eine getrennte Überprüfung jeder Dimension, anstatt ein einzelnes Etikett wie „containerisiert“ oder „MicroVM-basiert“ als vollständige Antwort zu akzeptieren.

Vergleich der Isolationsmodelle

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

Prozess-Isolation

Die Prozess-Isolation verwendet Betriebssystem-Primitive – Linux-Namespaces, cgroups, seccomp-Filter und AppArmor- oder SELinux-Profile –, um einzuschränken, worauf ein Prozess zugreifen kann. Die Sandbox läuft als Prozess auf dem Host-Betriebssystem und teilt sich den Host-Kernel.

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

Was es nicht verhindert: Kernel-Exploits, die durch eine gemeinsam genutzte Schwachstelle Privilegien ausweiten. Eine seccomp-Umgehung oder eine Kernel-Schwachstelle kann die Host-Grenze überbrücken.

Wann es geeignet ist: Kurzlebige, risikoarme, halbwegs vertrauenswürdige Codes, bei denen Startgeschwindigkeit und Portabilität wichtiger sind als eine harte VM-Grenze. Nicht empfohlen für die Ausführung von beliebigem, agentengeneriertem Code von externen Benutzern.

Container-Isolation (Docker/Namespaces)

Die Container-Isolation erweitert die Prozess-Isolation um ein strukturierteres Image-Modell, Netzwerk-Namespacing und Volume-Mounts. Die meisten Docker-basierten Sandbox-Implementierungen führen Code innerhalb eines Containers 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. Fehlkonfigurierte Volume-Mounts, zu weit gefasste seccomp-Profile, der --privileged-Modus und exponierte Docker-Sockets können die beabsichtigte Grenze aufheben.

Wann es geeignet ist: Viele Produktionsumgebungen nutzen Container effektiv für die KI-Code-Ausführung, wenn das seccomp-Profil streng, das Image minimal, der Ausgang beschränkt ist und kein privilegierter Zugriff gewährt wird. Das Risikomodell unterscheidet sich von MicroVMs, ist aber bei sorgfältiger Konfiguration beherrschbar.

MicroVM-Isolation (Firecracker/gVisor)

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

Was es verhindert: Gast-Kernel-Exploits breiten sich nicht auf den Host-Kernel oder andere Gäste aus. Die Host-Angriffsfläche wird auf den VMM (Virtual Machine Monitor) reduziert, der minimal gehalten wird.

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 – MicroVM-Isolation adressiert diese nicht.

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

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

Was trotzdem entweichen 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.

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

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 einen offenen Ausgang hat, kann ein Paketnamen-Konflikt, ein Typosquatting-Angriff oder ein Dependency-Confusion-Angriff bösartigen Code einschleusen, der mit allen Berechtigungen der Sandbox läuft. Die Isolationsgrenze begrenzt die Auswirkungsreichweite, verhindert die Installation jedoch nicht.

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

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

Ausgangs- und Netzwerkkontrollen

Der Ausgang ist die größte Lücke der meisten Sandboxes. Offener abgehender Internetzugang ist üblich, weil er praktisch ist – Agenten müssen Pakete installieren, APIs aufrufen und Ressourcen abrufen. Er schafft aber auch Risiken:

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

DNS-basierte Exfiltration: Selbst wenn HTTP blockiert ist, können abgehende DNS-Abfragen zur Datenexfiltration genutzt werden, indem Daten in Domain-Lookups codiert werden. DNS-Blockierung erfordert Filterung auf Resolver-Ebene, nicht nur die Blockierung von TCP/UDP 53 zu externen Servern.

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

Zu bewertende Kontrollen:

Kontrolle	Was sie verhindert	Was zu prüfen ist
Standardmäßig verweigerter Ausgang	Abgehende Verbindungen zu nicht gelisteten Zielen	Blockiert es auch DNS sowie TCP/UDP?
Ausgang basierend auf einer Positivliste	Verbindungen zu nicht genehmigten Domains	Ist die Positivliste kundenkonfigurierbar?
Blockierung von Metadaten-Endpoints	Abrufen von Cloud-Anmeldeinformationen über 169.254.169.254	Ist IPv6-Metadaten ebenfalls blockiert?
Ausgangs-Proxy	Protokollierung und Überprüfung des gesamten abgehenden Datenverkehrs	Ist das Proxy-Log zugänglich?
DNS-Filterung	DNS-basierte Exfiltration und Auflösung interner Namen	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-Agenten-Sandboxes folgen denselben 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 übermittelt.

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

Lebensdauer: Kurzlebige Anmeldeinformationen sind wesentlich sicherer als langlebige. Wenn eine Anmeldeinformation innerhalb einer Sandbox durchsickert, begrenzt eine kurze TTL das Expositionsfenster. Viele Cloud-IAM-Systeme unterstützen kurzlebige Tokens, die in Minuten oder Stunden ablaufen.

Injektionsmethode: Umgebungsvariablen sind die häufigste Injektionsmethode und für jeden Code im Prozess am leichtesten zugänglich. Geheimnisse, die über Dateisystem-Mounts injiziert werden, an einem Pfad, den der Agent nicht durchlaufen muss, oder dynamisch nur dann abgerufen werden, wenn das spezifische Tool, das sie benötigt, läuft, sind eingeschränkter als eine pauschale Umgebungsvariable.

Schwärzung: Geheimnisse sollten aus stdout, stderr, Tool-Antwort-Payloads, modellsichtbarem Kontext und Audit-Logs geschwärzt werden. Ein Agent, der seine Umgebung ausgibt, env aufruft oder ein Token an einen fehlschlagenden API-Aufruf weitergibt, kann Anmeldeinformationen in Logs 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 ausufernden Code, eine Endlosschleife, ein Speicherleck in einem installierten Paket oder einen bewussten Versuch, benachbarte Workloads zu stören.

Zu überprüfende Ressourcenkontrollen:

• CPU-Limits: Drosselung oder harte Grenzen 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 eine Wanduhrzeit überschreiten, sollten sauber beendet werden, nicht weiterlaufen.
• Netzwerk-Ratenbegrenzung: Begrenzungen der ausgehenden Bandbreite 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 Prozesstabelle erschöpfen.

Verstöße gegen Ressourcenlimits sollten ebenfalls protokolliert werden. Eine Sitzung, die bei leichten Aufgaben ständig die CPU-Drosselung oder den OOM-Kill erreicht, ist ein signal, das es zu untersuchen gilt.

Audit-Transparenz

Isolationskontrollen reduzieren die Auswirkungsreichweite, wenn etwas schiefgeht. Audit-Logs sind die Möglichkeit herauszufinden, dass etwas schiefgegangen ist, und zu rekonstruieren, was passiert ist.

Speziell für KI-Agenten-Sandboxes umfasst eine nützliche Audit-Abdeckung:

• Prozessausführung: Jeder ausgeführte Befehl mit vollständiger Argumentliste, UID und Elternprozess. Ohne Argumentlisten sind curl und python in einem Log nicht aussagekräftig.
• Dateisystemzugriff: Lese- und Schreibzugriffe auf sensible Pfade. Schreib- und Löschvorgänge haben für die meisten Bedrohungsmodelle höhere Priorität als Lesevorgänge.
• Abgehender Netzwerkverkehr: Ziele, Protokolle, DNS-Abfragen und übertragene Bytes. Die Protokollierung von DNS-Abfragen fehlt oft, ist aber wichtig.
• Paketinstallationen: Paketmanager, Paketname, Version, Quellregister und Hash.
• Sitzungslebenszyklus: Erstellungs-, Pause-, Fortsetzungs-, Beendigungs- und Bereinigungsereignisse mit Grundcodes.
• Ressourcenlimit-Ereignisse: OOM-Kills, CPU-Drosselung, Timeout-Beendigung.

Die Erfassungsmethode ist ebenso wichtig wie die Abdeckung. Logs, die innerhalb des Sandbox-Prozesses generiert werden, können von einem ausreichend privilegierten Agenten unterdrückt oder verändert werden. Die Erfassung auf Kernel-Ebene (über auditd, eBPF oder Hypervisor-Instrumentierung) erfolgt unterhalb der Anwendungsschicht, wo der Agent keine Schreibberechtigung hat.

Fragen an jeden Sandbox-Anbieter oder jedes Projekt

Verwenden Sie diese Checkliste bei der Bewertung eines verwalteten Sandbox-Dienstes oder eines Open-Source-Sandbox-Frameworks:

Isolation

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

Netzwerk und Ausgang

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

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 Anmeldeinformationen in die Sandbox injiziert?
• Können Anmeldeinformationen auf das spezifische Tool oder den Task begrenzt werden, der sie benötigt?
• Werden Geheimnisse aus Logs und modellsichtbaren Ausgaben geschwärzt?

Ressourcenlimits

• Werden CPU-, Speicher-, Festplatten- und Zeitbeschränkungen durchgesetzt?
• Was passiert, wenn ein Limit erreicht wird – Drosselung, Kill oder Alarm?

Audit-Logs

• Werden Logs auf Kernel-/Hypervisor-Ebene oder innerhalb des Sandbox-Prozesses generiert?
• Welche Ereigniskategorien werden standardmäßig protokolliert?
• Können Logs in ein externes SIEM- oder Log-Aggregationssystem exportiert werden?
• Wie ist die Aufbewahrungsrichtlinie für Logs?

Mandantenfähigkeit

• Sind Workloads verschiedener Mandanten voneinander isoliert?
• Gibt es gemeinsame Caches, Images oder Mounts, die kanäle zwischen Mandanten schaffen?

Wo die Novita Agent Sandbox einzuordnen ist

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

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

Bei der Bewertung der Novita Agent Sandbox für sicherheitsrelevante Anwendungsfälle sollten Sie vor Architekturentscheidungen das aktuelle Isolationsmodell, die Standardeinstellungen der Ausgangsrichtlinie, die Log-Abdeckung und den Umgang mit Geheimnissen in der Produktdokumentation überprüfen. Die Sicherheitsanforderungen variieren stark je nach Workload – was für eine interne Evaluierungspipeline angemessen ist, kann für ein Multi-Tenant-Produkt mit benutzergeliefertem Code unzureichend sein.

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

Einschränkungen und was keine Sandbox eliminiert

Keine Sandbox eliminiert alle Risiken. Zu verstehen, was außerhalb der Grenze bleibt, ist ebenso wichtig wie zu verstehen, was die Grenze bietet.

Vertrauensentscheidungen auf Anwendungsebene: Die Sandbox kontrolliert die Laufzeitausführung. Sie entscheidet nicht, was der Agent anfordern darf. Wenn Ihre Anwendung zulässt, dass ein Agent eine Anmeldeinformation anfordert, beliebige Shell-Befehle ausführt oder jede beliebige API aufruft, reduziert die Sandbox die Auswirkungsreichweite, verhindert diese Aktionen jedoch nicht.

Prompt-Injection: Ein Agent, der nicht vertrauenswürdige Inhalte verarbeitet – Webseiten, hochgeladene Benutzerdateien, externe API-Antworten – kann durch diese Inhalte manipuliert werden, um Aktionen auszuführen, die er nicht 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. MicroVM-Isolation bietet die stärkste Grenze im derzeitigen Produktionseinsatz, aber VMM-Schwachstellen existieren. Defense-in-Depth – die Kombination mehrerer Kontrollen anstatt das Vertrauen auf eine einzelne Grenze – ist eine robustere Haltung als jedes einzelne Isolationsmodell.

Social Engineering durch Modellausgabe: Ein Agent kann eine Ausgabe produzieren, die einen menschlichen Bediener zu einer unsicheren Aktion verleitet. Sandboxes prüfen keine menschlichen Entscheidungen.

Compliance- und regulatorisches Risiko: 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ührungs-Sandbox wird am besten als eine Reihe von zu bewertenden und zu konfigurierenden Kontrollen betrachtet, nicht als eine Eigenschaft, die man durch die Produktauswahl 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 sandboxed KI-Code-Ausführungsumgebung im Vergleich zur Ausführung von Code auf einem Server?

Eine gut konfigurierte Sandbox reduziert die Auswirkungsreichweite bei der Ausführung von nicht vertrauenswürdigem Code im Vergleich zur direkten Ausführung auf einem Server erheblich. Sie schränkt den Dateisystemzugriff, den Prozessumfang und den Netzwerkzugriff ein. Der Unterschied hängt jedoch von der Konfiguration ab. Ein Container mit offenem Ausgang 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 gemeinsam genutzte Kernel-Container nicht bieten. Sie kontrolliert jedoch nicht den Ausgang, Geheimnisse, Paketinstallationen oder die Audit-Abdeckung. Eine MicroVM mit offenem Ausgang und ohne Log-Erfassung ist nicht „vollständig sicher“, auch wenn die Isolationsschicht stark ist.

Kann KI-generierter Code aus einer Sandbox entkommen?

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

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

Offener abgehender Ausgang ist das am häufigsten unzureichend adressierte Risiko. Viele Sandboxes erlauben standardmäßig uneingeschränkten abgehenden Internetzugriff, weil es praktisch ist für Agenten, die Pakete installieren und APIs aufrufen müssen. Dies schafft Pfade für Datenexfiltration, Diebstahl von Anmeldeinformationen über Cloud-Metadaten-Endpoints und Command-and-Control-Kommunikation, die unabhängig davon existieren, wie stark die Isolationsgrenze ist.

Sollte ich eine verwaltete Sandbox verwenden oder meine eigene bauen?

Verwaltete Sandboxes übernehmen die operationelle Komplexität des MicroVM- oder Container-Lebenszyklus, der Host-Kapazität und des Image-Managements. Der Eigenbau gibt Ihnen mehr Kontrolle über den gesamten Richtlinien-Stack. In beiden Fällen gelten dieselben Bewertungsfragen: Ausgangsrichtlinie, Umgang mit Geheimnissen, Log-Abdeckung, Ressourcenlimits und Auditexport. Die Build-vs.-Buy-Entscheidung ist getrennt von der Sicherheitsbewertung.

Was unterscheidet die Sicherheit von Agenten-Sandboxes von der herkömmlichen Code-Ausführungssicherheit?

Herkömmliche Code-Ausführungssicherheit geht davon aus, dass man grob weiß, 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 startet, ohne dass für jeden Schritt eine explizite Entwicklergenehmigung erforderlich ist. Dies macht die Audit-Abdeckung wichtiger (Sie können nicht jede Aktion vorhersehen), die Ausgangskontrollen wichtiger (der Agent kann Ziele erreichen, die Sie nicht erwartet haben) und die Begrenzung von Geheimnissen wichtiger (der Agent hat Zugriff auf alles in seiner Umgebung).

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