Kategorie: KI-News

Ein Coding-Agent installiert Abhängigkeiten, öffnet Netzwerkverbindungen, greift auf Zugangsdaten zu und arbeitet weiter, wenn sein Auftraggeber längst in einem anderen Projekt steckt. Sobald ein Programm solche Vollmachten bekommt, ist es kein Werkzeug mehr, das geduldig auf Eingaben wartet, sondern ein Akteur, der Entscheidungen trifft und in seiner Umgebung handelt.

Auf der Konferenz WeAreDevelopers North America hat Docker-Präsident Mark Cavage in rund dreißig Minuten gezeigt, wie sich diese Vollmachten einfangen lassen. Sein Vortrag liefert keine Zukunftsvision, sondern drei Bausteine: eine harte Grenze um jeden Agenten, eine reproduzierbare Beschreibung seiner Rechte und die Möglichkeit, dieselbe Umgebung vom Laptop in die Cloud zu verschieben. Wer heute überlegt, wie viel Vertrauen ein autonomer Agent bekommen soll, findet dort ein Modell, das die Frage nicht mit guten Vorsätzen beantwortet, sondern mit Architektur. Als Bild dafür dient eine Werkstatt, die man einem Handwerker übergibt – samt Werkzeug, Material und einem Schlüsselbund, dessen Umfang der Auftraggeber festlegt, nicht der Handwerker selbst.

Eine Einordnung vorab: Grundlage ist eine Zusammenfassung der Keynote im Docker-Firmenblog, geschrieben vom Produktmarketing. Alle Leistungsversprechen stammen also vom Anbieter selbst, unabhängige Tests der Sandboxes liegen bislang nicht vor.

Warum Container für Agenten zu klein geworden sind

Container wurden gebaut, um Anwendungen voneinander zu trennen. Eine Datenbank soll nicht in die Dateien der Webanwendung greifen, ein Build-Prozess nicht die Umgebungsvariablen eines anderen Dienstes sehen. Das funktioniert seit Jahren zuverlässig, auch bei Agenten – nur nicht weit genug. Ein Agent läuft nicht einfach, er handelt: Er entscheidet selbst, welches Paket er installiert, welche Schnittstelle er aufruft und welches Werkzeug er als nächstes benutzt. Damit verschiebt sich die Grenze, die man ziehen muss, von der Anwendung auf die gesamte Umgebung, die der Agent erreichen kann.

Cavage hat diesen Punkt in einer Live-Demonstration sichtbar gemacht. Der Container verhielt sich exakt so, wie er konstruiert war; das Problem lag nicht an einem Fehler in der Isolation, sondern daran, dass der Agent über die Grenzen hinausgriff, die für ein klassisches Programm ausreichen. In der Werkstatt-Analogie ist ein Container ein abschließbarer Raum, in dem ein einzelnes Gerät steht. Ein Agent dagegen ist der Handwerker, der durch die Werkstatt läuft, Schubladen öffnet und selbst entscheidet, welche Maschine er anwirft. Wer ihn einsperren will, muss nicht das Gerät sichern, sondern die ganze Halle – inklusive Stromkreis, Schlüsselbund und Zugang zur Straße.

Docker Sandboxes: eine eigene Maschine pro Agent

Diese Halle liefern die Docker Sandboxes. Jeder Agent bekommt seine eigene isolierte MicroVM mit eigenem Kernel, getrennt von der Umgebung des Entwicklers auf dem Hostsystem. Innerhalb dieser Maschine darf der Agent arbeiten, ausprobieren und scheitern, ohne dass ein Fehler bis auf den Laptop oder die Firmeninfrastruktur durchschlägt. Der Entwickler wählt, welchen Agenten, welches Modell und welche Werkzeuge der Auftrag braucht – die Sandbox schreibt keinen Anbieter vor, sondern nur den Rahmen.

Innerhalb dieses Rahmens gelten klare Regeln. Der Zugriff auf Dateien, Netzwerke und Geheimnisse wie API-Schlüssel wird explizit definiert, und diese Richtlinien liegen außerhalb der Reichweite des Agenten. Er kann sie nicht umschreiben, nicht erweitern und nicht versehentlich aushebeln. Erst das Zusammenspiel aus isolierter Maschine und extern verwalteter Policy macht autonome Arbeit verantwortbar. Die Docker Sandboxes sind schon heute über eine kostenlose, eigenständige CLI verfügbar, mit der du bestehende Agenten-Workflows isoliert ausführen kannst, ohne deine Arbeitsweise umzukrempeln.

Docker Sandbox Kits machen Berechtigungen reproduzierbar

Eine starke Grenze schützt, sagt aber noch nichts darüber aus, was innerhalb der Grenze passieren soll. Wer einen Agenten in einem Team betreibt, braucht eine wiederholbare Antwort auf zwei Fragen: Was läuft hier, und worauf darf es zugreifen? Dafür hat Cavage die nächste Generation der Docker Sandbox Kits angekündigt, die jetzt als gewöhnliche OCI-Images gebaut werden. Ein Kit bündelt den Agenten, seine Werkzeuge und die Regeln für seine Reichweite in einem einzigen versionierten Artefakt.

Die Bündelung ist der unscheinbarste Teil der Ankündigung, und der wichtigste. Kits lassen sich über dieselben Arbeitsabläufe teilen, die du schon für Container-Images benutzt, und jede Änderung an den Vollmachten eines Agenten wird dadurch sichtbar und prüfbar. Man muss nicht mehr rekonstruieren, welcher Kollege welchen Schlüssel wann in welcher Konfiguration hinterlegt hat, weil die Antwort im Artefakt selbst steckt. Docker bringt es so auf den Punkt: Dockerfiles machten Software reproduzierbar, Kits machen jetzt die Vollmachten reproduzierbar. Docker hat angekündigt, die Spezifikation unter neutrale Governance zu stellen und das Ökosystem zum Mitschreiben einzuladen.

Docker Cloud Sandboxes: vom Laptop in die Cloud

