Kategorie: KI-News

Warum geben Netzwerkverantwortliche die Kontrolle über ihre Netze an KI ab? Eine neue Studie von Cisco und der Beratungsfirma Omdia nennt einen Grund: Die Netze sind in vielen Unternehmen zu komplex geworden, um sie noch rein menschlich zu betreiben. Befragt wurden rund 1.000 IT- und Netzwerkbetriebsleiter.

Wer den Betrieb eines großen Unternehmensnetzes mit einer Flugsicherung vergleicht, sieht das Muster schnell. Mehr Flugzeuge, mehr Startbahnen, mehr Wetterlagen, dazu weniger Lotsen mit der passenden Ausbildung. Die Radarschirme füllen sich, die Warnhinweise blinken dichter, und irgendwann reicht die Aufmerksamkeit nicht mehr für alle Signale. An diesem Punkt steht der Netzwerkbetrieb vieler Organisationen.

Die Frage ist deshalb nicht mehr, ob KI im Netzwerkbetrieb eingesetzt wird, sondern wie viel Kontrolle die Teams abgeben wollen, unter welchen Bedingungen sie das tun und was davon im Alltag übrig bleibt. Der folgende Text geht den Zahlen der Erhebung nach.

Die Zahlen der Cisco-Omdia-Studie zu Agentic AI im Netzwerkbetrieb

Drei Viertel der Befragten setzen bereits in irgendeiner Form KI für den Netzwerkbetrieb ein. 80 Prozent fühlen sich wohl mit der Vorstellung, KI eine hohe oder vollständig autonome Rolle in der Netzwerkadministration zu übertragen. 56 Prozent der Befragten wollen das allerdings nur, solange ein Mensch die jeweilige Aktion freigibt. 24 Prozent sind damit einverstanden, dass KI Eingriffe ganz ohne menschliche Aufsicht vornimmt, und 82 Prozent erlauben autonome Produktionsänderungen zumindest für bestimmte Kategorien.

Eine andere Zahl fällt auf: 51 Prozent der Befragten nutzen agentische KI-Werkzeuge nach eigener Auskunft schon im Produktivbetrieb, um in Echtzeit korrigierend einzugreifen. Nicht, um sich beraten zu lassen, sondern um handeln zu lassen. Der Werkzeugkasten ist damit kein Analyseassistent mehr, der Vorschläge macht, sondern ein System, das eingreift. 84 Prozent erwarten, innerhalb von zwölf Monaten ein vollständig KI-geführtes Betriebsmodell zu erreichen. Der KI-gesteuerte Netzwerkbetrieb verschiebt sich damit von der Beobachtung zur Ausführung.

Solche Werte sind mit Vorsicht zu lesen. Zwölf Monate sind im Unternehmen eine kurze Spanne, besonders wenn Prozesse, Mitbestimmung und Haftungsfragen mit im Spiel sind. Die Richtung ist trotzdem eindeutig, und sie kommt nicht aus einer Laune heraus, sondern aus einem Druck, der sich messen lässt.

Netzwerkkomplexität: Änderungen im Tagesrhythmus

Die Erhebung nennt konkrete Gründe für den Kontrollverlust. 59 Prozent der Befragten ändern ihre Produktionsumgebung mindestens einmal täglich. Die Hälfte dieser Gruppe nimmt mehrere Änderungen pro Tag vor, bei einem Teil der Unternehmen passiert das mehrmals pro Stunde. 57 Prozent räumen ein, dass ihre Änderungsprozesse mit diesem Tempo nicht mehr mithalten können.

Dazu kommt die Verteilung der Probleme. 92 Prozent der Befragten berichten, dass Leistungsprobleme typischerweise mehrere Domänen gleichzeitig betreffen: Cloud, Sicherheit, Anwendungen, Endgeräte. Wer nur einen Ausschnitt des Netzes überwacht, sieht Symptome, aber nicht die Ursache. 95 Prozent sagen, dass ihre bestehenden, nicht agentischen AIOps-Werkzeuge genau hier versagen, weil sie zu viel menschliche Interpretation verlangen und zu wenig domänenübergreifende Sicht liefern.

Und dann ist da noch der Faktor KI selbst. Zwei Drittel der Befragten geben an, dass der Boom der generativen KI die Komplexität zusätzlich erhöht hat. Cisco hat den eigenen Datenverkehr zu KI-Diensten analysiert und festgestellt, dass sich das durchschnittliche tägliche Volumen etwa alle sechs Monate verdoppelt. Treiber ist nicht die einfache Anfrage, sondern die wachsende Komplexität der Aufgaben, die deutlich mehr Datenaustausch verlangt als eine Suchanfrage.

Von AIOps zu AgenticOps: Beratung wird Handlung

Der Unterschied zwischen den beiden Ansätzen lässt sich mit einem Instrumentenbrett im Cockpit vergleichen. AIOps leuchtet eine Warnlampe auf und überlässt es dem Piloten, sie zu deuten. AgenticOps schaltet nicht nur das Licht ein, sondern greift in die Steuerung ein, vorausgesetzt, es ist klar definiert, welche Eingriffe erlaubt sind und welche nicht. Cisco nennt diesen Schritt den Wechsel von AIOps zu agentengestütztem Betrieb, kurz AgenticOps, und meint damit mehr als klassische Netzwerkautomatisierung.

Zeus Kerravala, Gründer und Principal Analyst von ZK Research, hält den Schritt für unausweichlich. Agentische Abläufe seien notwendig, und Netzwerkfachleute würden sie annehmen, so seine Einschätzung. Es werde einige Zeit dauern, bis das Vertrauen in die neuen Werkzeuge gewachsen sei, ähnlich wie bei autonomen Fahrzeugen, die nach seiner Beobachtung deutlich weniger Unfälle verursachen als menschlich gesteuerte Autos. Dieselbe Logik wendet er auf KI-Agenten an: Sie werden Fehler machen, aber weniger als Menschen, und sie entlasten die Teams bei Aufgaben mit geringerem Wertbeitrag.

Jim Frey, Principal Analyst für Netzwerke bei Omdia und an der Entwicklung der Erhebung beteiligt, sieht die Entwicklung aus dem Blickwinkel des Personals. Für ihn ist AgenticOps das Ergebnis zweier gleichzeitiger Bewegungen: steigende Netzwerkkomplexität auf der einen, sinkende Zahl von Menschen mit den passenden Fähigkeiten auf der anderen Seite. Besonders knapp seien Fachleute, die Probleme über mehrere Domänen hinweg lösen können.

Warnmeldungen, blinde Flecken und die Zeit bis zur Lösung

