Eine Nachricht, voller Zugriff: Was der Cowork-Sandbox-Ausbruch für Ihre KI-Agenten-Strategie bedeutet

Eine einzige Nachricht. Eine frisch verbundene Session. Kein zusätzlicher Klick, kein Permission-Prompt. Und am Ende: voller Lese- und Schreibzugriff auf das gesamte Nutzerkonto eines Mac, inklusive SSH-Schlüsseln und Cloud-Zugangsdaten. So beschreibt die IT-Sicherheitsfirma Accomplish AI in einem am 23. Juli 2026 veröffentlichten Blogpost mit dem Titel "SharedRoot: Escaping the Claude Cowork sandbox", wie sie aus der Sandbox von Anthropics Claude Cowork ausgebrochen ist. Für Unternehmen, die gerade dabei sind, KI-Agenten Zugriff auf Firmenrechner oder Cloud-Umgebungen zu geben, ist das mehr als eine technische Randnotiz – es ist ein konkretes, dokumentiertes Beispiel dafür, was schiefgehen kann, wenn "die Sandbox schützt uns schon" die einzige Sicherheitsstrategie ist.

Was ist passiert: Der SharedRoot-Sandbox-Ausbruch bei Claude Cowork

Claude Cowork ist Anthropics Werkzeug für autonome Multi-Schritt-Aufgaben auf dem eigenen Rechner: Man verbindet einen Ordner, gibt eine Aufgabe vor, und der Agent arbeitet eigenständig darin – Dateien lesen, Dokumente erstellen, Recherchen zusammenführen. Damit der Agent dabei nicht versehentlich das gesamte System verändert, läuft er in der lokalen Ausführungsart auf macOS in einer isolierten Linux-VM. Genau diese Isolation stand im Zentrum des Berichts von Accomplish AI.

Das Problem: Die Linux-VM-Sandbox teilt sich das Host-Dateisystem über ein beschreibbares VirtioFS-Mount. Diese Architekturentscheidung – praktisch für Performance und nahtlosen Dateizugriff, aber riskant für die Isolation – bildete den Ausgangspunkt für den Ausbruch. Oren Yomtov, Principal Security Researcher bei Accomplish AI, schildert den Vorgang laut Berichterstattung so: Man habe einen Ordner mit einer frisch gestarteten Cowork-Session verbunden, eine kurze, präparierte Nachricht gesendet – und dabei live beobachtet, wie der Agent aus der eigentlich isolierten Sandbox ausbrach.

Genau dieses Szenario – ein Ordner wird geteilt, eine Aufgabe formuliert, der Agent legt los – ist kein Sonderfall, sondern der ganz normale Alltag mit einem Werkzeug wie Cowork. Niemand, der einen solchen Agenten einrichtet, rechnet damit, dass die erste Nachricht in der Session bereits genügt, um die eigentlich vorgesehene Grenze zwischen "Agent darf hier arbeiten" und "Agent hat Zugriff auf den gesamten Rechner" aufzulösen. Genau diese Erwartungshaltung – dass die Sandbox unsichtbar im Hintergrund für Sicherheit sorgt, ohne dass man selbst etwas dafür tun muss – ist es, die der SharedRoot-Bericht infrage stellt.

Laut Accomplish AI genügte eine einzige Nachricht in einer neu verbundenen Cowork-Session mit geteiltem Ordner, um den Agenten aus der Sandbox ausbrechen zu lassen – ohne zusätzlichen Klick, ohne Permission-Prompt, ohne dass der Nutzer selbst aktiv etwas freigeben musste.

Keine mehrstufige Angriffskette, kein Social Engineering, kein Umgehen von Bestätigungsdialogen. Eine präparierte Nachricht in einer neuen Session mit geteiltem Ordner genügte, um den Agenten aus der eigentlich isolierten VM heraus auf das komplette Host-System zugreifen zu lassen. Für Geschäftsführer und IT-Verantwortliche, die "Sandbox" bislang als Synonym für "sicher genug" behandelt haben, ist das eine wichtige Korrektur: Eine Sandbox ist immer nur so stark wie ihre schwächste Schnittstelle zum Host-System – und ein beschreibbares, geteiltes Dateisystem ist eine sehr breite Schnittstelle.

Die Technik dahinter: CVE-2026-46331 und die "pedit COW"-Schwachstelle