Manche Agentenaufträge beginnen und enden auf dem Entwickler-Laptop: ein Refactoring, ein Testlauf, eine Analyse. Andere brauchen Ausdauer oder Parallelität und laufen weiter, wenn der Entwickler den Rechner zuklappt und nach Hause geht. Für diesen Fall hat Docker die Cloud Sandboxes vorgestellt, die dieselbe microVM-basierte Isolation von der lokalen Maschine auf verwaltete Compute-Kapazität übertragen. Der Unterschied liegt nicht im Sicherheitsmodell, sondern im Ort, an dem es ausgeführt wird.

Der Ablauf bleibt vertraut. Mit dem bekannten sbx-Workflow startest du lokal, verschiebst die Arbeit mit einem Befehl in die Cloud und lässt sie dort weiterlaufen; bei Bedarf auch mehrere Aufgaben gleichzeitig, ohne selbst Infrastruktur zu provisionieren oder zu pflegen. Abgerechnet wird nach Verbrauch. Wichtiger als die Bequemlichkeit ist die Kontinuität: Die Vertrauensentscheidung, die du lokal getroffen hast, gilt in der Cloud unverändert weiter, weil es dieselbe Technik mit denselben Policies ist. Es ist kein Umzug, sondern ein durchgereichtes Sicherheitsmodell.

Offene Standards und Partner im Ökosystem

Ein offenes Agenten-Ökosystem braucht zwei Dinge gleichzeitig: Auswahl für Entwickler und gemeinsame Formate, auf die sich die Branche verlassen kann. Beides war auf der Bühne zu sehen. Nous Research zeigte Hermes als Kit in Docker Sandboxes – ein Agent eines Drittanbieters, verpackt für eine gemeinsame Umgebung, während Docker die darunterliegende Isolation und Kontrolle liefert. Du kannst also den Agenten wählen, der zu deiner Aufgabe passt, ohne die vertrauenswürdige Ausführungsschicht jedes Mal neu zu bauen.

Die zweite Hälfte betrifft den Standard selbst. Docker hat zugesagt, die Kits-Spezifikation an die Cloud Native Computing Foundation zu übergeben, jene herstellerneutrale Heimat für cloudnative Software. Chris Aniszczyk, CTO der CNCF, lobt das in einer Stellungnahme: Kaum ein Unternehmen verstehe so gut wie Docker, dass Standards ein Ökosystem schnell wachsen lassen, ohne es zu zersplittern; mit Kits als Standard-OCI-Images bekomme die Branche einen offenen, wiederholbaren Weg, einen KI-Agenten samt Werkzeugen und Leitplanken als ein Artefakt zu verpacken. Der Hinweis auf OCI ist mehr als ein Detail: Wer auf einem Standard aufsetzt, der die gesamte Cloud-Native-Welt trägt, erreicht diese Welt mit einem Schritt statt mit Dutzenden von Einzelintegrationen.

Vertrauen entsteht aus dem System um den Agenten

Zusammengenommen ergeben die Ankündigungen kein Sortiment, sondern ein System, das sich gegenseitig stützt. Sandboxes liefern eine deterministische Grenze, Kits machen Umgebung und Berechtigungen reproduzierbar, Cloud Sandboxes dehnen dasselbe Vertrauensmodell auf dauerhafte Kapazität aus. Das Ergebnis ist mehr Freiheit für den Agenten bei gleichbleibender Kontrolle darüber, was er anfassen und verändern darf. In der Werkstatt bleibt der Handwerker frei in seiner Arbeit, während der Auftraggeber weiterhin bestimmt, welche Türen sein Schlüssel öffnet.

Daraus folgt eine einfache Konsequenz: Vertrauen in autonome KI-Agenten ist kein Gefühl, das man dem Modell entgegenbringt, sondern eine Eigenschaft der Umgebung, in der es läuft. Solange diese Umgebung nicht definiert ist, bleibt jede Freigabe ein Glücksspiel, egal wie überzeugend die Zwischenergebnisse aussehen. Docker Sandboxes verhindern deshalb keine Fehler – sie sorgen dafür, dass ein Fehler einen begrenzten Raum hat, einen nachvollziehbaren Ursprung und eine Grenze, die der Agent nicht selbst verschieben kann. Wer heute mit der CLI startet, kann diesen Unterschied im eigenen Workflow ausprobieren, statt ihn theoretisch zu diskutieren.

Für Teams, die Agenten in größerem Maßstab einsetzen wollen, verschiebt sich damit die eigentliche Arbeit. Nicht das Modell ist die knappe Ressource, sondern die Frage, wie sich Rechte sauber beschreiben, versionieren und überprüfen lassen. Wer das löst, kann Agenten laufen lassen, ohne bei jedem Schritt mitzählen zu müssen. Wer es nicht löst, wird früher oder später eine Grenze ziehen, die zu spät kommt.

Quelle: docker.com

Im Januar bestellte Nat Friedman Hunderte Mac minis für sein Team, nachdem er OpenClaw selbst ausprobiert hatte. Die Zahl stammt nicht aus einer Pressemitteilung, sondern aus einem Beitrag auf X. Friedman leitet heute das Produkt bei Metas Superintelligence Labs (MSL), und dort hat er etwas eingeräumt, das in der KI-Branche selten so offen gesagt wird: Muse, Metas neuer KI-Assistent, sei als Produkt „definitely heavily inspired“ von OpenClaw. Wer in den letzten Wochen durch Foren und Feeds gestreift ist, wird das nicht überraschend finden. Interessanter als die Pointe ist die Begründung – und was sie über den Zustand der Branche verrät.

Eine Analogie hilft: OpenClaw ist ein offenes Rezept. Jeder kann hineinschauen, es nachkochen, verändern oder weitergeben. Meta ist eine Großküche, die daraus ein Gericht für Milliarden Menschen machen will – einheitliche Qualität, geprüfte Zutatenliste, eine Verteilung, die kein Restaurant der Welt erreicht. Diese Großküche hat jetzt zugegeben, dass das eigene Gericht nicht am eigenen Herd erfunden wurde.

Was Nat Friedman auf X geschrieben hat

Friedman war CEO von GitHub, bevor er zu Meta kam, wo er im vergangenen Jahr neben Metas Chief AI Officer Alexandr Wang anfing. Sein Beitrag auf X besteht aus zwei Hälften, und die Teilung ist der Punkt. Einerseits: „We built Muse from scratch“ – Muse sei von Grund auf neu gebaut. Andererseits: Muse sei „definitely heavily inspired as a product by OpenClaw“. Technisch ein eigenes Werk, produktseitig erkennbar an einer Vorlage orientiert.