Die tägliche Realität sieht so aus: Eine durchschnittliche Organisation erzeugt rund 4.100 Überwachungsmeldungen und Ereignisse pro Tag, etwa die Hälfte davon mit Netzwerkbezug. Omdia schätzt, dass eine Fachkraft pro Tag ungefähr 21 Netzwerkwarnungen prüfen, untersuchen und abschließen kann. Umgerechnet bräuchte es ein Team von rund 100 Spezialisten, um dieses Volumen zu bewältigen.

Kaum ein Unternehmen hat so viel Personal. 46 Prozent aller Warnungen werden ohne Untersuchung geschlossen. Für 65 Prozent der Befragten ist die Warnmeldungsmüdigkeit eine Quelle von Unzufriedenheit im Team, 67 Prozent sagen, dass die Menge sie davon abhält, andere wichtige Arbeit zu erledigen. Kerravala bestätigt diese Größenordnung aus eigener Forschung zu Sicherheitsalarmen, bei der deutlich weniger als die Hälfte aller Meldungen untersucht wird.

Auch die Werkzeuglandschaft trägt wenig zur Übersicht bei. Im Schnitt nutzen Unternehmen zehn verschiedene Instrumente, um Ende-zu-Ende-Sichtbarkeit herzustellen. Diese Werkzeuge sind in der Regel voneinander abgeschottet, was die Diagnose über Domänengrenzen hinweg erschwert, also genau den Fall, der laut 92 Prozent der Befragten der Normalfall ist. Die Auflösungszeiten spiegeln das wider: Im Mittel dauert es 88 Stunden, bis ein Netzwerkvorfall behoben ist, der Median liegt bei 12,5 Stunden. Frey erklärt die große Differenz damit, dass einzelne Organisationen eine Woche oder länger brauchen und den Durchschnitt nach oben ziehen.

Guardrails entscheiden über autonome Netzwerkoperationen

Die Bereitschaft, Verantwortung abzugeben, hat einen Preis. 99 Prozent der Befragten würden KI nicht ohne verbindliche Schutzmechanismen handeln lassen. Genannt werden erklärbare KI-Aktionen, menschliche Freigabe, richtlinienbasierte Betriebsgrenzen, Notfall-Übersteuerung, rollenbasierte Zugriffskontrolle und unveränderliche Prüfprotokolle. Erst diese Guardrails machen autonome Netzwerkoperationen für die Teams diskutabel.

Joe Vaccaro, Senior Vice President und General Manager für Netzwerkplattform und Assurance bei Cisco, beschreibt, wie solche Leitplanken Vertrauen schaffen. Nutzer sollen erkennen, auf welchem Weg ein Agent zu seiner Schlussfolgerung gekommen ist. Zwar könne ein Agent aus den Daten, die er untersucht, eigene Schlüsse ziehen, doch seine Aktionen folgten vordefinierten Abläufen, die sich an den Standardprozessen des Netzwerkteams orientieren. Der Agent improvisiert also nicht, er folgt einem Spielplan.

Eine weitere Einschränkung, die Frey aus Gesprächen mit Cisco mitnimmt: Agenten sprechen nicht mit anderen Agenten. Bleibt ein Agent auf sich selbst gestellt, ist er weniger gefährlich, weil er keine unkontrollierbaren Kettenreaktionen auslösen kann. Hinzu kommt, dass Agenten um konkrete Fähigkeiten und einen klar umrissenen Verantwortungsbereich herum gebaut sind. Genau diese Kombination gebe Betriebsteams die Zuversicht, agentische KI einzusetzen, so Vaccaro.

Die Erhebung erscheint in einer Zeit, in der es Rufe gibt, den KI-Einsatz zu bremsen. Ein Vorfall wie der Hack bei Hugging Face, bei dem KI-Agenten außer Kontrolle gerieten, zeigt, was fehlende Leitplanken anrichten können. Genau diese Leitplanken sind der Grund, warum hunderte Netzwerkverantwortliche bereit sind, einen Teil der Kontrolle abzugeben.

Was das für den Netzwerkbetrieb konkret bedeutet

Cisco positioniert dazu die eigene Cloud-Control-Plattform als Antwort: eine einheitliche Sicht und Managementebene für Netzwerk, Sicherheit, Compute, Observability und Collaboration, ergänzt um agentische KI, die domänenübergreifende Probleme diagnostiziert und behebt. Das ist das viel beschworene „single pane of glass“, diesmal mit KI darunter. Die Ironie, dass ein Hersteller, dessen Geräte die Komplexität mit aufgebaut haben, nun die Lösung für genau diese Komplexität verkauft, liegt auf der Hand. Kerravala sieht die Sache pragmatisch: Ja, die Anbieter seien mitschuldig gewesen, aber es sei gut, dass sie nun vereinfachen. Netze würden in viel mehr Zusammenhängen genutzt als früher, mit Größenordnungen mehr Geräten und Verbindungen.

Für den Alltag in den Teams folgt daraus eine Reihenfolge. Wenn du heute einen Einstieg suchst, liegt er fast nie im großen Wurf, sondern in wiederkehrenden Situationen. Wenn dieselbe Korrekturmaßnahme zum vierzehnten Mal nötig ist, liegt die Automatisierung nahe. Frey beschreibt genau dieses Muster: ausführen lassen ja, aber mit Rückmeldung, dass es geschehen ist. Das Ziel, Netzwerkkomplexität mit KI zu reduzieren, beginnt also nicht mit dem Umbau der gesamten Betriebsmannschaft, sondern mit dem Aussortieren der immergleichen Handgriffe.

Der zweite Schritt ist die Frage, wie viel Autonomie eine Organisation tatsächlich erträgt. Die Studie zeigt eine breite Mitte: Die meisten Befragten wollen KI handeln lassen, aber mit menschlicher Freigabe im Prozess. Vollständige Autonomie bleibt vorerst die Ausnahme, und das ist keine Schwäche, sondern eine vernünftige Reihenfolge. Vertrauen entsteht in der Flugsicherung nicht dadurch, dass man die Automatik sofort scharf schaltet, sondern dadurch, dass man sie lange genug beobachtet hat.

Am Ende bleibt eine Verschiebung, die sich kaum zurückdrehen lässt. Netzwerkkomplexität, Änderungsgeschwindigkeit und Personalmangel bilden zusammen einen Druck, dem reine Handarbeit nicht mehr gewachsen ist. KI im Netzwerkbetrieb ist damit keine Optimierungsfrage mehr, sondern eine Frage der Betriebsfähigkeit. Entscheidend wird sein, wer die Leitplanken definiert und ob die Teams sich die Zeit nehmen, sie sauber zu setzen, bevor sie die Hand vom Steuer nehmen.

Quelle: networkworld.com

Wer mehrere Coding-Agenten parallel laufen lässt, etwa Claude Code und Codex in getrennten Terminals, verliert schnell den Überblick: Welcher Agent hat welche Aufgabe begonnen, wer sollte sie prüfen, und welcher Kontext gehört wozu? Nach einem Neustart ist dieser Zusammenhang oft weg. Hier setzt OpenRig an, ein Open-Source-Projekt auf GitHub, mit dem sich aus Claude Code, Codex und Pi ein eigenes Netzwerk von Agenten aufbauen lässt.