Technisch nutzt der SharedRoot-Exploit eine Schwachstelle im Linux-Kernel selbst, die unter der Kennung CVE-2026-46331 registriert ist und im Sicherheitsjargon "pedit COW" genannt wird. Sie sitzt im act_pedit-Subsystem der Traffic-Control-Komponente des Kernels – einem Teil, der eigentlich für die Verarbeitung von Netzwerkpaketen zuständig ist, nicht für Dateisystemzugriffe.

Der Fehler liegt darin, dass der Kernel den beschreibbaren Copy-on-Write-Bereich berechnet, bevor der tatsächliche Schreib-Offset feststeht. Dieses Timing-Problem erlaubt es, Page-Cache-Daten gezielt zu korrumpieren. In der Praxis bedeutet das: Ein unprivilegierter Nutzer innerhalb der Gast-VM kann sich Root-Rechte verschaffen – etwa, indem er ein gecachtes Setuid-Binary wie /bin/su vergiftet. Besonders unangenehm für Verteidiger: Der Angriff hinterlässt laut Accomplish AI keine Spuren, die klassische Integritätsprüfungen erkennen würden.

CVE-2026-46331 erreicht einen CVSS-Score von 7,8 von 10 – als "hoch" eingestuft. Betroffen war ein breiter Bereich des Linux-Kernels, von Version 5.18 bis 7.1-rc6. Der eigentliche Kernel-Fix kam bereits Mitte Juni 2026, doch die von Cowork lokal genutzten VM-Images waren zum Zeitpunkt der Accomplish-Demonstration Ende Juli offenbar noch verwundbar – ein Detail, das zeigt, wie leicht ein bereits behobener Upstream-Fehler in nachgelagerten Produkten unbemerkt weiterlebt, wenn Basis-Images nicht zeitnah aktualisiert werden.

Für technisch nicht spezialisierte Entscheider klingt das zunächst nach Kernel-Innereien, die man getrost Sicherheitsteams überlassen kann. Der entscheidende Punkt liegt aber eine Ebene höher: Es brauchte keine kompromittierte Website, keinen Phishing-Link, keinen manipulierten Anhang von außen. Der Angriffsvektor war die normale, vorgesehene Interaktion mit dem Agenten – eine Nachricht in einem Chat-Fenster. Genau das macht Prompt-getriggerte Sandbox-Ausbrüche so schwer vorhersehbar: Die Grenze zwischen "normaler Nutzung" und "Angriff" verläuft nicht mehr am Netzwerkrand, sondern mitten im Gespräch mit dem Agenten selbst. Für ein Unternehmen bedeutet das: Klassische Perimeter-Sicherheit – Firewall, VPN, Netzwerksegmentierung – schützt hier wenig, weil der Angriff nicht von außen ins Netzwerk eindringt, sondern innerhalb der ganz normalen, vorgesehenen Nutzung des Werkzeugs stattfindet.

Die Tragweite: 500.000 Nutzer und die Frage nach dem "vollen Zugriff"

Nach dem Ausbruch aus der VM, so Accomplish AI, erhielt der Agent vollen Lese- und Schreibzugriff auf das gesamte Host-Nutzerkonto – nicht nur auf den ursprünglich freigegebenen Ordner. Das schließt potenziell SSH-Private-Keys und Cloud-Zugangsdaten mit ein. Wer sich vor Augen führt, was in einem typischen Nutzerverzeichnis eines Unternehmensrechners liegt – Konfigurationsdateien mit API-Tokens, gespeicherte Anmeldedaten in Browser-Profilen, lokale Kopien von Kundendaten, Zugangsschlüssel zu Cloud-Umgebungen –, versteht schnell, warum "voller Zugriff auf das Nutzerkonto" kein abstraktes Risiko ist, sondern ein sehr konkretes.

Man muss sich dafür kein Worst-Case-Szenario ausdenken, es ergibt sich fast von selbst: Ein SSH-Private-Key öffnet den Weg zu weiteren Servern, auf denen dieser Schlüssel hinterlegt ist – Produktivsysteme, Backup-Server, unter Umständen sogar Kundeninfrastruktur. Cloud-Zugangsdaten in Konfigurationsdateien erlauben unter Umständen den Zugriff auf ganze Speicherbereiche, Datenbanken oder Abrechnungskonten. Und lokal gespeicherte Browser-Sitzungsdaten können ausreichen, um sich in Firmen-E-Mail, CRM-Systeme oder Buchhaltungssoftware einzuloggen, ohne dass dafür überhaupt ein Passwort nötig wäre. Ein Sandbox-Ausbruch auf einem einzelnen Mitarbeiter-Laptop ist damit potenziell der erste Schritt zu einem viel größeren Vorfall – nicht, weil der Agent böswillig handelt, sondern weil er nach dem Ausbruch schlicht dieselben Rechte hat wie der Mensch, der am Rechner angemeldet ist.