Ob die Unterscheidung juristisch sauber klingen soll oder inhaltlich trägt, lässt sich von außen schwer beurteilen. Friedman liefert den Kontext gleich mit: Nachdem er OpenClaw im Januar ausprobiert hatte, kaufte er Hunderte Mac minis für das MSL-Team – und viele dort hätten sich in OpenClaw und andere persönliche Agenten verliebt. Sein erklärtes Ziel mit Muse: etwas wie OpenClaw zu bauen, das sicher, leicht zu bedienen und auf Milliarden Nutzer skalierbar ist.

Skalierung ist der entscheidende Punkt. Ein offenes Projekt für technisch versierte Nutzer zu betreiben ist etwas anderes, als dieselbe Mechanik in einer App auszuliefern, die ein Teenager ohne Anleitung installiert. Friedman benennt diesen Unterschied, und er ist nicht trivial.

Wie die Sache ins Rollen kam

Ausgelöst hat die Debatte nicht Meta, sondern ein Beitrag, der unter KI-Enthusiasten viral ging. Ansh Nanda, Mitgründer einer KI-App, schrieb dort: „Muse is LITERALLY OpenClaw for normies.“ Also: Muse ist OpenClaw für Normalsterbliche. Zugespitzt, aber viele Leser hatten denselben Verdacht.

Der Beleg in Nandas Beitrag war ungewöhnlich: ein Gespräch mit Muse selbst. Darin antwortete der Assistent, die Ähnlichkeit zwischen seinen Systemdateien und denen von OpenClaw sei nicht „a coincidence“, sondern „a match“. Der Agent hat auf die Frage nach dem Rezept also mit „dasselbe“ geantwortet.

Selbstauskünfte eines Sprachmodells sind mit Vorsicht zu behandeln. Modelle behaupten viel, wenn der Kontext es nahelegt, und sie spüren genau, welche Antwort erwartet wird. Hier kam kurz darauf Bestätigung von der Quelle selbst, die sich nicht als Halluzination abtun lässt. Der Stein kam durch einen Nutzer ins Rollen, nicht durch Recherche und nicht durch ein Leak.

SOUL.md oder: Warum eine einzelne Textdatei so viel verrät

Kurz nach Nandas Beitrag meldeten sich weitere Nutzer mit Fundstücken. Einer wies darauf hin, dass Muse ebenfalls eine Datei namens SOUL.md besitzt. Wer noch nie mit einem persönlichen KI-Assistenten gearbeitet hat, mag darüber hinweggehen, doch die Datei ist wichtig. Eine SOUL.md ist eine Textdatei in Markdown – ein schlichtes Format für Überschriften, Listen und Hervorhebungen mit normalen Zeichen. Ihr Inhalt: die Persönlichkeit des Agenten.

In so einer Datei steht, wie der Assistent spricht, welchen Ton er anschlägt, welche Werte ihm wichtig sind, wo seine Grenzen liegen und wofür er sich zuständig fühlt. Sie funktioniert wie die Gewürzmischung eines Gerichts. Zwei Gerichte mögen dieselben Zutaten haben – erst die Mischung entscheidet, ob daraus etwas Eigenes wird oder eine Kopie.

Ein dritter Nutzer stellte fest, dass nicht nur die Dateinamen zwischen beiden Assistenten übereinstimmten, sondern auch die Inhalte – „nearly identical“. Dateinamen sind Konvention. Inhalte sind Substanz.

Friedman wurde auf X gefragt, warum Muse die exakten Dateinamen übernommen hat und warum der Inhalt der SOUL.md fast gleich ist. Er widersprach nicht. Er schrieb, man sei der Meinung gewesen, dass Peter – Peter Steinberger, der Schöpfer von OpenClaw, im Netz als @steipete – „got those things exactly right“. Wer so antwortet, verteidigt sich nicht. Er erklärt eine Design-Entscheidung.

Das Meta-Playbook: beobachten, übernehmen, verteilen

So viel Offenheit überrascht, die Strategie dahinter ist altbekannt. Meta übernimmt seit Jahren erfolgreiche Formate und gewinnt dann über die eigene Reichweite. Das berühmteste Beispiel ist Stories: Snapchat hat die Funktion erfunden, kurz darauf tauchte sie in Instagram auf – keine Kopie im juristischen Sinne, aber eine Antwort mit größerem Publikum. Wer diesen Mechanismus kennt, wird bei Muse nicht überrascht sein.

OpenClaw war so erfolgreich, dass OpenAI den Schöpfer des Projekts Anfang dieses Jahres abwarb. Nun bringt Meta einen Assistenten auf den Markt, der sich erkennbar an derselben Vorlage orientiert. Um ein einziges Open-Source-Projekt herum haben sich zwei der größten Labore der Welt positioniert.

Das ist grundsätzlich legitim. Open Source heißt, dass man den Code lesen, verwenden und weiterentwickeln darf. Ob das auch die fast wortgleiche SOUL.md deckt, hängt an der Lizenz; dazu äußern sich weder Meta noch der Bericht. Kulturell bleibt eine Frage offen: Wenn ein Produkt seine Existenz der Offenheit anderer verdankt, was wird zurückgegeben? Ein Lob in einem X-Beitrag ist ein Anfang, aber keine Antwort.

Platz 1 im US-App-Store

Unabhängig von der Herkunftsfrage läuft Muse gut. Die App hat kürzlich Platz 1 im US-App-Store erreicht, und Daten deuten darauf hin, dass sie den Start von ChatGPT übertrifft, wenn man Plattformen und Marktverfügbarkeit direkt vergleicht. Ein Meta-Sprecher verwies auf Anfrage auf Friedmans Aussage und hatte nichts hinzuzufügen.

Das als Beweis für Produktqualität zu lesen greift zu kurz. Der Vorteil liegt in der Verteilung: Meta muss niemanden davon überzeugen, eine App zu installieren, deren Existenz Millionen ohnehin im Blick haben. Ein hervorragendes Werkzeug, das man erst suchen muss, verliert gegen ein gutes, das einfach da ist. Darum ging es bei „scale to billions“.