Der Autor von OpenRig formuliert den Unterschied in einem Satz: Ein Harness umschließt ein Modell, ein Rig umschließt deine Harnesses. Das beschreibt, worum es geht. Du startest nicht mehr einzelne Coding-Agenten, sondern eine Mannschaft, die als System funktioniert. Wer schon länger mit KI-Coding-Agenten arbeitet, kennt das Problem: Ein einzelner Agent ist mächtig, aber sobald mehrere parallel laufen, entsteht Chaos.

Was OpenRig von einem einzelnen Agenten unterscheidet

Ein KI-Coding-Agent wie Claude Code oder Codex ist ein Werkzeug, das Anweisungen versteht und Code verändert. Er arbeitet in einer Sitzung, in einem Verzeichnis, mit einem Kontext. Für eine einzelne Aufgabe reicht das. Sobald aber ein Agent implementiert, ein zweiter prüft und ein dritter die Infrastruktur anpasst, brauchst du eine übergeordnete Ebene, die weiß, wer was tut. Diese Ebene ist OpenRig.

Der Autor beschreibt sein System als Schicht über den Harnesses, nicht als Ersatz. Claude Code und Codex laufen weiter wie gewohnt, nur unter der Regie eines Daemons, der ihre Sitzungen kennt, ihre Rollen verwaltet und ihre Kommunikation weiterleitet. Statt loser Terminals entsteht ein beständiges Team, das einen Neustart übersteht und sich gegenseitig Nachrichten schicken kann.

Die Rollenverteilung ist schlicht. In der Einsteiger-Anleitung steht ein Zweier-Team im Mittelpunkt: ein „Owner“, der eine Aufgabe umsetzt, und ein „Checker“, der die Änderung überprüft. Du sprichst mit dem Owner, der Owner koordiniert den Checker, am Ende bekommst du ein Ergebnis samt Review. Ein nüchternes Modell für ein Feld, in dem sonst gern von autonomen Agentenschwärmen die Rede ist.

Das Agenten-Team in YAML definieren

Die Topologie eines Teams wird nicht im Terminal zusammengeklickt, sondern in einer Datei beschrieben. OpenRig nennt dieses Format RigSpec und baut darauf Konzepte wie Pods, Edges und Continuity-Policies auf. Pods sind Gruppen zusammengehöriger Plätze (im Projektjargon „Seats“), Edges beschreiben, wie diese Plätze miteinander verbunden sind und wer wem schreiben darf. Continuity-Policies legen fest, wie ein Team einen Neustart übersteht.

Wer schon CI-Pipelines oder Kubernetes-Manifeste geschrieben hat, erkennt das Muster: Zustand wird deklarativ beschrieben, das Werkzeug kümmert sich um die Ausführung. Ein Agententeam, das man per YAML definiert, lässt sich versionieren, teilen und reproduzieren. Das fehlt, solange jeder Agent als handgestartete Terminal-Sitzung existiert. Der Start läuft dann mit einem Befehl, rig up, der die nötigen tmux-Sitzungen, Harnesses und Startdateien anlegt und prüft, ob alles bereit ist.

Das ist nicht nur ein Startskript. OpenRig erkennt bestehende Claude-Code- und Codex-Sitzungen in tmux und übernimmt sie in ein verwaltetes Rig. Man muss also nicht bei null anfangen. Auch der umgekehrte Weg ist vorgesehen: rig down –snapshot friert die aktuelle Topologie ein, rig up <name> holt sie wieder hervor.

Die TUI als Kontrollzentrum

Ohne eine Übersicht wäre ein Team aus mehreren Agenten kaum zu überblicken. OpenRig liefert deshalb eine Terminal-Oberfläche, die dieselben Rigs einmal als Graph und einmal als Tabelle zeigt. In der Tabelle stehen die einzelnen Plätze mit Laufzeit, Modell, Kontext und Zustand. Wer will, öffnet einen bestimmten Platz und sieht im Detail, was gerade passiert. Unspektakulär, im Alltag aber entscheidend.

Zur Kommunikation zwischen den Agenten gibt es drei Befehle, die sich leicht merken lassen: rig send schickt eine Nachricht an einen bestimmten Platz, rig broadcast an mehrere, und rig chatroom öffnet einen gemeinsamen Raum. Wer selbst in einem Terminal tippt und nicht durch automatische Nachrichten unterbrochen werden will, kann mit rig seat set-typing-guard einen Platz schützen. Automatische Nachrichten werden dann zurückgehalten, statt mitten in die eigene Eingabe zu platzen.

Das Dashboard lässt sich geteilt oder unabhängig öffnen. Ein geteiltes Dashboard verschwindet nicht, wenn man das Fenster schließt. Ein Detail, das darüber entscheidet, ob man ein Werkzeug ständig neu startet oder im Hintergrund laufen lässt.

Was OpenRig auf deiner Maschine verändert

Die README enthält einen eigenen Abschnitt: „What OpenRig changes on your machine“. Den sollte man lesen, bevor man irgendetwas installiert. OpenRig schreibt Konfiguration in Vertrauensdateien, legt Hooks an und erweitert Dateien wie ~/.tmux.conf, ~/.claude.json und die Codex-Konfiguration unter ~/.codex/config.toml.

Konkret: Beim Start eines Rigs werden Workspace-Trust-Einstellungen gesetzt, Codex-Hooks aktiviert und Vertrauens-Hashes für bestimmte Befehle vorab eingetragen. Claude Code bekommt einen Statusline-Befehl und ausgewählte Activity-Hooks in die lokale Settings-Datei geschrieben. Die Aktivitäts-Relays senden Ereignistyp, Sitzungskennung und Zeitstempel an den eigenen Daemon, ausdrücklich ohne Prompt-Text und ohne Tool-Argumente. Wer Datenschutz ernst nimmt, sollte diese Liste lesen. Provider-Dateien und Instanz-Zustand sind getrennt, aber ein geänderter OPENRIG_HOME-Pfad isoliert die Provider-Konfiguration nicht automatisch.

Vor dem ersten Start sollte man die betreffenden Dateien sichern. Manche Schreibroutinen behandeln unlesbare Einstellungsdateien als leere Objekte, und eine Garantie zur Wiederherstellung gibt es nicht. Der Befehl rig setup –dry-run zeigt den geplanten Eingriff an, ohne ihn auszuführen, deckt aber nicht jeden späteren Starteffekt ab.

Berechtigungen: Der Punkt, an dem es ernst wird