Mehrere Fachmedien, darunter TheHackerNews, 9to5Mac, AppleInsider, TechRadar und CyberSecurityNews, berichteten übereinstimmend, dass vor der Behebung des Problems rund 500.000 macOS-Nutzer betroffen waren, die Cowork lokal ausführten. Diese Zahl stammt aus Sekundärberichterstattung unter Berufung auf Accomplish AI; eine offizielle, eigenständige Bestätigung durch Anthropic dazu liegt nach aktuellem Stand nicht vor. Selbst mit dieser Einschränkung zeigt die Größenordnung, dass es sich nicht um ein Nischenproblem für einzelne Power-User handelte, sondern um eine Konfiguration, die eine sehr breite Nutzerbasis betraf.

Wichtig für die Einordnung: Es handelt sich hierbei um einen von mehreren, klar zu unterscheidenden Cowork-Sicherheitsvorfällen aus dem Sommer 2026. Parallel dazu meldete die Firma Armadin eine separate Angriffskette gegen Cowork unter Windows – über eine Manipulation des CoworkVMService, das Aushebeln der Netzwerk-Domain-Allowlist und DLL-Sideloading gegen claude.exe und USERENV.dll. Anthropic bestritt hier die Relevanz mit dem Argument, dass für diesen Angriffsweg bereits lokale Codeausführung vorausgesetzt werde – ein Einwand, der in der Sicherheitsbranche nicht unumstritten ist, der aber technisch von SharedRoot klar zu trennen ist: unterschiedliche Plattform, unterschiedlicher Mechanismus, unterschiedliches Meldedatum. Wer beide Vorfälle in einer Meldung vermischt, verwässert die eigentliche Botschaft: Es gab im gleichen Zeitraum mehrere, unabhängig voneinander entdeckte strukturelle Schwachstellen in einem Produkt, das gezielt für autonome Aufgaben mit weitreichendem Systemzugriff entwickelt wurde.

Hinzu kommen weitere, ebenfalls unabhängig gemeldete Cowork-Schwachstellen aus derselben Phase: Innerhalb von 48 Stunden nach dem Cowork-Launch demonstrierten Forscher laut Branchenquellen wie explainx.ai, Palo Alto Networks und der Cloud Security Alliance einen Prompt-Injection-Angriff über ein Word-Dokument mit unsichtbarem Text, der Claude zum Hochladen von Finanzdokumenten mit Sozialversicherungsnummern verleitete. Separat erreichten gemeldete Desktop-Extension-Schwachstellen bei Cowork einen CVSS-Wert von 10 von 10 – die maximal mögliche Schwere. Das Bild, das sich daraus ergibt, ist kein einzelner Ausrutscher, sondern ein Muster: Ein neues Produkt mit weitreichenden Systemrechten wird in kurzer Zeit aus mehreren, technisch unabhängigen Richtungen auf die Probe gestellt – und besteht diese Probe nicht durchgehend.

Wie hat Anthropic reagiert – und was das über Anbieterabhängigkeit sagt

Berichten zufolge fiel die Reaktion auf entsprechende Cowork-Sicherheitsmeldungen aus dem Sommer 2026 insgesamt eher zurückhaltend aus: Meldungen wurden intern teils als "informativ" eingestuft, ohne dass jeweils ein dedizierter, öffentlich kommunizierter Sicherheitspatch für die konkret beschriebene Schwachstelle folgte. Welche dieser Einschätzungen sich exakt auf SharedRoot und welche sich auf den separaten Armadin-Vorfall bezieht, lässt sich aus der vorliegenden Sekundärberichterstattung nicht in jedem Detail eindeutig trennen – ein Umstand, der für sich genommen schon aufschlussreich ist: Wenn selbst Fachmedien mehrere Cowork-Sicherheitsmeldungen aus derselben Woche nicht immer sauber auseinanderhalten, wie soll ein Unternehmen, das Cowork produktiv einsetzen will, im Alltag die Übersicht behalten?