Für Nutzer ist das nicht automatisch schlecht. Ein Assistent, der funktioniert wie OpenClaw, aber weniger Einrichtung verlangt, ist nützlich. Offen bleibt, welche Zugeständnisse mit der Einfachheit einhergehen – bei Sicherheit, Anpassbarkeit und der Frage, wem die Gespräche gehören.

Was das für Open Source und Nutzer bedeutet

Der Fall ist kein Skandal. Offene Projekte liefern heute die Ideen, aus denen große Plattformen ihre Produkte formen – früher war das die Rolle der Forschungslabore. Wer etwas Offenes baut, sollte damit rechnen, dass ein finanzstarkes Unternehmen vorbeikommt und fragt, ob es das auch in groß haben kann. Das ist der Preis dafür, dass Offenheit die Stärke dieses Ökosystems ist.

Der Assistent auf dem eigenen Telefon wird künftig von Konzepten geprägt sein, die in kleinen Community-Projekten entstanden sind. Davon erfahren wir meist nur, wenn jemand so genau hinschaut wie Ansh Nanda. Dass Meta die Nähe zugibt, statt sie abzustreiten, ist immerhin etwas. Es zeigt, dass die Werkzeuge der offenen Szene gut genug sind, um den Maßstab für Milliardenprodukte zu setzen.

Quelle: techcrunch.com

Nummer 172 ist eine Enigma-Nachricht, die auf der Website von Crypto Cellar Research als ungebrochen geführt wurde. Bruce Schneier machte sie in seinem Blog zum Ausgangspunkt eines Beitrags, den er mit „ziemlich erstaunlich“ einleitet. Am 22. September 2026 zitierte er einen Bericht von Crypto Cellar Research, wonach ein Sprachmodell namens GPT-6 Astra die Nachricht entschlüsselt hat – und zwar, das hebt der Bericht als das Erstaunlichste hervor, vollständig selbstständig.

Was auf der Liste der ungebrochenen Nachrichten stand

Carter Leffer, der das Experiment durchführte, wies GPT-6 Astra an, zu prüfen, ob es eine der ungebrochenen Enigma-Nachrichten auf der Website von Crypto Cellar Research knacken könne. Das Modell sah sich die Liste an und entschied, dass Nummer 172 mit der Kennung MVUEH die aussichtsreichste Kandidatin sei. Außerdem vermutete es früh, dass Nummer 173 mit der Kennung SIPVX inhaltlich mit MVUEH zusammenhängen könnte. Diese Vermutung setzt eine Arbeitsweise voraus, die über reines Durchprobieren hinausgeht.

Warum eine kurze Nachricht leichter zu brechen sein kann als eine lange? Nicht wegen der Länge, sondern weil sich im Text womöglich ein bekanntes oder erratbares Klartextstück findet. GPT-6 Astra probierte laut dem Bericht viele Ansätze aus, bevor es sich auf einen konzentrierte. Erst breit suchen, dann gezielt eingrenzen — das unterscheidet Kryptanalyse von blindem Raten.

Der wiederholte Ortsname ROSENOW als Crib

Der Durchbruch kam über einen Crib. So nennt man in der Kryptanalyse ein Stück Klartext, von dem man mit hoher Wahrscheinlichkeit weiß, dass es in der Nachricht vorkommt. Man kann sich das vorstellen wie ein Kreuzworträtsel mit fast leeren Feldern, in das ein einziges Wort schon eingetragen ist — dieses Wort verrät die Struktur des Gitters. Für MVUEH wählte GPT-6 Astra den wiederholten Ortsnamen ROSENOW ROSENOW als Crib. Dass ein Ortsname doppelt auftaucht, hilft, weil die Wiederholung zusätzliche Prüfpunkte liefert.

Mit diesem Crib begann das Modell den Bruch. Ziel war nicht, eine Buchstabenfolge zu raten, sondern die Walzenstellung und die Steckerverbindungen zu finden, unter denen der Crib an der richtigen Stelle im Geheimtext erscheint. Das leistet die Enigma-Bombe: Sie prüft viele Kombinationen und schließt falsche Kandidaten aus. Am Ende standen der Schlüssel und der Klartext von MVUEH. Die Wahl des Cribs war kein Zufallstreffer, sondern eine Hypothese, die sich bestätigt hat.

Eine KI, die sich Enigma-Simulator und Bombe selbst baut

Der ungewöhnlichste Teil des Berichts betrifft die Werkzeuge. GPT-6 Astra entwickelte laut dem Bericht die nötige Software selbst: einen Enigma-Simulator und eine Enigma-Bombe, in Python und C++. Das Modell hat nicht geraten, sondern sich das Instrumentarium gebaut, mit dem ein solcher Bruch überhaupt möglich ist. Dass eine Maschine eine Maschine nachbaut, die Menschen einst gegen eine andere Maschine konstruierten, hat eine eigene Ironie.

Die Bombe ist kein Zufallsgenerator, sondern ein Ausschlussverfahren. Sie nutzt logische Widersprüche, um falsche Schlüsselkandidaten zu verwerfen, und geht davon aus, dass ein bestimmter Crib im Text vorkommt. Wer an Bletchley Park denkt, kommt an Alan Turing und Gordon Welchman nicht vorbei, die diese Methode im Zweiten Weltkrieg entwickelten. Ein Kommentator auf Schneiers Blog schrieb, die Vorstellung, dass ein Modell heute selbst eine Bombe baut, rufe die Arbeit jener Jahrzehnte zurück, in denen polnische Vorarbeiten und später britische Maschinen den Weg bereiteten.

Bundesarchiv-Dateien und die offene Frage nach den Logs

Unklar bleibt, wie GPT-6 Astra an bestimmte Quellen gelangte. Ein Kommentator unter Schneiers Beitrag zitiert aus dem Bericht: Die Dateiverweise des Modells sind korrekt, die Dateien aber nicht auf der Website von Crypto Cellar Research verfügbar. Die Rede ist von einer Privatsammlung, und es bleibt offen, ob das Modell auf die digitalisierten Bestände des Bundesarchivs zugegriffen hat. Die Signaturen lauten RS 3-3/20a und RS 3-3/63b — Primärquellen, wie Historiker sagen würden. Ihre Verwendung wäre für eine KI ein bemerkenswerter Schritt.