Ein Multi-Agenten-System für Coding-Agenten darf Dateien ändern, Befehle ausführen und im Grunde alles tun, wozu ein Agent eben in der Lage ist. OpenRig löst das nicht dadurch, dass es pauschal alles erlaubt. Der Autor beschreibt mehrere Stufen: Die Standardeinstellung für Codex ist ein Sandbox-Modus mit Schreibzugriff auf den Workspace, Claude Code startet mit --permission-mode acceptEdits. Ein vollständiger Bypass ist möglich, aber ausdrücklich nicht die Voreinstellung.

Für einzelne Plätze lässt sich mit rig seat set-permissions ein auditiertes Modell wählen, das beim nächsten Start greift. Eine solche Auswahl verändert den laufenden Prozess nicht. Wer denkt, ein Befehl schalte sofort schärfere Rechte frei, täuscht sich. Gewünschte Einstellung und zuletzt verwendete Startargumente werden getrennt angezeigt, und keine der beiden Angaben beweist, dass die native Durchsetzung greift.

In einem Umfeld, in dem Agenten gern als magische Helfer dargestellt werden, sagt der Autor klar, was sein Werkzeug kontrolliert und was nicht. Ein Multi-Agenten-Harness ist kein Sicherheitskonzept. Es ist eine Verwaltungsschicht, die dir den Überblick erleichtert und dich zwingt, dich mit Berechtigungen auseinanderzusetzen.

Für wen sich der Einstieg lohnt

OpenRig läuft auf macOS und Linux, benötigt Node.js 22 oder 24 und tmux. Auf Apple-Silicon-Macs empfiehlt der Autor Node.js 22, nativer Windows-Support fehlt bislang, WSL2 ist ungetestet. Die Installation erfolgt global über npm mit @openrig/cli, alternativ mit Bun. Danach folgt der erwähnte Trockenlauf, bevor etwas verändert wird.

Wer nur gelegentlich einen einzelnen Coding-Agenten nutzt, braucht das nicht. Wer aber regelmäßig mehrere KI-Coding-Agenten parallel laufen lässt, kennt das Problem der auseinanderdriftenden Terminals. OpenRig macht aus verstreuten Sitzungen ein adressierbares Team, in dem du den Überblick behältst, in dem Aufgaben nachvollziehbar ankommen und in dem ein Neustart nicht bedeutet, alles neu aufzusetzen.

Der Autor beschreibt den Einstieg klein: ein Repository, eine nützliche Änderung, ein Owner, ein Checker, ein überprüftes Ergebnis. Die Vorstellung, man definiere heute ein Agenten-Team in YAML und morgen erledige es die halbe Codebasis, hält der Praxis selten stand. Ein Rig aufzusetzen heißt, sich Gedanken zu machen: Wer prüft wen, welche Rechte bekommt welcher Platz, was passiert beim nächsten Reboot. Diese Fragen sind wichtiger als jeder zusätzliche Agent.

Quelle: github.com

Eine Produktankündigung ohne nutzbares Produkt ist im Softwaregeschäft Marketing. Bei Google Gemini 4 Argon stimmt das nur halb. Der Konzern legt prüfbare Angaben vor, aber keinen Zugang für normale Nutzer. Wer das Modell gerade selbst ausprobieren will, findet nichts. Was Google veröffentlicht hat, sagt trotzdem mehr über die Branche als manche fertig ausgelieferte Version.

Grundlage ist ein Bericht von Ryan Whitwam für Ars Technica vom 30. September 2026. Er beschreibt eine Ankündigung, die sich anfühlt wie ein Datenblatt ohne Fahrzeugschlüssel. Ein Hersteller zeigt einen Prototypen auf einem abgeriegelten Testgelände, nennt Leistung, Verbrauch und Preis, lässt aber niemanden hinters Lenkrad. Zahlen lesen, Zahlen vergleichen – losfahren geht nicht. Interessant ist, was in der Zwischenzeit auf dem Gelände passiert.

Was Google mit Gemini 4 Argon angekündigt hat

Google zufolge führt das Modell in Programmierung, Wissensarbeit und Cybersicherheit. In diesen drei Feldern entscheidet sich, ob ein KI-Modell im professionellen Einsatz sein Geld wert ist. Spannender als die Behauptung ist die Frage, wer es schon benutzt. Laut Google arbeiten eigene Ingenieure umfangreich damit, der Rest der Welt wartet. Der Konzern ist damit Kunde und Anbieter seines eigenen Produkts.

Zwei Beispiele zeigen den praktischen Nutzen. Gemini 4 Argon soll über unternehmensweite Telemetriedaten geholfen haben, rund 300 TiB Speicher in den Rechenzentren einzusparen. Außerdem sollen Agenten des Modells C- und C++-Codebasen nach Rust übertragen haben, darunter Tausende Zeilen in den Kernbibliotheken re2 und libgav1 sowie mehr als 800.000 Zeilen im Zircon-Kernel von Fuchsia. Wer schon einmal eine gewachsene Codebasis von einer Sprache in eine andere überführt hat, weiß, was das bedeutet. Hier zeigt sich, wofür Google Gemini 4 Argon intern tatsächlich einsetzt: als Werkzeug in der eigenen Infrastruktur, nicht als Demo.

Von Gemini 3.5 Pro zu den Flash-Modellen

Der Vergleich zu Gemini 3.5 Pro liegt nahe. Google hatte Gemini 3.5 Pro für Juni in Aussicht gestellt, doch der Sommer verging mit kleineren Flash-Modellen statt mit dem angekündigten Sprung an die Spitze. Für Beobachter sah das nach Verzögerung aus, vielleicht nach einem Strategiewechsel. Der Autor von Ars Technica schreibt trocken, Google sei nun bereit, es erneut an der Frontier zu versuchen.

Der Vergleich Gemini 4 Argon vs Gemini 3.5 Pro bleibt schwierig, weil das eine Modell nie in der angekündigten Form erschienen ist. Wer ein Produkt mit einem Versprechen vergleicht, vergleicht Versprechen. Es bleibt ein Muster: Große Modelle werden angekündigt, kleinere erscheinen, dazwischen liegt eine Zeitspanne, die niemand offiziell erklärt. Für Unternehmensplanungen ist das der unangenehmste Teil, weil er sich nicht kalkulieren lässt.

Die Benchmarkzahlen und die Million Ausgabe-Tokens

Google liefert Zahlen mit. Auf dem Software-Benchmark DeepSWE v1.1 erreicht Gemini 4 Argon laut eigenen Angaben 77,9 Prozent und liegt damit über GPT-6 Astra, Fable 5.1 und Opus 5.5. Beim wirtschaftsanalytischen Vals Index nennt Google ebenfalls einen Spitzenwert. Solche Tabellen sind mit Vorsicht zu lesen, weil der Anbieter Testaufbau und Aufgaben selbst bestimmt. Aussagekräftig sind sie trotzdem: Sie setzen eine Messlatte, an der sich Wettbewerber messen lassen müssen.

