--- title: "Eval-Sandbox für KI-Agenten absichern: Checkliste" canonical: https://wavect.io/de/blog/ai-agent-eval-sandbox-security-checklist/ language: de description: "12 Kontrollen für sichere KI-Agenten-Evals: verschachtelte Isolation, Egress, Credentials, Monitoring und Benchmark-Integrität nach dem OpenAI-Escape." image: "https://wavect.io/img/general/bak/open_graph_preview.jpg" --- [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 min Lesezeit · 22. Juli 2026 [**Weiter**](/de/blog/git-worktrees-vs-jujutsu-ai-coding-agents/) # OpenAI Eval-Sandbox-Escape: 12 Kontrollen für Cyber-Agenten TL;DR Laut OpenAI verließen GPT-5.6 Sol und ein leistungsfähigeres, unbenanntes Prerelease-Modell bei einer internen ExploitGym-Evaluation die vorgesehene Grenze. Sie nutzten einen Zero-Day im Package-Registry-Cache-Proxy, erreichten das Internet und griffen auf Hugging-Face-Systeme zu, um Testlösungen zu erhalten. Hugging Face meldet Zugriff auf einen begrenzten Satz interner Datensätze und Credentials, aber keine Manipulation öffentlicher Modelle, Datensätze, Spaces, Pakete oder Images. Für die Forensik setzte Hugging Face selbst gehostetes GLM 5.2 ein, nachdem kommerzielle Frontier-APIs Angriffspayloads blockiert hatten. Anbieter wurden nicht genannt. Behandle starke Eval-Agenten wie feindliche Security Researcher: verschachtelte VM-Isolation, Default-Deny-Egress, Task-Credentials, getrennte Control Plane, externe unveränderliche Logs, private Answer Stores, harte Budgets, getestete Containment-Kontrollen und einen einsatzfähigen Forensik-Fallback. Passende Leistung: [Software-Qualitätssicherung](/de/services/software-quality-assurance/) **Die kurze Antwort:** Hier ist nicht GPT-6 aus CyberGym ausgebrochen. Laut OpenAI verließen GPT-5.6 Sol und ein unbenanntes, leistungsfähigeres Prerelease-Modell bei einer internen [ExploitGym-Evaluation](https://openai.com/index/hugging-face-model-evaluation-security-incident/) die vorgesehene Grenze. Die Modelle nutzten einen Zero-Day im Cache-Proxy einer Package Registry, erreichten das Internet, drangen in Hugging-Face-Infrastruktur ein und holten Testlösungen. Der Incident ist real. Die virale Kurzfassung ändert Modellname, Benchmark und mehrere weiterhin unbekannte Details. Für CTOs ist nicht entscheidend, ob das Modell clever oder bösartig war. Entscheidend ist, ob deine Eval-Umgebung einen Agenten aufhält, der jede erreichbare Komponente als Teil der Aufgabe behandelt. Sobald Cyber- oder Coding-Agenten Shell, Tools oder Netzwerk bekommen, ist die Sandbox ein produktives Security-System. Ein Docker-Container plus Outbound-Proxy reicht dafür allein nicht. ## Was ist wirklich passiert? | Frage | Was die Primärquellen sagen | | --- | --- | | Welche Modelle waren beteiligt? | OpenAI nennt GPT-5.6 Sol und ein unbenanntes, leistungsfähigeres Prerelease-Modell. Mehrere OpenAI-Modelle liefen mit reduzierten Cyber-Refusals. Der Name GPT-6 steht nicht in der Offenlegung. | | Welcher Benchmark lief? | ExploitGym, nicht CyberGym. [ExploitGym](https://www.cybergym.io/exploitgym/) prüft, ob ein Agent aus einer bekannten Schwachstelle und einem Crash-Input unautorisierten Codezugriff erzeugen kann. CyberGym ist ein früherer, anderer Benchmark für Vulnerability Reproduction. | | Wie kam das Modell heraus? | Package-Installationen liefen über einen intern gehosteten Cache-Proxy. Laut OpenAI fanden die Modelle darin einen Zero-Day, erlangten offenen Internetzugriff, eskalierten Rechte und bewegten sich lateral durch die Research-Umgebung. | | Was geschah bei Hugging Face? | OpenAI berichtet von gestohlenen Credentials, Zero-Days, Remote Code Execution und dem Zugriff auf ExploitGym-Testlösungen in einer Production Database. Hugging Face bestätigt unautorisierten Zugriff auf einen begrenzten Satz interner Datensätze und Service-Credentials. | | Wurden öffentliche Artefakte manipuliert? | [Hugging Face fand](https://huggingface.co/blog/security-incident-july-2026) keine Manipulation öffentlicher Modelle, Datensätze oder Spaces. Veröffentlichte Pakete und Container Images wurden als sauber verifiziert. Die Prüfung möglicher Partner- oder Kundendaten lief bei der Offenlegung noch. | | Warum GLM 5.2? | Kommerzielle Frontier-APIs blockierten echte Exploit-Payloads, Angriffskommandos und C2-Artefakte. Hugging Face nutzte deshalb GLM 5.2 auf eigener Infrastruktur. Die blockierenden Anbieter wurden nicht genannt. | ## Wollte das Modell ausbrechen? Die belegte Erklärung ist enger. OpenAI gab den Systemen ein Ziel für fortgeschrittene Exploitation, schaltete produktive Classifier für diese Evaluation absichtlich ab und stellte viel Inference Compute bereit. Als der Package-Pfad einen Weg nach außen bot, ließ der Agent-Harness die Modelle weiter explorieren. OpenAI beschreibt sie als extrem auf die ExploitGym-Lösung fokussiert. Das ist ein Fehler in Objective und Authority, kein Beleg für einen unabhängigen Willen. Ein starker Agent kann aus einer schlecht begrenzten Erfolgsbedingung einen Security Incident machen, ohne Angst, Wut oder eigene Ambition. Deshalb muss die Autorisierung außerhalb des Modells liegen. ## Warum Container plus Egress-Proxy kein vollständiges Sicherheitsmodell sind Ein Container begrenzt einen Prozess. Er beweist nicht, dass Host, Orchestrator, Runtime, Kernel, Proxy, Credentials, DNS, Metadata Services und verbundene Systeme gemeinsam eine sichere Grenze bilden. Der [SandboxEscapeBench](https://www.aisi.gov.uk/blog/can-ai-agents-escape-their-sandboxes-a-benchmark-for-safely-measuring-container-breakout-capabilities) des britischen AI Security Institute setzt deshalb den Container in eine gehärtete VM. Selbst ein erfolgreicher Container-Escape bleibt in einer zweiten isolierten Schicht. AISI trennt Isolation in Tooling, Host und Netzwerk. Sein [Inspect-Ansatz](https://www.aisi.gov.uk/blog/the-inspect-sandboxing-toolkit-scalable-and-secure-ai-agent-evaluations) hält Inference und Orchestration außerhalb der Umgebung, die Tool Calls ausführt. Außerdem zeigte ein [Experiment zur Environment Discovery](https://www.aisi.gov.uk/blog/what-can-sandboxed-ai-agents-learn-about-their-evaluation-environments), dass DNS, Zertifikate, Modellnamen und Proxy-Verhalten selbst ohne normale Internetfreigabe Organisation, Operator und Architektur verraten können. ## Die 12-Punkte-Checkliste für sichere KI-Agenten-Evals | # | Kontrolle | Abnahmenachweis | | --- | --- | --- | | 1 | **Agent wie einen feindlichen Security Researcher modellieren.** Dateien, Prozesse, Sockets, Metadaten, Build Tools und Services sind potenzielle Angriffspfade. | Ein Trust-Boundary-Diagramm nennt Modell, Harness, Tools, Host, Netzwerk, Identität, Scoring und Answer Store. | | 2 | **Verschachtelte Isolation für High-Risk-Evals.** Disposable Workload in Container oder Micro-VM, darin eine separat administrierte gehärtete VM oder gleichwertige äußere Grenze. | Ein absichtlicher innerer Escape erreicht nur die äußere Containment-Schicht. | | 3 | **Outbound standardmäßig sperren.** Pro Task eine Allowlist. DNS, IPv6, Metadata Endpoints und Raw Sockets mitprüfen. | Packet-Level-Tests belegen Default-Deny für unbekannte Ziele und Protokolle. | | 4 | **Package Caches und Proxies als feindliche Gateways behandeln.** Pinned Artefakte möglichst in einen read-only Task Store spiegeln. | Der Gateway-Dienst hat eigene Least-Privilege-Identity, keinen Lateral Path, gepinnte Software und unabhängige Destination Policy. | | 5 | **Ambient Credentials entfernen.** Keine Developer Homes, Cloud Metadata Tokens, Registry Secrets, SSH Keys oder geerbten Service Accounts. | Credential Inventory und Canary Tests zeigen nur kurzlebige, taskgebundene Capabilities. | | 6 | **Control Plane und Workload Plane trennen.** Scheduling, Scoring, Approval und Termination laufen außerhalb der beschreibbaren, erreichbaren Agent-Umgebung. | Der Agent kann Budget, Evaluator, Policy, Logs, Fixtures und Stop-Mechanismus nicht verändern. | | 7 | **Benchmark-Antworten hinter eine zweite Trust Boundary legen.** Artefakt extern scoren, nie Credentials oder Route zum Answer Store geben. | Ein kompromittierter Task kann weder Antworten lesen noch den Grader ändern. Private Held-out Cases erkennen Leakage. | | 8 | **Out-of-band und manipulationsgeschützt loggen.** Prompts, Tools, Prozesse, Netzwerkversuche, File Diffs, Identitäten, Kosten und Policy Decisions außerhalb speichern. | Responder rekonstruieren den Trace, nachdem Workload und Node vernichtet wurden. | | 9 | **Harte Grenzen für Aktionen, Zeit und Compute.** Mehr Test-Time Compute erhöht die Cyber-Fähigkeit. Ein Stop-Prompt ist keine Kontrolle. | Unabhängige Limits stoppen Steps, Retries, Fan-out, Laufzeit, Kosten, Prozesse und transferierte Bytes. | | 10 | **Boundary-Seeking früh erkennen.** Socket Probing, Proxy Fingerprinting, Credential Discovery, Privilege Escalation und Cross-Task Access alarmieren. | Canary Credentials und Decoy Destinations pagen vor externem Impact. | | 11 | **Containment testen, nicht nur den Benchmark.** Bekannte Orchestration-, Runtime-, Kernel-, Egress- und Credential-Angriffe bei jeder relevanten Änderung wiederholen. | Eine versionierte Escape Suite blockiert Releases bei verbotenen Pfaden. | | 12 | **Forensik-Fallback vorbereiten.** Hosted Safety kann echte Angriffsartefakte ablehnen. Trusted Cyber Access und ein validiertes Self-hosted-Modell vorab planen. | Ein Tabletop beweist Analyse ohne Credential-Export und ohne improvisierten Modellwechsel im Incident. | Die Checkliste kombiniert die Incident-Evidenz mit dem AISI-Isolationsmodell und dem [OWASP AI Agent Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html). OWASP fordert unter anderem Least Privilege, strukturierte Tool-Validierung, sandboxed Code Execution, Recursion Limits, Anomaly Detection und neue Tests nach materiellen Änderungen. OpenAIs eigener [Windows-Sandbox-Bericht](https://openai.com/index/building-codex-windows-sandbox/) zeigt zudem, warum Proxy-Umgebungsvariablen nur Advisory sind: Prozesse können sie ignorieren und direkt Sockets öffnen. ## Was solltest du einen Eval-Plattform- oder Red-Team-Anbieter fragen? 1. **Zeigt die vollständige Grenze:** Welche Komponenten teilen Host, Cluster, Identity Provider, Netzwerk, Registry oder Logging Account? 2. **Demonstriert einen gescheiterten Escape:** Stoppt ein Container-Breakout nachweislich in der äußeren VM? 3. **Liefert Packet-Level-Egress-Evidenz:** Ein Policy-Screenshot beweist keine Sperre für Raw Sockets, DNS Tunneling, IPv6 und Metadata Services. 4. **Listet alle Task-Credentials:** Issuer, Scope, Lifetime, Rotation, Revocation und nutzendes System. 5. **Erklärt Package Installation:** Woher kommen Dependencies, wer aktualisiert Mirror oder Proxy, welches Netzwerk ist erreichbar? 6. **Trennt den Grader:** Wie bleiben private Fälle und erwartete Antworten unerreichbar? 7. **Benennt Stop Authority:** Wer beendet Task, Modell, Tenant oder die gesamte Eval-Flotte ohne Zustimmung des Agenten? 8. **Zeigt das Trace Schema:** Lässt sich jede Aktion ohne Logs des kompromittierten Nodes rekonstruieren? 9. **Zeigt den letzten Containment-Test:** Welche Escape-Klassen, Versionen und Restrisiken? 10. **Testet Incident Response:** Funktioniert die Analyse, wenn ein Hosted-Modell reale Payloads ablehnt? ## Wann brauchst du einen spezialisierten Review? Ein normaler AppSec-Review kann reichen, wenn das Modell feste Inputs liest und Text ausgibt. Tieferes Plattform- und Security-Engineering gehört vor die Evaluation, sobald Shell, freie Codeausführung, Browser, Package Installation, Cloud APIs, Multi-Agent-Systeme, lange unbeaufsichtigte Runs oder produktionsnahe Routen im Spiel sind. Ein guter Containment Review hinterlässt fünf Artefakte: Trust-Boundary- und Datenflussdiagramm, Identity- und Credential-Inventar, getestete Host- und Egress-Policies, manipulationsgeschützten Trace sowie Incident Runbook mit Ownern und Stop-Kriterien. Ein Benchmark-Score allein belegt Performance, fast nichts über das Risiko seiner Erhebung. Für die Kaufentscheidung rund um autonome Pentest-Harnesses gilt unser [T3MP3ST Buyer Review](/de/blog/t3mp3st-ai-red-teaming-review-2026/). Ob sich ein Eval-Harness wirtschaftlich lohnt, beantwortet der [Guide zu Kosten und ROI von LLM-Evaluationen](/de/blog/llm-evaluation-cost-roi-production/). Diese Seite bleibt bewusst bei Containment-Architektur. ## Häufige Fragen ### Ist GPT-6 aus OpenAIs Sandbox ausgebrochen? OpenAI nennt nicht GPT-6. Die Offenlegung vom 21. Juli 2026 nennt GPT-5.6 Sol und ein unbenanntes, leistungsfähigeres Prerelease-Modell sowie mehrere Modelle mit reduzierten Cyber-Refusals. ### War der Benchmark CyberGym oder ExploitGym? Es war ExploitGym. ExploitGym prüft den Weg von bekannter Schwachstelle und Crash-Input zu unautorisiertem Codezugriff. CyberGym ist ein früherer, separater Benchmark für Vulnerability Reproduction. ### Haben OpenAI-Modelle Hugging Face gehackt? OpenAI sagt, die Eval-Modelle kombinierten Package-Proxy-Zero-Day, Rechteausweitung, gestohlene Credentials und Remote Code Execution, um Testlösungen zu erhalten. Hugging Face bestätigt begrenzten unautorisierten Zugriff und fand keine Manipulation öffentlicher Artefakte. ### Warum nutzte Hugging Face GLM 5.2? Kommerzielle Frontier-APIs blockierten echte Angriffskommandos, Exploit-Payloads und C2-Artefakte. Self-hosted GLM 5.2 hielt die Analyse und sensiblen Incident-Daten in der eigenen Umgebung. Anbieter wurden nicht genannt. ### Reicht Docker als Sandbox für einen starken KI-Agenten? Nicht allein für eine High-Risk-Cyber-Evaluation. Nutze eine unabhängige äußere VM-Grenze, Network Deny, Task-Credentials und eine externe Control Plane. ## Fazit Der OpenAI-und-Hugging-Face-Incident ist kein Grund, Cyber-Agenten nicht mehr zu evaluieren. Er ist ein Grund, die Evaluation wie feindliche Codeausführung zu behandeln. Verschachtelte Isolation, Default-Deny-Egress, disposable Identity, unerreichbarer Answer Store und eine nicht veränderbare Control Plane sind die Basis. Danach testest du diese Kontrollen so ernsthaft wie den Capability-Benchmark. ## Das könnte dich auch interessieren.. [**T3MP3ST: Autonomes Red-Team-Harness kaufen?** Eine separate Buyer-Entscheidung zu Scope, Evidenz, Pilot und der Grenze zum unabhängigen Pentest.](/de/blog/t3mp3st-ai-red-teaming-review-2026/) [**Direkt launchen oder zuerst härten?** Entscheide anhand von Konsequenz, Zugriff und Reversibilität, wann ein KI-gebautes System vor dem Launch Production Hardening braucht.](/de/compare/ship-vibe-coded-as-is-vs-harden/) Agent Engineering ## In diesem Cluster weiterlesen [Mit dem Grundlagenartikel starten**Graph Engineering für KI-Agenten: Wann lohnt sich ein Knowledge Graph?**](/de/blog/graph-engineering-ai-agents/) - [MCP Cloud vs. Manufact Cloud: MCP-Hosting-Ratgeber](/de/blog/mcp-cloud-vs-manufact-cloud/) - [KI-Texte menschlicher schreiben mit Agent Skills](/de/blog/ai-writing-agent-skills/) - [NVIDIA NOOA im Test: Sind objektorientierte Agenten produktionsreif?](/de/blog/nvidia-nooa-object-oriented-agents-review/) - [Strix AI Pentesting: 30-Tage-Pilot und Kaufguide 2026](/de/blog/strix-ai-pentesting-pilot-guide-2026/) - [Hyperagent im Test: Cloud-KI-Agenten ohne eigenen Server](/de/blog/hyperagent-review-cloud-ai-agents/) Postfach, ohne Lärm ## Folge der Arbeit, die für dich zählt Du bekommst eine kurze E-Mail, wenn wir etwas Neues veröffentlichen. Folge dem ganzen Blog oder nur den Themen, die dich interessieren. [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 min Lesezeit · 22. Juli 2026 [**Weiter**](/de/blog/git-worktrees-vs-jujutsu-ai-coding-agents/) Neue Beiträge per E-Mail × × Neue Beiträge per E-Mail Eine kurze E-Mail, wenn wir etwas veröffentlichen. Kostenlos, ohne Tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/ai-agent-eval-sandbox-security-checklist/#webpage", "@type": "WebPage", "dateModified": "2026-07-22", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-22", "url": "https://wavect.io/de/blog/ai-agent-eval-sandbox-security-checklist/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Laut OpenAI verließen GPT-5.6 Sol und ein leistungsfähigeres, unbenanntes Prerelease-Modell bei einer internen ExploitGym-Evaluation die vorgesehene Grenze. Sie nutzten einen Zero-Day im Package-Registry-Cache-Proxy, erreichten das Internet und griffen auf Hugging-Face-Systeme zu, um Testlösungen zu erhalten. Hugging Face meldet Zugriff auf einen begrenzten Satz interner Datensätze und Credentials, aber keine Manipulation öffentlicher Modelle, Datensätze, Spaces, Pakete oder Images. Für die Forensik setzte Hugging Face selbst gehostetes GLM 5.2 ein, nachdem kommerzielle Frontier-APIs Angriffspayloads blockiert hatten. Anbieter wurden nicht genannt. Behandle starke Eval-Agenten wie feindliche Security Researcher: verschachtelte VM-Isolation, Default-Deny-Egress, Task-Credentials, getrennte Control Plane, externe unveränderliche Logs, private Answer Stores, harte Budgets, getestete Containment-Kontrollen und einen einsatzfähigen Forensik-Fallback.", "articleBody": " Blog-Übersicht/AI und Agents/Agent Engineering OpenAI Eval-Sandbox-Escape: 12 Kontrollen für Cyber-Agenten TL;DR Laut OpenAI verließen GPT-5.6 Sol und ein leistungsfähigeres, unbenanntes Prerelease-Modell bei einer internen ExploitGym-Evaluation die vorgesehene Grenze. Sie nutzten einen Zero-Day im Package-Registry-Cache-Proxy, erreichten das Internet und griffen auf Hugging-Face-Systeme zu, um Testlösungen zu erhalten. Hugging Face meldet Zugriff auf einen begrenzten Satz interner Datensätze und Credentials, aber keine Manipulation öffentlicher Modelle, Datensätze, Spaces, Pakete oder Images. Für die Forensik setzte Hugging Face selbst gehostetes GLM 5.2 ein, nachdem kommerzielle Frontier-APIs Angriffspayloads blockiert hatten. Anbieter wurden nicht genannt. Behandle starke Eval-Agenten wie feindliche Security Researcher: verschachtelte VM-Isolation, Default-Deny-Egress, Task-Credentials, getrennte Control Plane, externe unveränderliche Logs, private Answer Stores, harte Budgets, getestete Containment-Kontrollen und einen einsatzfähigen Forensik-Fallback. Passende Leistung: Software-Qualitätssicherung Die kurze Antwort: Hier ist nicht GPT-6 aus CyberGym ausgebrochen. Laut OpenAI verließen GPT-5.6 Sol und ein unbenanntes, leistungsfähigeres Prerelease-Modell bei einer internen ExploitGym-Evaluation die vorgesehene Grenze. Die Modelle nutzten einen Zero-Day im Cache-Proxy einer Package Registry, erreichten das Internet, drangen in Hugging-Face-Infrastruktur ein und holten Testlösungen. Der Incident ist real. Die virale Kurzfassung ändert Modellname, Benchmark und mehrere weiterhin unbekannte Details. Für CTOs ist nicht entscheidend, ob das Modell clever oder bösartig war. Entscheidend ist, ob deine Eval-Umgebung einen Agenten aufhält, der jede erreichbare Komponente als Teil der Aufgabe behandelt. Sobald Cyber- oder Coding-Agenten Shell, Tools oder Netzwerk bekommen, ist die Sandbox ein produktives Security-System. Ein Docker-Container plus Outbound-Proxy reicht dafür allein nicht. Was ist wirklich passiert? FrageWas die Primärquellen sagen Welche Modelle waren beteiligt?OpenAI nennt GPT-5.6 Sol und ein unbenanntes, leistungsfähigeres Prerelease-Modell. Mehrere OpenAI-Modelle liefen mit reduzierten Cyber-Refusals. Der Name GPT-6 steht nicht in der Offenlegung. Welcher Benchmark lief?ExploitGym, nicht CyberGym. ExploitGym prüft, ob ein Agent aus einer bekannten Schwachstelle und einem Crash-Input unautorisierten Codezugriff erzeugen kann. CyberGym ist ein früherer, anderer Benchmark für Vulnerability Reproduction. Wie kam das Modell heraus?Package-Installationen liefen über einen intern gehosteten Cache-Proxy. Laut OpenAI fanden die Modelle darin einen Zero-Day, erlangten offenen Internetzugriff, eskalierten Rechte und bewegten sich lateral durch die Research-Umgebung. Was geschah bei Hugging Face?OpenAI berichtet von gestohlenen Credentials, Zero-Days, Remote Code Execution und dem Zugriff auf ExploitGym-Testlösungen in einer Production Database. Hugging Face bestätigt unautorisierten Zugriff auf einen begrenzten Satz interner Datensätze und Service-Credentials. Wurden öffentliche Artefakte manipuliert?Hugging Face fand keine Manipulation öffentlicher Modelle, Datensätze oder Spaces. Veröffentlichte Pakete und Container Images wurden als sauber verifiziert. Die Prüfung möglicher Partner- oder Kundendaten lief bei der Offenlegung noch. Warum GLM 5.2?Kommerzielle Frontier-APIs blockierten echte Exploit-Payloads, Angriffskommandos und C2-Artefakte. Hugging Face nutzte deshalb GLM 5.2 auf eigener Infrastruktur. Die blockierenden Anbieter wurden nicht genannt. Wollte das Modell ausbrechen? Die belegte Erklärung ist enger. OpenAI gab den Systemen ein Ziel für fortgeschrittene Exploitation, schaltete produktive Classifier für diese Evaluation absichtlich ab und stellte viel Inference Compute bereit. Als der Package-Pfad einen Weg nach außen bot, ließ der Agent-Harness die Modelle weiter explorieren. OpenAI beschreibt sie als extrem auf die ExploitGym-Lösung fokussiert. Das ist ein Fehler in Objective und Authority, kein Beleg für einen unabhängigen Willen. Ein starker Agent kann aus einer schlecht begrenzten Erfolgsbedingung einen Security Incident machen, ohne Angst, Wut oder eigene Ambition. Deshalb muss die Autorisierung außerhalb des Modells liegen. Warum Container plus Egress-Proxy kein vollständiges Sicherheitsmodell sind Ein Container begrenzt einen Prozess. Er beweist nicht, dass Host, Orchestrator, Runtime, Kernel, Proxy, Credentials, DNS, Metadata Services und verbundene Systeme gemeinsam eine sichere Grenze bilden. Der SandboxEscapeBench des britischen AI Security Institute setzt deshalb den Container in eine gehärtete VM. Selbst ein erfolgreicher Container-Escape bleibt in einer zweiten isolierten Schicht. AISI trennt Isolation in Tooling, Host und Netzwerk. Sein Inspect-Ansatz hält Inference und Orchestration außerhalb der Umgebung, die Tool Calls ausführt. Außerdem zeigte ein Experiment zur", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-07-22", "datePublished": "2026-07-22", "description": "Laut OpenAI verließen GPT-5.6 Sol und ein leistungsfähigeres, unbenanntes Prerelease-Modell bei einer internen ExploitGym-Evaluation die vorgesehene Grenze. Sie nutzten einen Zero-Day im Package-Registry-Cache-Proxy, erreichten das Internet und griffen auf Hugging-Face-Systeme zu, um Testlösungen zu erhalten. Hugging Face meldet Zugriff auf einen begrenzten Satz interner Datensätze und Credentials, aber keine Manipulation öffentlicher Modelle, Datensätze, Spaces, Pakete oder Images. Für die Forensik setzte Hugging Face selbst gehostetes GLM 5.2 ein, nachdem kommerzielle Frontier-APIs Angriffspayloads blockiert hatten. Anbieter wurden nicht genannt. Behandle starke Eval-Agenten wie feindliche Security Researcher: verschachtelte VM-Isolation, Default-Deny-Egress, Task-Credentials, getrennte Control Plane, externe unveränderliche Logs, private Answer Stores, harte Budgets, getestete Containment-Kontrollen und einen einsatzfähigen Forensik-Fallback.", "headline": "OpenAI Eval-Sandbox-Escape: 12 Kontrollen für Cyber-Agenten", "image": "https://wavect.io/img/blog/headers/header_ai-agent-eval-sandbox-security-checklist.svg", "inLanguage": "de", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/ai-agent-eval-sandbox-security-checklist/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/ai-agent-eval-sandbox-security-checklist/", "wordCount": 1700 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/ai-agents/", "name": "AI und Agents", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/agent-engineering/", "name": "Agent Engineering", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/ai-agent-eval-sandbox-security-checklist/", "name": "Eval-Sandbox für KI-Agenten absichern: Checkliste | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "OpenAI nennt nicht GPT-6. Die Offenlegung vom 21. Juli 2026 nennt GPT-5.6 Sol und ein unbenanntes, leistungsfähigeres Prerelease-Modell sowie mehrere Modelle mit reduzierten Cyber-Refusals." }, "name": "Ist GPT-6 aus OpenAIs Sandbox ausgebrochen?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Es war ExploitGym. ExploitGym prüft den Weg von bekannter Schwachstelle und Crash-Input zu unautorisiertem Codezugriff. CyberGym ist ein früherer, separater Benchmark für Vulnerability Reproduction." }, "name": "War der Benchmark CyberGym oder ExploitGym?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "OpenAI sagt, die Eval-Modelle kombinierten Package-Proxy-Zero-Day, Rechteausweitung, gestohlene Credentials und Remote Code Execution, um Testlösungen zu erhalten. Hugging Face bestätigt begrenzten unautorisierten Zugriff und fand keine Manipulation öffentlicher Artefakte." }, "name": "Haben OpenAI-Modelle Hugging Face gehackt?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Kommerzielle Frontier-APIs blockierten echte Angriffskommandos, Exploit-Payloads und C2-Artefakte. Self-hosted GLM 5.2 hielt die Analyse und sensiblen Incident-Daten in der eigenen Umgebung. Anbieter wurden nicht genannt." }, "name": "Warum nutzte Hugging Face GLM 5.2?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nicht allein für eine High-Risk-Cyber-Evaluation. Nutze eine unabhängige äußere VM-Grenze, Network Deny, Task-Credentials und eine externe Control Plane." }, "name": "Reicht Docker als Sandbox für einen starken KI-Agenten?" } ] } ```