Frode Weierud, eng mit Crypto Cellar Research verbunden, äußerte sich in den Kommentaren zurückhaltend. Er bezweifelt, dass die Bundesarchiv-Dateien für den MVUEH-Bruch entscheidend waren, findet aber interessant, wie weit GPT-6 bei Primärquellen gegangen ist. Er räumt ein, nicht über alle Logs zu verfügen; nur Carter Leffer habe die vollständigen Aufzeichnungen. Möglich sei, dass sich das Modell mit einem Forscherkonto Zugang zum Bundesarchiv verschafft habe — sicher ist das nicht. Hier liegt die offene Frage des Falls.

Claude Opus 5 und die 63 Buchstaben vom 31. Juli 1941

Der Bruch von MVUEH blieb nicht folgenlos. Laut Weierud inspirierte er einen weiteren Angriff auf eine der ungebrochenen Nachrichten. Am 20. September 2026 wurde die 63 Buchstaben lange Nachricht Nr. 205 NF, auch als Nr. 285 FMNGI geführt, vom 31. Juli 1941 entschlüsselt — mit Unterstützung von Anthropic Claude Opus 5. Auch hier half ein Crib, diesmal XHARTJENSTEINX, eine sehr häufige Signatur. Wieder war es ein bekanntes Klartextstück, das den Weg durch den Schlüsselraum bahnte.

Auffällig ist die Arbeitsteilung. Bei MVUEH lieferte GPT-6 Astra den ganzen Ablauf von der Auswahl der Nachricht bis zur Bombe; bei der 63-Buchstaben-Nachricht half Claude Opus 5. Beide Fälle zeigen dasselbe Muster: Die KI ersetzt den Crib nicht, sie beschleunigt die Arbeit darum herum. Wer glaubt, eine KI könne Enigma ohne jede Klartextannahme brechen, unterschätzt die Mathematik dahinter.

Was der Doppelbruch für Kryptanalyse und Geschichtsschreibung bedeutet

Die Nachrichten von Crypto Cellar Research sind kein Zufallskorpus. Sie wurden über Jahre zusammengetragen, geprüft und als ungebrochen veröffentlicht — ein Archiv, das gerade deshalb taugt, weil es dokumentiert, was bislang nicht gelang. Dass innerhalb weniger Tage zwei dieser Nachrichten fielen, sagt weniger über einen plötzlichen KI-Durchbruch als über die Reife der Werkzeuge. Modelle können Code schreiben, Hypothesen ordnen und Ergebnisse gegen Quellen prüfen. Das ähnelt klassischer Kryptanalyse, nur schneller und ausdauernder.

Für die historische Kryptographie ist das eine gute Nachricht, solange die Ergebnisse überprüfbar bleiben. Ein entschlüsselter Text, der sich gegen Primärquellen wie Schiffslogbücher oder Archivbestände halten lässt, gewinnt an Gewicht. Ein Kommentator verweist auf ein verwandtes Beispiel, über das Tom’s Hardware berichtet: GPT-6 Astra knackte einen 108 Jahre alten deutschen Funkspruch von 1918, eine Warnung an die Schwarzmeerflotte, die gegen die Logbücher der HMS Canterbury verifiziert wurde. Die KI wird zum Recherchewerkzeug, das Quellen findet, Software baut und Hypothesen testet. Angewiesen bleibt sie auf den Menschen, der die Aufgabe stellt und die Ergebnisse prüft.

Quelle: schneier.com

Ein neues Frontier-Modell gilt als Erfolg, wenn es jede Bestenliste anführt und den Preis nach oben schraubt. Grok 4.7 von SpaceXAI macht es anders: Der Token-Preis bleibt gleich, und der Anbieter räumt selbst ein, dass die Führung nicht überall gilt. Kein Alleskönner also, sondern ein Modell mit klar umrissenem Profil.

Entscheidend ist nicht, wer die ersten hundert Meter am schnellsten läuft, sondern wer über Stunden konzentriert bleibt. Bei Grok 4.7 stehen drei Dinge im Mittelpunkt: Ausdauer, Selbstkontrolle und der Umgang mit langem Kontext. Wer sich mit grok 4.7 für coding und knowledge work beschäftigt, sollte deshalb nicht nach dem einen großen Sprung suchen, sondern nach dem Verhalten auf langen Strecken.

Ausdauer statt Sprint: die Unterschiede zwischen Grok 4.7 und Grok 4.6

Grok 4.7 läuft auf einem neuen und größeren Basismodell als Grok 4.6, das nach Angaben von SpaceXAI mit einem längeren Reinforcement-Learning-Zyklus trainiert wurde. Die Aufgabenmischung wurde härter gewichtet, hin zu Arbeiten, die viele Stunden dauern können. Trainiert wird also nicht auf schnelle Einzelschritte, sondern auf Durchhaltevermögen.

Daraus ergeben sich die Eigenschaften, die der Anbieter nennt. Das Modell soll bei schwierigen Aufgaben länger dranbleiben, seine eigene Ausgabe sorgfältiger prüfen und mit ausgedehntem Kontext umgehen. Zusätzlich wurde Grok 4.7 nativ auf dem Grok-Bot-Harness trainiert, was auf konversationelle Aufgaben und allgemeine Wissensarbeit zielt.

Verfügbar ist das Modell nicht nur im eigenen Haus. Der Zugang reicht von Cursor über Grok Build und die Grok API bis zu Coding-Harnessen Dritter, Model-Routern und Cloud-Plattformen. Wer heute ki-modelle für programmierung auswählt, entscheidet also zunehmend innerhalb bestehender Werkzeugketten. Das senkt die Hürde, macht die konkreten Zahlen aber wichtiger.

Grok 4.7 Benchmarks und Testergebnisse im Detail

Die veröffentlichten Werte zeigen Fortschritte gegenüber Grok 4.6, aber keine gleichmäßigen. Auf CursorBench 4.0 kommt Grok 4.7 auf 46,3 Prozent und liegt damit über den 40,4 Prozent des Vorgängers. Auf DeepSWE v1.1 erreicht es 71,0 Prozent, wobei dieser Wert unter der Einstellung mit hohem Aufwand erzielt wurde. Die Zahl ist nicht ohne ihre Konfiguration zu lesen.