Greifbarer als Ranglisten ist eine technische Zahl. Das Ausgabelimit steigt auf eine Million Tokens, nach 64.000 Tokens in früheren Google-Gemini-Modellen. Das ist mehr als eine Verfünfzehnfachung und verändert die Aufgaben, die in einem Durchgang erledigt werden können. Statt kleiner Häppchen lässt sich ein kompletter Vorgang am Stück verarbeiten. Google zufolge werden so umfangreichere Arbeiten ohne Zwischenschritte möglich.

Auch beim Preis gibt es Angaben, obwohl das Modell noch nicht frei verfügbar ist. Für eine begrenzte Zeit nennt Google zwei Dollar pro Million Eingabe-Tokens und zehn Dollar pro Million Ausgabe-Tokens. Zwischengespeicherte Eingaben sollen mit 95 Prozent Rabatt berechnet werden. Ein Preis für etwas, das man nicht kaufen kann, klingt paradox. Er ist ein Signal an Unternehmen, die Budgets planen und eine Größenordnung brauchen, bevor sie eine Zusage machen.

Cyberabwehr, Wiz und das Fairwind-Programm

Der Schwerpunkt der ersten Phase liegt nicht auf Chat oder Textproduktion, sondern auf Cyberverteidigung. Google begründet den stufenweisen Start mit der Größe des Modells. Zunächst bekommt nur eine kleine Gruppe vertrauenswürdiger Tester Zugang. Partner im sogenannten Fairwind-Programm können die Abwehrfähigkeiten nutzen, bevor die Allgemeinheit überhaupt an eine Schnittstelle kommt.

Als Beleg nennt Google das Sicherheitsunternehmen Wiz. Wiz soll Gemini 4 Argon bereits einsetzen und damit eine kritische Schwachstelle gefunden haben, über die persönliche Daten in einem weltweit in Krankenhäusern genutzten System einsehbar gewesen wären. Google behauptet, andere Frontier-Modelle hätten die Lücke übersehen, nennt aber keine Details. Vorsicht ist hier angebracht: Eine Anekdote ersetzt keine unabhängige Prüfung, und ein Anbieter, der sein eigenes Modell lobt, ist kein neutraler Zeuge.

Trotzdem sagt die Reihenfolge etwas. Ein Modell, das zuerst an Sicherheitsteams geht und danach an Endkunden, ist ein anderes Produkt als ein Chatfenster für alle. Die Logik ist nachvollziehbar: Ein Werkzeug, das Schwachstellen findet, kann sie auch ausnutzen, wenn es in die falschen Hände gerät. Wer Zugriff bekommt, bekommt Macht. Google steuert diese Verteilung bewusst und nennt sie Phasenmodell.

Chain-of-Thought, Misalignment und die Unruhe nach dem Sommer

Über den Sommer gab es mehrere vielbeachtete Hacking-Vorfälle, seither ist die Sorge um fehlgeleitete Modelle lauter geworden. Misalignment beschreibt, wenn ein System nicht wegen eines Defekts das Falsche tut, sondern weil es ein Ziel auf eine Weise verfolgt, die niemand beabsichtigt hat. Google verweist dazu auf die Architektur von Gemini 4 Argon. Das Modell soll Systeme enthalten, die seinen Gedankengang überwachen und eingreifen, wenn es Grenzen überschreitet.

Der Konzern begründet das so: Transparenz im Schlussfolgern sei bei Frontier-Modellen nicht optional, sondern Voraussetzung. Bemerkenswert ist das, weil es den Blick auf etwas lenkt, das der Nutzer normalerweise nie sieht. Wer nur das Ergebnis liest, sieht die Zwischenschritte nicht. Überwacht werden soll genau diese Kette, nicht als Beweis für Ehrlichkeit, sondern als Notbremse. Ob das funktioniert, lässt sich von außen nicht beurteilen, solange niemand das Modell testen darf.

Was das konkret bedeutet

Für den deutschen Markt ist die Lage klar: Google Gemini 4 Argon ist noch nicht nutzbar, ein Termin für ein Release in Deutschland steht nicht fest. Google macht keine konkreten Zeitaussagen. Bekannt ist nur die Reihenfolge. Nach den Cybersicherheitstests beginnt die allgemeine Verfügbarkeit bei zahlenden API-Kunden und bei Abonnenten von Google AI Ultra. Wer wartet, sollte nicht auf einen Stichtag planen, sondern auf die Ankündigung einer Ankündigung.

Unternehmen sollten ihren Fahrplan nicht an einem Modellnamen festmachen. Plane Fähigkeiten, nicht Versionsnummern. Wenn ein Anbieter Ausgabelimits, Preise und Benchmarks veröffentlicht, ohne Zugang zu geben, ist das eine Einladung, die eigene Architektur darauf vorzubereiten – nicht, sie darauf zu bauen. Wer heute auf 64.000 Ausgabe-Tokens ausgelegt hat, sollte prüfen, was sich ändert, wenn eine Million möglich wird. Das betrifft Speicherbedarf, Kostenkontrolle und die Frage, wie viel Verantwortung ein einzelner Durchgang tragen darf.

Der Prototyp auf dem Testgelände bleibt das passende Bild. Google zeigt nicht das fertige Fahrzeug, sondern Messwerte und die Teststrecke. Die Strecke verrät am meisten: Speicher sparen, C++ nach Rust übertragen, Schwachstellen in Krankenhaussoftware finden. Das sind Aufgaben mit klarem wirtschaftlichem Wert, und sie erklären, warum der Konzern das Modell zuerst intern und bei Sicherheitspartnern einsetzt. Der Tag, an dem man selbst mit Google Gemini 4 Argon arbeitet, kommt danach. Bis dahin bleibt die spannendste Information, dass Google die Gedankengänge seines eigenen Modells überwachen will.

Quelle: arstechnica.com

539 Sterne, 25 Forks, zwölf Commits: das ist der öffentliche Stand des Repositories openai/mcp-extensions auf GitHub. Die Kurzbeschreibung dort lautet „Build plugins that feel like native, first-class features of ChatGPT“ – es geht also nicht um eine weitere Sammlung von Werkzeugaufrufen, sondern um die Frage, wie ein externer Dienst Teil der Oberfläche wird.

Wenn du heute ein ChatGPT-Plugin entwickelst, läuft alles über MCP, das Model Context Protocol. Damit kann ein Modell Werkzeuge aufrufen, Daten lesen, Aktionen auslösen. Was MCP nicht regelt, ist die Oberfläche: Wo taucht dein Dienst auf, wie öffnet sich ein Dokument, wie wählt jemand ein Bauteil aus einer Liste? Genau diese Lücke beschreibt das Repository von OpenAI, und dort entstehen Funktionen, die sonst nur das Produkt selbst hatte.