Eine mildernde Entwicklung gibt es dennoch: Bereits seit einem Update am 7. Juli 2026 führt Claude Cowork Sessions standardmäßig in der Cloud aus – Remote-Execution ist der neue Standard, nicht mehr die lokale VM auf dem Mac. Das entschärft den hier beschriebenen lokalen VM-Escape-Pfad für Nutzer, die mit den Standardeinstellungen arbeiten; Sessions laufen dabei sogar weiter, wenn der lokale Rechner offline ist. Ob diese Umstellung eine direkte Reaktion auf die SharedRoot-Offenlegung war oder aus anderen Gründen erfolgte, lässt sich aus der vorliegenden Berichterstattung nicht abschließend klären – sie liegt zeitlich sogar davor. Nutzer, die Cowork bewusst weiterhin lokal betreiben, etwa aus Datenschutz- oder Offline-Gründen, sollten laut Sicherheitsempfehlungen unter anderem unprivilegierte User-Namespaces deaktivieren, den Zugriff auf geteilte Dateisysteme einschränken und den Cowork-Daemon mit strikterer Mount-Sicherheit betreiben.

Für Mittelstandsunternehmen ergibt sich daraus eine unbequeme, aber wichtige Erkenntnis: Man kann sich nicht darauf verlassen, dass der Anbieter jede gemeldete Schwachstelle in der eigenen Priorisierung genauso hoch einstuft wie das eigene Unternehmen es tun würde. Was für einen KI-Anbieter mit Millionen Nutzern eine von vielen Meldungen in der Triage ist, kann für ein einzelnes Unternehmen mit sensiblen Kundendaten der Unterschied zwischen "normaler Betrieb" und "meldepflichtiger Sicherheitsvorfall" sein.

Der Compliance-Blindfleck und die politische Großwetterlage

Ein weiterer Aspekt verdient besondere Aufmerksamkeit für regulierte Branchen: Anthropic weist laut Fachpresse ausdrücklich darauf hin, dass Cowork-Aktivität nicht in Audit Logs, der Compliance API oder Data Exports erfasst wird. Konversationsverläufe werden lokal auf dem Gerät gespeichert, nicht in Anthropics zentraler Audit-Infrastruktur. Für ein Unternehmen aus der Finanzbranche, dem Gesundheitswesen oder generell mit DSGVO-relevanten Datenverarbeitungen bedeutet das: Selbst wenn der Agent korrekt und sicher arbeitet, fehlt der lückenlose, zentral auswertbare Nachweis darüber, was er wann mit welchen Daten getan hat. Im Kontext eines Sandbox-Ausbruchs wie SharedRoot verschärft sich das Problem zusätzlich – ein Vorfall, der lokal auf einem einzelnen Mitarbeiter-Laptop stattfindet, ist ohne zentrales Logging schwer nachträglich aufzuklären, geschweige denn in einer Audit-Prüfung lückenlos nachzuweisen.

Der Vorfall reiht sich zudem in eine Phase verstärkter regulatorischer Aufmerksamkeit für KI-Sicherheit ein. Am selben Tag, dem 23. Juli 2026, brachten die US-Abgeordneten Ted Lieu (Demokraten) und Nathaniel Moran (Republikaner) den "AI Kill Switch Act" ein. Der Gesetzentwurf würde dem Department of Homeland Security die Befugnis geben, als gefährlich eingestufte KI-Modelle abschalten zu lassen – mit Strafen von 20 Millionen US-Dollar pro Tag bei Nichtbefolgung. Auch wenn dieser Gesetzentwurf primär auf die US-Regulierung zielt und nicht direkt mit SharedRoot verknüpft ist, zeigt die zeitliche Nähe beider Meldungen ein größeres Muster: Autonome KI-Agenten mit weitreichenden Systemrechten geraten zunehmend in den Fokus von Sicherheitsforschern und Gesetzgebern gleichermaßen. Wer heute Agenten mit Zugriff auf Firmensysteme ausrollt, baut auf einem regulatorischen Fundament, das sich in den kommenden Monaten spürbar bewegen dürfte – auch mit Blick auf den EU AI Act, der von Unternehmen zunehmend Nachweis- und Kontrollfähigkeiten für eingesetzte KI-Systeme verlangt.

Was das für Ihre KI-Agenten-Strategie im Mittelstand bedeutet

Der SharedRoot-Vorfall ist ein Weckruf, aber kein Grund, KI-Agenten grundsätzlich zu verteufeln. Er zeigt vielmehr sehr konkret, was "volle Sandbox-Isolation" in der Praxis bedeuten kann und wo die Grenzen von General-Purpose-Desktop-Agenten liegen, die für eine Vielzahl beliebiger Aufgaben auf einem Rechner mit breiten Rechten laufen sollen. Für Unternehmen mit sensiblen Daten – Kundendaten, Zugangsdaten, geistiges Eigentum – ist ein solcher Ansatz strukturell riskanter als ein eng gescopter, für einen konkreten Zweck gebauter Agent mit geprüften, minimalen Berechtigungen.