Weitere Ergebnisse: 64,0 Prozent auf EEBench, 1.657 Punkte auf AA Briefcase v1.1, 38,0 Prozent auf Terminal-Bench 4.0 und 19,6 Prozent im Harvey Legal Agent Benchmark. Zusammen mit den GDPval-Resultaten deuten vor allem die Briefcase-Werte auf stärkere Dokumenten- und Präsentationsarbeit in typischen Berufsfeldern hin. Genannt werden Juristinnen, Pflegekräfte und Finanzanalysten.

Die Liste ist schief. Ein großer Teil der Benchmarks stammt aus dem Umfeld Software-Engineering, Terminal und Agentenaufgaben. Das Modell ist dort am stärksten, wo Arbeit schrittweise abgearbeitet und zwischendurch überprüft wird. Wer einen grok 4.7 vs grok 4.6 unterschiede sucht, findet ihn weniger in der Breite des Wissens als in der Fähigkeit, eine Aufgabe zu Ende zu bringen.

Grok 4.7 Preise pro Million Tokens und die schnelle Variante

Bei den grok 4.7 preise pro million tokens bleibt SpaceXAI auf der Linie des Vorgängers: 2 Dollar für eine Million Eingabe-Tokens und 6 Dollar für eine Million Ausgabe-Tokens. Damit ist das Modell günstiger als andere Frontier-Systeme, ohne dass die Preisliste nach oben korrigiert wurde. Hinzu kommt eine Fast-Variante, die die doppelte Ausgabegeschwindigkeit zum doppelten Preis bietet.

Ein Sonderangebot ist das nicht. Lange Aufgaben bedeuten viele Ausgabe-Tokens, und dort liegt der teurere Teil der Rechnung. Ein Modell, das eine Stunde länger an einem Problem arbeitet, kann billiger pro Token sein und trotzdem teurer pro erledigter Aufgabe. In Grok Build lässt sich das Modell kostenlos ausprobieren, was den Einstieg erleichtert, aber nicht die spätere Kalkulation ersetzt.

Für Teams, die mehrere Anbieter parallel testen, ändert sich damit der Maßstab. Der Frontier-Modelle-Vergleich findet nicht mehr nur auf der Benchmark-Tabelle statt, sondern auf der Rechnung hinter dem Projekt. Wer ohnehin mehrere Harnesses betreibt, kann austauschen, was am Ende am wenigsten Umweg kostet.

Grok 4.7 Sicherheit und Jailbreak-Resistenz

Neben den Benchmarks geht es um Absicherung. SpaceXAI spricht von einem vollständig neuen Safeguard-Stack und nennt Grok 4.7 sein bislang stärkstes Modell bei Verweigerung und Widerstand gegen Jailbreaks. Auf dem Biosicherheits-Benchmark von LatchBio werden 62,4 Prozent erreicht, und auf HackerBench v0.3 ließ das Modell nur 3,3 Prozent riskanter Dual-Use-Prompts durch.

Interessanter ist der zweite Teil dieser Zahl. Dem Anbieter zufolge lehnt Grok 4.7 legitime Sicherheitsarbeit nur selten ab – ein Problem, das viele gehärtete Modelle plagt und das in der Praxis mehr stört als die gelegentliche Fehlverweigerung in der Demo. Ausgewählte Cybersicherheitspartner erhalten zudem einen zugangsbeschränkten Einblick in die Red-Team-Fähigkeiten für Verteidigungsforschung.

Solche Angaben sind mit Vorsicht zu lesen, weil sie vom Anbieter selbst stammen und die Testverfahren nicht offenliegen. Sie zeigen aber, wohin die Argumentation zielt: Sicherheit wird hier nicht als Anhang behandelt, sondern als Produktversprechen. Bei einem Modell, das über Stunden eigenständig an Aufgaben arbeitet, ist das keine Nebensache.

Wo der Vorsprung endet: HealthBench und die Grenzen der Zahlen

Nicht überall liegt Grok 4.7 vorn. Mit 56,7 Prozent auf HealthBench Professional bleibt es hinter GPT-5.6 Sol Max und Fable 5.1 Max zurück. Der Anbieter benennt diese Lücke selbst, was den Rest der Zahlen glaubwürdiger macht. Ein Modell kann bei Software-Aufgaben führen und bei medizinischen Fragen dennoch Zweiter sein.

Frontier-Modelle unterscheiden sich heute weniger in ihrer allgemeinen Qualität als in ihrer Form: Wo das eine breit antwortet, hält das andere länger durch. Wer diese Unterschiede ignoriert, kauft am Ende das Modell mit dem besten Marketing und nicht das mit dem passenden Profil.

Hinzu kommt die Frage der Übertragbarkeit. Benchmark-Ergebnisse entstehen in einem bestimmten Harness, mit bestimmten Einstellungen und oft mit erhöhtem Rechenaufwand. In der eigenen Umgebung, mit eigenen Werkzeugen und eigenen Aufgaben, verschieben sich diese Werte regelmäßig. Ein Testlauf mit echten Aufgaben aus dem eigenen Repository sagt mehr als jede Fremdtabelle.

Was das konkret für Coding- und Knowledge-Teams bedeutet

Für SpaceXAI hat die Veröffentlichung eine doppelte Funktion. Einerseits bindet Grok 4.7 die Modelllinie enger an die eigenen Coding-Produkte, andererseits öffnet sie den Zugang über externe Entwicklerwerkzeuge und Infrastrukturen. Die Kombination aus längerer Aufgabenausführung, Selbstprüfung, wettbewerbsfähigen Token-Preisen und engeren Schutzmechanismen richtet sich an Teams, die derzeit unter mehreren Kandidaten wählen müssen.

Wer ein Modell für lange, mehrstufige Arbeit sucht, sollte Grok 4.7 in die engere Auswahl nehmen und dabei zwei Dinge messen, die in keiner Benchmark stehen. Erstens die Token-Menge, die eine Aufgabe tatsächlich verbraucht, denn Ausdauer kostet Ausgabe-Tokens. Zweitens die Zahl der Eingriffe, die ein Mensch noch leisten muss, bis das Ergebnis brauchbar ist.

Ein Modell, das lange Strecken durchhält, zwischendurch nachprüft und bezahlbar bleibt, ist kein spektakulärer Sprung. Ob Grok 4.7 im Alltag hält, was die Zahlen versprechen, zeigt sich nicht in den ersten Testläufen, sondern in der täglichen Arbeit.