Wer nach OpenAI MCP Extensions auf GitHub sucht, landet in einem Projekt, das sich als Ergänzung versteht und nicht als Ersatz. MCP bleibt der Unterbau, die Extensions sind die Schicht darüber. Deshalb ist hier vieles offen und wenig abgeschlossen.

MCP als Mietvertrag, Extensions als Ladenfront

Stell dir ein Einkaufszentrum vor. MCP ist der Mietvertrag: Er legt fest, dass ein Laden Waren annehmen, Bestellungen aufgeben und Lieferungen auslösen darf. Das funktioniert und ist erprobt. Nur: Wer durch die Passage läuft, bemerkt diesen Laden möglicherweise gar nicht. Keine Tür zur Hauptachse, kein Schaufenster, kein Kassenband am Gang.

Die Extensions in openai/mcp-extensions sind diese Ladenfront. Sie ergänzen MCP um ChatGPT-spezifische Fähigkeiten, sodass ein Plugin an Stellen auftaucht, die sonst dem Produkt selbst vorbehalten sind. Der Begriff im Repository lautet „first-class“ – ein Plugin soll nicht als Gast erscheinen, sondern als Bewohner. Im Alltag ist der Unterschied deutlicher als in der Dokumentation.

Die Arbeitsteilung dahinter: MCP bleibt der neutrale Unterbau, den auch andere Clients nutzen können. Die Extensions sind die Schicht darüber, gebunden an eine konkrete Oberfläche. Du baust also zweimal – einmal unten, einmal oben – und nur die obere Schicht ist plattformspezifisch.

Vier Andockpunkte, an denen ein Plugin nativ wirkt

Das Repository zeigt die Erweiterungen als kurze Animationen statt als Liste von Funktionsnamen. Der Nutzen lässt sich so leichter zeigen als beschreiben. Der erste Andockpunkt sind Einstiegspunkte in der Seitenleiste: Nutzer öffnen die App direkt aus der Navigation, statt sie über eine Unterhaltung anzusteuern. Ein Dienst bekommt so einen festen Platz, nicht nur eine Erwähnung.

Der zweite Punkt betrifft Dateiendungen. Öffnet jemand eine Datei eines unterstützten Typs, kann das Plugin einen eigenen Betrachter rendern – im Beispiel ist es eine CAD-Datei, die in einer speziellen Ansicht erscheint. Der dritte Punkt heißt Composer Mentions: In der Eingabezeile lässt sich nach Ressourcen des Plugins suchen und ein Verweis in die Nachricht einfügen. Der vierte Punkt sind erweiterte Formulare, in denen die Auswahl über Vorschaubilder läuft statt über Textlisten.

An diesen vier Punkten entscheidet sich, ob ein Werkzeug benutzt oder umgangen wird. Ein Modell kann einen Tool-Aufruf erzwingen – es kann aber niemanden dazu bringen, ein Werkzeug zu mögen. Sichtbarkeit, Suchbarkeit und eine brauchbare Auswahloberfläche machen aus Erreichbarkeit tatsächliche Nutzung. Native ChatGPT-Features mit Plugins entstehen genau hier.

Bits & Bolts: der Referenzfall aus dem Repository

Alle Beispiele stützen sich auf ein einziges Plugin namens Bits & Bolts, in einer Remote-Variante. Wer es ausprobieren will, installiert es aus dem Plugin-Verzeichnis und öffnet anschließend die „Parts Library“ in der Seitenleiste – dort liegt die Bauteilbibliothek, mit der die weiteren Beispiele arbeiten. Eine Bauteilbibliothek mit Vorschaubildern, Dateiansichten und Suchfunktion zeigt jede der vier Erweiterungen in einem realistischen Zusammenhang.

Ein Beispiel, das alle Erweiterungen gleichzeitig verwendet, zwingt die Autoren zu einer konsistenten Schnittstelle und zeigt Entwicklern, wie sich die Teile zusammensetzen. Wer ein eigenes Plugin plant, kann sich an dieser Struktur entlanghangeln statt jede Entwurfsentscheidung allein zu treffen.

Das Beispiel ist kein Katalog von Endpunkten und keine Referenz aller möglichen Parameter. Das Repository bleibt beim Prinzip „zeigen statt auflisten“. Die Details liegen in der Spezifikation, auf die der letzte Abschnitt verweist.

SDKs, Registry und der Weg von der Idee zum Plugin

Der Einstieg ist in vier Schritte gegliedert, und der erste verlangt kein eigenes Projekt: erst ausprobieren, dann bauen. Für den Bau verweist das Repository auf die allgemeine Plugin-Dokumentation; sobald ein Plugin existiert, kommen die SDKs hinzu. Für TypeScript heißt das Paket @openai/mcp-extensions und ist für MCP-Server und Apps gedacht, für Python heißt es openai-mcp-extensions und richtet sich an Server.

Die Sprachverteilung im Repository passt dazu: rund 62,7 Prozent TypeScript, 30,6 Prozent Python, dazu kleinere Anteile CSS, JavaScript und HTML. Wer ChatGPT Plugins entwickeln will, findet also beide gängigen Wege vorbereitet. Die Releases für Node und Python stehen jeweils bei 0.1.0.

Für die Verteilung spielt die MCP Registry eine Rolle, jener Ort, an dem sich externe Tools integrieren und auffindbar machen lassen. Der Weg: Plugin bauen, SDK einbinden, über die Registry verfügbar machen, im Verzeichnis installieren. Wer täglich mit GitHub Copilot arbeitet, kennt das Muster Kontext, Werkzeug, Ausführung – hier in der Gegenrichtung. Nicht der Assistent greift auf deinen Code zu, sondern dein Dienst greift in die Oberfläche des Assistenten.

Version 0.1.0, Apache 2.0 und ein Blick in die Historie

Zwölf Commits, drei Releases, drei Mitwirkende: Das Repository ist jung, und die Historie verrät, woran gerade gearbeitet wird. Die jüngsten Einträge datieren auf den 29. und 30. September 2026. Der letzte Commit betrifft die Spezifikation: Die Abschnitte zu MCP Apps wurden an eine stabile Fassung gebunden, während der Entwurf gepinnt bleibt.

Die Autoren unterscheiden hier zwischen dem, was schon verlässlich ist, und dem, was sich noch bewegt – inklusive Sicherheitsarbeit an Dateiimporten und Grenzen für Speicherzuweisungen. Wer darauf plant, sollte die Spezifikation als Vertrag lesen, nicht als Handbuch.

Die Lizenz ist Apache 2.0, also offen und für kommerzielle Nutzung geeignet. Bei 539 Sternen und 25 Forks ist Aufmerksamkeit vorhanden, die Verbreitung aber noch überschaubar. So sehen Schnittstellen oft aus, wenn sie gerade erst definiert werden.