Das zentrale Prinzip dahinter ist Least Privilege: Ein Agent sollte nur genau die Rechte bekommen, die er für seine konkrete Aufgabe braucht – und nicht "vorsorglich" Vollzugriff auf Dateisystem, SSH-Schlüssel oder Cloud-Zugangsdaten, nur weil es bequemer ist, ihn einmal breit einzurichten und dann nicht mehr darüber nachzudenken. Ein Agent, der Rechnungen aus einem definierten Ordner verarbeitet, braucht keinen Zugriff auf das gesamte Nutzerkonto. Ein Agent, der Kundenanfragen beantwortet, braucht keinen Schreibzugriff auf Systemdateien. Diese Trennung mag im Alltag etwas mehr Einrichtungsaufwand bedeuten – sie ist aber genau der Unterschied zwischen einem Vorfall, der auf einen Ordner begrenzt bleibt, und einem Vorfall, der das gesamte Unternehmensnetzwerk kompromittiert.

Aus dem Vorfall lässt sich eine praktische Checkliste für Geschäftsführer und IT-Verantwortliche ableiten, bevor ein KI-Agent produktiv geschaltet wird. Erstens: Welche Dateien und Systeme braucht der Agent tatsächlich, um seine Aufgabe zu erfüllen – und wo lässt sich dieser Zugriff technisch hart begrenzen, statt ihn nur organisatorisch zu vereinbaren? Zweitens: Läuft der Agent isoliert, idealerweise in einer Cloud-Umgebung statt in einer lokalen VM auf einem Mitarbeiter-Rechner, wo geteilte Dateisysteme zusätzliche Angriffsflächen schaffen? Drittens: Gibt es ein Monitoring beziehungsweise einen Audit-Trail für Agenten-Aktionen, der auch dann etwas dokumentiert, wenn der Agent selbst kompromittiert wurde? Viertens: Wer im Unternehmen verantwortet die Freigabe eines Agenten vor dem Go-Live, und wird diese Freigabe regelmäßig überprüft, wenn sich die zugrunde liegende Software ändert? Fünftens: Gibt es einen Notfallplan – einen tatsächlichen Kill-Switch –, falls ein Agent unerwartetes Verhalten zeigt, und ist dieser Plan getestet, nicht nur dokumentiert?

Genau hier liegt auch die Einordnung, dass Anthropic entsprechende Meldungen zurückhaltend behandelt haben soll, statt umgehend einen dedizierten Patch zu veröffentlichen: Unternehmen können sich nicht allein auf den Anbieter verlassen, sondern müssen eigene Sicherheitsprüfungen und Architekturentscheidungen zu Scope, Isolation und Monitoring treffen, bevor ein Agent produktiv eingesetzt wird. Das ist keine Absage an fertige KI-Tools an sich, sondern eine Aufforderung, sie nicht unreflektiert mit breitem System- oder Dateizugriff einzukaufen und dann laufen zu lassen.

Amazing Agents positioniert sich genau an dieser Stelle: als Partner, der Agenten von Anfang an mit engem Aufgaben-Scope, einer geprüften und gehärteten Ausführungsumgebung sowie einem dokumentierten Rechte-Konzept baut – statt vorgefertigte General-Purpose-Werkzeuge unreflektiert mit weitreichenden Rechten auszustatten. Ob es um einen Agenten für die Rechnungsprüfung, die Mandantenkommunikation einer Steuerkanzlei oder die Schadenbearbeitung eines Versicherungsmaklers geht: Die Frage ist nie "Wie geben wir dem Agenten möglichst viel Zugriff, damit er möglichst flexibel ist?", sondern "Was braucht dieser Agent für genau diese Aufgabe – und wie stellen wir sicher, dass er nicht mehr kann?"

Der SharedRoot-Vorfall wird nicht der letzte seiner Art sein. Autonome Agenten mit Systemzugriff sind ein junges, sich schnell entwickelndes Feld, und wo neue Fähigkeiten entstehen, entstehen zwangsläufig auch neue Angriffsflächen. Unternehmen, die das ernst nehmen, warten nicht darauf, dass ein Anbieter jede Schwachstelle von sich aus behebt. Sie bauen ihre Agenten-Strategie von Anfang an so, dass ein einzelner Vorfall – eine einzige Nachricht in einer Session – eben nicht automatisch vollen Zugriff auf das gesamte Unternehmen bedeutet.