Quelle: testingcatalog.com

Ein Entwickler hat den Vorgang auf dem eigenen Telefon nachgebaut: ChatGPT in Chrome unter Android, angemeldet mit dem eigenen Konto, der Netzwerkverkehr mit zwei unabhängigen Methoden mitgeschnitten. Beim Aufruf gewöhnlicher Einkaufsseiten – Chewy, Wayfair, ThriftBooks und neun weiterer – taucht dabei jedes Mal dieselbe Kennung auf.

Im Mitschnitt erscheint bei jeder dieser Seiten ein Cookie, das keine von ihnen gesetzt hat. Es heißt __obi, ist auf die Domain openai.com beschränkt und trägt eine Kennung, die kurz zuvor im Chat erzeugt wurde. Der Entwickler dokumentiert damit ein Werbetracking-System, das ChatGPT mit dem Verhalten auf fremden Websites verbindet. Er hat den Ablauf auf dem eigenen Gerät nachgebaut, mit zwei unabhängigen Mitschnittmethoden geprüft und gegen mehrere Monate aufgezeichneten Verkehr gehalten: 936 Werbe-Pixel auf 1.029 Hostnamen.

Der Mechanismus besteht aus bekannten Teilen. Interessant ist, wo er auftaucht. Eine Analogie hilft bei der Einordnung: ein Armband auf einem Festival. Am Eingang wird es angelegt, jeder Stand kann es lesen, und am Ende wissen die Veranstalter, an welchen Ständen du warst. So ist __obi gebaut.

Vom Chat zur Kennung: so entsteht das Cookie der OpenAI-Werbeplattform

Der erste Schritt spielt auf chatgpt.com und fällt niemandem auf. Der Client erzeugt 16 zufällige Bytes und schickt sie an den Endpunkt /backend-api/bazaar/obi/sync-token, abgemeldet an die Variante für anonyme Nutzer. Zurück kommt ein signiertes Token im Format RS256, ein JWT mit kryptografischer Signatur. Darin steht im Feld sub das Konto, im Feld obi die Kennung. Das Token ist auf den Collector beschränkt und läuft nach 60 Sekunden ab.

Die Namen verraten die Herkunft. bzr steht für Bazaar, den internen Namen der OpenAI-Werbeplattform, wadi heißt der ausstellende Dienst. Wer den Namen Bazaar bisher nirgends gesehen hat, findet hier den ersten konkreten Anhaltspunkt: ein Werbesystem mit eigener Domain, eigener Infrastruktur und eigenem SDK.

Im zweiten Schritt wird aus der Kennung ein Cookie. Der Client schickt das Token per Cross-Site-Request an bzr.openai.com/v1/obi/sync. Der Server antwortet mit einem Set-Cookie-Header, der drei Dinge festlegt: SameSite=None, Secure, ein Jahr Laufzeit. SameSite=None ist der Schalter, der ein Cookie überhaupt erst bei seitenübergreifenden Anfragen mitschickt. Der Wert im Cookie ist derselbe wie im Token. Das ist der Kniff.

Der dritte Schritt gehört den Werbetreibenden. Jede Firma, die auf ChatGPT Anzeigen bucht, baut ein kleines Stück OpenAI-Code in die eigene Seite ein, so wie sie längst Code von Meta und Google einbaut. Lädt ein Browser dieses Skript von bzrcdn.openai.com, hängt er das Cookie von sich aus an die Anfrage. Das passiert, bevor auch nur eine Zeile des Skripts ausgeführt wird.

Was der Ad-Collector zusätzlich aus Formularen und Tag-Managern liest

Das SDK begnügt sich nicht mit der Kennung. Auf der Seite des Werbetreibenden sammelt es Identitätsdaten und sortiert sie in vier Quellen, die OpenAI selbst so benennt: in steht für Werte, die der Werbetreibende bewusst übergibt, fm, ht und js stehen für Werte, die das Skript aus Formularfeldern, gerendertem Seitentext und dem Datenbus des Tag-Managers abgreift. In den beobachteten Datenverkehren überwog die abgegriffene Identität die übergebene deutlich, mit 685 zu 255 Ereignissen.

Der Tag-Manager-Bus ist die ergiebigste Quelle für E-Mail-Adressen. Das SDK ersetzt window.dataLayer.push durch eine eigene Funktion, liest zusätzlich adobeDataLayer und findet umbenannte GTM-Schichten, indem es den Parameter l aus dem Skript-Tag von gtm.js auswertet. In aktuellen Versionen nimmt es E-Mail und Telefonnummer von dort. Version 0.1.31 holte zusätzlich Namen und Geografie, bevor der Umfang am 27. August eingeschränkt wurde.

Vor dem Versand werden E-Mail, Telefon, Vor- und Nachname mit SHA-256 gehasht. Land, Region, Stadt und Postleitzahl gehen im Klartext raus. Die Postleitzahl war das am häufigsten abgegriffene Formularfeld, mit 100 Ereignissen auf 28 Websites. URLs werden auf Origin plus Pfad gekürzt; in keinem der 23.929 beobachteten Fälle war eine Query-Zeichenkette dabei. Die Pfade bleiben aussagekräftig. Darunter fanden sich eine medizinische Diagnose, ein Schuldenberatungs-Funnel und ein Formular für Sammelklagen.

Ein zweiter Schalter sitzt in OpenAIs Ads Manager: das automatische Matching. Es war bei 638 von 881 Pixeln mit bekannter Einstellung aktiv, darunter bei jedem beobachteten Kredit- und Finanzierungswerbetreibenden. Eine Sperrliste schließt Passwörter, Einmalcodes, Kartennummern, Sozialversicherungsnummern, Geburtsdatum, Krankengeschichte, Diagnosen und Gerichtsfelder aus. Dass eine solche Liste nötig ist, sagt einiges über den Rest des Feldes.

Warum nur __obi die Seitengrenze überquert

Auf denselben Anfragen von Werbeseiten blockierte der Browser jedes andere Cookie von OpenAI. oai-did und oaicom-stable-id scheiterten an SameSite=Lax, das sie nur bei Navigationen mitschickt. oai-client-auth-info und die Session-Cookies scheiterten an der Domain, weil sie nicht zu openai.com, sondern zu chatgpt.com gehören.