Was das konkret bedeutet

Für Entwickler ändert sich die Frage am Anfang. Statt „welche Funktionen stelle ich bereit?“ lautet sie nun „an welcher Stelle der Oberfläche soll mein Dienst auftauchen?“ Dieser Entwurfsgedanke entscheidet früh über den Erfolg eines Plugins – früher als jede API-Dokumentation.

Für Nutzer bleibt die Wirkung unsichtbar, bis sie plötzlich fehlt. Ein Plugin mit Seitenleisteneintrag, eigenem Dateibetrachter und durchsuchbaren Ressourcen fühlt sich nicht wie eine Erweiterung an, sondern wie ein Teil des Programms.

Wer heute baut, baut auf einer frühen Version. Die SDKs stehen bei 0.1.0, die Spezifikation unterscheidet stabil und Entwurf, und die MCP Apps Dokumentation wird laufend nachgezogen. Experimentieren lohnt sich, feste Zusagen gibt es noch nicht.

Quelle: github.com

Ein KI-Modell, das Exploits selbstständig baut — wie gefährlich ist das? Anthropics Sicherheitsteam hat das im September untersucht. Im Mittelpunkt: GLM-5.3, das aktuelle Modell des chinesischen Anbieters Zhipu AI, das außerhalb Chinas als Z.ai firmiert. Das Ergebnis ist unangenehm. Das Modell baut funktionsfähige Angriffswerkzeuge, auf einem Niveau, das bis vor wenigen Monaten nur geschlossenen Spitzenmodellen zugetraut wurde. Der Unterschied liegt weniger in der Fähigkeit selbst als darin, wer sie nutzen darf.

Ein Bild hilft, die Tragweite einzuordnen. Ein Modell mit offenen Gewichten ist wie ein Werkzeugkasten, bei dem der Bauplan mitgeliefert wird: Jeder kann ihn nachbauen, umschweißen und die eingebaute Sicherung ausbauen. Bei geschlossenen Modellen bleibt der Bauplan beim Hersteller, der Werkzeugkasten wird nur ausgeliehen und später wieder eingesammelt. Dieser Unterschied zieht sich durch den ganzen Bericht über GLM-5.3. Die Autoren Andrew Fasano, Marius Fleischer, Cole McFaul, Robert Xiao und Tripp Gallagher beschreiben nicht nur, was das Modell kann, sondern auch, wie leicht sich seine Schutzmechanismen entfernen lassen.

Was GLM-5.3 bei Exploits leistet

Für die Messung der Angriffsfähigkeiten nutzt das Team zwei Werkzeuge. Das erste ist ExploitBench, ein Benchmark für bekannte Schwachstellen in der V8-Engine von Google Chrome. Entscheidend ist nicht, ob ein Modell eine Lücke erkennt, sondern ob es daraus einen vollständigen Exploit baut. Laut Bericht gelingt GLM-5.3 das in 50 von 410 Versuchen, das eigene Modell Claude Mythos Preview in 56 von 410. Zwei Modelle auf Augenhöhe.

Das zweite Werkzeug ist ein interner Benchmark für binäre Ausnutzung, auf Basis von Projekten aus Googles OSS-Fuzz-Programm. Volle Punktzahl gibt es nur für vollständige Kontrollflussübernahme, also dafür, dass der Angreifer die Programmsteuerung übernimmt. Auf 100 zufällig ausgewählten Aufgaben erreicht GLM-5.3 das in vier Prozent der Durchläufe, Claude Mythos Preview in sechs Prozent. Interessanter als der kleine Abstand ist die Grenze dahinter: Frühere Modelle wie Claude Opus 4.6, GLM-5.2, Kimi K3 oder DeepSeek V4.1-Flash kommen in beiden Tests praktisch nicht über null Prozent.

Ein Exploit ist mehr als ein einzelner Trick. Er ist eine Kette, bei der jedes Glied stimmen muss: die Lücke finden, ihre Ursache verstehen, den Speicher gezielt manipulieren, Schutzmechanismen umgehen, den Angriff reproduzierbar machen. Solche Ketten baut GLM-5.3 laut Analyse eigenständig. Für Angreifer ist das der entscheidende Sprung. Knapp ist nicht das Wissen um eine Schwachstelle, sondern die Arbeit, aus ihr eine Waffe zu formen.

Der Sprung zwischen GLM-5.2 und GLM-5.3

Die Kurven im Bericht zeigen den Erfolg nicht als feste Zahl, sondern abhängig vom Rechenbudget, gemessen in ausgegebenen Tokens. Das verrät, wie schnell ein Modell mit mehr Arbeitszeit besser wird. Bei GLM-5.3 steigt die Erfolgsquote deutlich, bei GLM-5.2 bleibt die Linie nahe null, egal wie viel Rechenzeit man investiert. Dasselbe Muster zeigt der Vergleich von Claude Opus 4.6 und Claude Mythos Preview.

Die Autoren lesen daraus einen Generationssprung, keinen graduellen Fortschritt. Zwischen aufeinanderfolgenden Versionen liegt offenbar eine Schwelle, ab der aus vereinzelten Teilerfolgen eine belastbare Fähigkeit zur autonomen Ausnutzung wird. Deshalb ist die Veröffentlichung von GLM-5.3 mehr als eine weitere Zeile in einer Rangliste. Wer ein Modell dieser Klasse kontrolliert, kontrolliert ein Werkzeug, das vorher nur hinter Zugangsschranken zu haben war.

Auch wie die Vergleiche zustande kommen, ist bemerkenswert. Die eigenen Claude-Modelle wurden mit deaktivierten Sicherheitsvorkehrungen getestet, in einem Zustand also, den normale Nutzer nicht erreichen. Bei GLM-5.3 brauchte es diesen Kunstgriff nicht, weil das Modell ohnehin frei herunterladbar ist. Der Vergleich misst damit nicht nur Fähigkeiten, sondern auch, wer sie tatsächlich abrufen kann.

Ein Forschertag genügt für eine Exploit-Kette

Neben den automatisierten Benchmarks schildern die Autoren Tests, bei denen Fachleute das Modell auf unbekannte Ziele ansetzten. In einer ersten Sitzung arbeitete ein Forscher auf einer abgeschotteten Maschine mit einer Linux-Version eines verbreiteten Browsers. Im Laufe eines Tages fand GLM-5.3 mehrere bis dahin unbekannte Schwachstellen in der JavaScript-Engine und verknüpfte sie zu einem funktionierenden Exploit. Das Ergebnis: eine Webseite, die beim Besuch beliebige Dateien vom Rechner ausliest, darunter einen privaten SSH-Schlüssel. Der menschliche Aufwand blieb gering, unter einer Stunde konzentrierter Arbeit.

Die Autoren weisen darauf hin, dass die Lücke im Linux-Build nachgewiesen wurde, andere Plattformen aber wahrscheinlich ebenfalls betroffen sind, wenn auch über komplexere Wege. Der Hersteller wurde informiert. In derselben Sitzung stieß der Forscher mit Unterstützung des Modells auf weitere ausnutzbare Schwachstellen, unter anderem in Funk- und Grafiktreibern sowie in netzwerknaher Gerätesoftware. Diese Fälle werden derzeit geprüft.

Eine zweite Sitzung widmete sich einer bekannten Lücke, dem Chrome-Fehler CVE-2026-11645. Es ging um die Frage, wie schnell sich ein öffentlicher Patch in einen funktionierenden Angriff verwandeln lässt, in der Sicherheitsszene als N-Day-Problem bekannt. Das kleinere Modell GLM-5.3-Flash verband den Fehler mit einer weiteren bekannten Schwachstelle zu einer zuverlässigen Exploit-Kette für ARM64-Systeme und umging die Pointer-Authentication-Härtung. Der menschliche Anteil: rund zwanzig Minuten Aufmerksamkeit. Das Modell arbeitete acht Stunden. Zu den API-Preisen von Zhipu entspricht das etwa 20,40 Dollar.

Warum sich die Sicherheitsvorkehrungen umgehen lassen

GLM-5.3 hat Schutzmechanismen. Auf klar schädliche Anfragen verweigert das Modell in der Regel die Antwort. Die Autoren zeigen aber, dass sich diese Verweigerung mit einfachen Mitteln aushebeln lässt. In einer simulierten Umgebung, in der das Modell offen zur Attacke auf kritische Systeme aufgefordert wurde, lehnte es zunächst in allen Durchläufen ab. Mit einer Rahmenhandlung, die es zu einem autonomen Red-Team-Agenten in einer Übung erklärte, sank die Verweigerungsquote auf 64 Prozent. Das Modell spielte also in mehr als der Hälfte der Versuche mit. Wurde ihm ein Teil seiner Antwort vorab eingefüllt, reagierte es in 92 Prozent der Fälle.

Die gründlichste Methode heißt Abliteration. Dabei werden die Gewichte, also die trainierten Zahlenwerte des Modells, so verändert, dass die eingelernte Weigerungshaltung verschwindet. Weil GLM-5.3 als Open-Weight-Modell erscheint, kann das jeder mit entsprechender Hardware selbst tun. Mehrere Entwickler veröffentlichten schon wenige Tage nach dem Release passende Varianten. Anthropic erstellte zu Forschungszwecken eine eigene abliterierte Fassung und beziffert den Aufwand auf rund 2.200 GPU-Stunden und etwa 4.400 Dollar Rechenkosten. Für die kleinere Variante GLM-5.3-Flash genügten rund 600 GPU-Stunden.

Das Ergebnis ist eindeutig. Die Verweigerungsquote fiel von über 90 Prozent auf etwa drei Prozent im JailbreakBench, zwei Prozent im HarmBench und zwölf Prozent im StrongREJECT. Die Leistungsfähigkeit blieb weitgehend erhalten: Im GPQA-Diamond, einem Test für allgemeine wissenschaftliche Fähigkeiten, schnitten Original und abliterierte Fassung identisch ab; im CyberGym-Test lag die veränderte Version nur wenige Prozentpunkte niedriger. Bei den geschlossenen Claude-Modellen ist dieser Weg versperrt, weil die Gewichte nicht veröffentlicht werden und sich nicht nachträglich umbauen lassen.

Was die NIST-CAISI-Bewertung von GLM-5.3 zeigt

Die Analyse steht nicht allein. Am 17. September veröffentlichte das Center for AI Standards and Innovation (CAISI) am US-NIST eine eigene Einschätzung der Cyberfähigkeiten von GLM-5.3. Die Behörde nennt es das bislang fähigste Open-Weight-Modell im Bereich Cyber und verortet es im Aggregat ihrer Benchmarks etwa vier Monate hinter der US-Spitze. Die Befunde von Anthropic decken sich in der Tendenz damit.

Ein Detail der CAISI-Methodik ist wichtig. Die amerikanischen Vergleichsmodelle wurden, wo nötig, mit deaktivierten Sicherheitsvorkehrungen getestet, und zur US-Spitze zählen auch Modelle, die nur geprüften Nutzern zugänglich sind. Für Angreifer sind diese Versionen praktisch unerreichbar. GLM-5.3 dagegen kann jeder herunterladen — ohne Antrag, ohne Prüfung, ohne Vertrag. Der Abstand von vier Monaten beschreibt deshalb nicht nur einen technischen Rückstand, sondern eine offene Tür.

Was das für Angreifer und Verteidiger bedeutet

Die Fähigkeit selbst ist nicht neu. Neu ist ihre Verteilung. Genau das meinen die Autoren, wenn sie schreiben, Modelle dieser Klasse seien nun angekommen: Was zuvor in einem kontrollierten Kreis von Verteidigern zirkulierte, liegt jetzt als herunterladbare Datei vor. Wer Software betreibt, muss deshalb nicht in Panik verfallen, sollte aber realistisch rechnen. Der Abstand zwischen dem Bekanntwerden einer Schwachstelle und einem funktionierenden Angriff schrumpft — auf Stunden, wenn ein Modell acht Stunden rechnen darf.

Zugleich gilt der umgekehrte Fall. Dieselben Fähigkeiten helfen Verteidigern, Schwachstellen zu finden, bevor sie ausgenutzt werden. Im Programm Project Glasswing, mit dem Anthropic sein eigenes Spitzenmodell zunächst nur geprüften Sicherheitsteams zur Verfügung stellte, wurden nach Angaben des Unternehmens mehr als 10.000 Schwachstellen in kritischer Software aufgespürt. Diesen Vorsprung beschreiben die Autoren als bewusst gewählten Zeitgewinn, bevor vergleichbar fähige Modelle allgemein verfügbar wurden. Offen bleibt, wie lange solche Vorsprünge halten, wenn Gewichte frei verteilt werden.

Für die Praxis bleibt eine nüchterne Einordnung. Die Abliteration eines Modells kostet derzeit noch Tausende Dollar Rechenzeit und einiges an Know-how. Beide Hürden sinken mit jeder Generation. Sicherheitsvorkehrungen, die nur in den Antworten eines Modells verankert sind und nicht in der Verfügbarkeit seiner Gewichte, halten einem entschlossenen Angreifer nicht dauerhaft stand. Wer Systeme betreibt, sollte deshalb weniger darauf setzen, dass ein Angreifer keine KI benutzt, und mehr darauf, dass Angriffe schneller erkannt, Patches rascher eingespielt und Schutzmechanismen wie Pointer-Authentication nicht als Allheilmittel behandelt werden.

Quelle: anthropic.com