__obi dagegen wurde gesendet, und das ist kein Zufall. Es ist die einzige OpenAI-Kennung, die mit SameSite=None konfiguriert ist. In der Armband-Analogie ist das der Unterschied zwischen einem Armband, das jeder Stand scannen kann, und einem Zettel in der Hosentasche, der nur im eigenen Gebäude gilt. Beide sind Kennungen, aber nur eine ist für das gebaut, was die Werbebranche Cross-Site-Tracking nennt.

Zwölf Shops, dreizehn Pixel: die gemessene Reichweite

Auf dem Gerät des Entwicklers wurde ein einziger __obi-Wert an OpenAI von zwölf kommerziellen Websites unter dreizehn verschiedenen Pixel-IDs gesendet, darunter Chewy, Wayfair, ThriftBooks, Eventbrite, HelloFresh, Coursera und SeatGeek. Jede dieser Anfragen quittierte der Collector mit dem Status 202, also mit Annahme. In der breiteren Datenbasis tauchten 12 von 30 beobachteten __obi-Werten bei mehr als einem Werbetreibenden auf, einer sogar bei zehn verschiedenen.

Ab hier wird aus einem einzelnen Cookie ein Profil. Ein Wert, der nur bei einem Händler auftaucht, sagt wenig. Ein Wert, der bei zehn auftaucht, erlaubt Rückschlüsse darauf, wie dieselbe Person einkauft, liest und recherchiert. So lässt sich ein ChatGPT-Account mit Website-Aktivitäten verknüpfen, ohne dass eine der beteiligten Seiten davon weiß.

Auch ohne Anmeldung und trotz getrennter Einwilligungen

Von 932 entschlüsselten Sync-Tokens trugen 736 die Angabe subject_type: account_user, die übrigen 196 die Angabe anonymous. Der anonyme Betreff ist genauso stabil wie der angemeldete: einer pro Gerät, nachweisbar über mindestens 27 Tage. Wer ChatGPT also nur ausgeloggt benutzt, verliert die Zuordnung nicht, er verliert nur den Namen daran.

In der Cookie-Richtlinie von OpenAI steht __obi unter Analytics-Cookies, mit einem Jahr Laufzeit, gültig für chatgpt.com und openai.com. Es ist der einzige Eintrag in dieser Kategorie. Analytics-Cookies werden dort als Hilfe beschrieben, um zu verstehen, wie die eigenen Dienste funktionieren und genutzt werden. Für Marketing betreibt OpenAI eine separate Einwilligung, oai_consent_analytics und oai_consent_marketing sind zwei verschiedene Schalter.

Jedes Token, das der Entwickler entschlüsselte, trug die Angabe consent_decision: analytics_allowed. Wer Analytics erlaubt und Marketing ablehnt, bekommt also genau dieses Cookie. Das ist der heikelste Befund für den Datenschutz bei ChatGPT. Nicht weil ein Cookie gesetzt wird, sondern weil die Einordnung als Analytics-Cookie die Frage aufwirft, ob Nutzer überhaupt verstehen können, was sie an dieser Stelle erlauben.

Der Entwickler hat am 14. September zwei Fragen an press@openai.com und privacy@openai.com geschickt: warum __obi als Analytics-Cookie klassifiziert ist, und ob jemand, der Analytics erlaubt und Marketing ablehnt, es trotzdem erhält. Die Antwort kam vom OpenAI-Support. Sie bestätigte die Anfrage, kündigte eine interne Prüfung an und beantwortete keine der beiden Fragen.

Wo die Beobachtung endet und was davon bleibt

Die Grenzen der Untersuchung benennt der Entwickler selbst. Gemessen wurde in Chrome unter Android. Safaris Intelligent Tracking Prevention blockiert Drittanbieter-Cookies vollständig, und Chrome unter iOS läuft auf WebKit, sodass der Mechanismus in keinem iOS-Browser funktioniert. Desktop-Chrome wurde nicht getestet. Auch die Auslösung ist nicht konstant: etwa jede fünfte ChatGPT-Sitzung erzeugte ein Sync-Token, und der mobile Webclient spielt Anzeigen ganz ohne Synchronisierung aus. Wer die Schritte nachvollzieht, kann also ein Pixel ohne Cookie sehen.

Auch der letzte Schritt ist eine Schlussfolgerung. Der Status 202 bedeutet, dass der Collector das Ereignis mit angehängtem Cookie angenommen hat. Dass OpenAI es serverseitig dem Konto zuordnet, folgt aus dem Design, wurde aber nicht direkt beobachtet. Der Unterschied ändert wenig an der Architektur, aber viel an der Beweislage.

Zum Vergleich: Das andere Cookie des Systems, __obref, wird auf der Domain des Werbetreibenden gesetzt. Jede Seite bekommt einen anderen Wert, keine kann den Wert einer anderen sehen; von 2.860 beobachteten Werten erschienen 2.828 unter genau einem Werbetreibenden. Die Werbetreibenden selbst haben also keinen Einblick. Sie haben ein Conversion-Pixel eingebaut und erfahren nicht, dass ihre Besucher mit einer ChatGPT-Identität verknüpft werden.

Strukturell ist das nichts Neues. Meta hat vor Jahren etwas gebaut, das demselben Muster folgt: ein angemeldetes Konto, Drittanbieter-Cookies beim Pixel-Aufruf, serverseitig aufgelöste Off-Site-Conversions. Neu ist der Ort. Auf einem KI-Chatprodukt landen Fragen, die viele Menschen nie in einem sozialen Netzwerk stellen würden, und dieselben Produkte handeln zunehmend im Auftrag ihrer Nutzer. OpenAI-Tracking auf Werbeseiten ist damit nicht nur ein Datenschutzthema, sondern eine Frage der Rollenvermischung.

Wenn du ChatGPT in Chrome unter Android nutzt, reicht es nicht, Marketing abzulehnen. Prüfe, was unter Analytics eingestellt ist, und entscheide, ob dieser Schalter für dich passt. Cookies lassen sich im Browser löschen — das setzt die Kennung zurück, beendet aber nicht die Mechanik. Die zwei Fragen an OpenAI stehen weiterhin offen.

Quelle: buchodi.com