Kategorie: KI-News

123.600 Token auf der einen Seite, 50.800 auf der anderen. Dazwischen liegt der Effekt, den der Agent-Modus in der DuckDB-Kommandozeile in einer Messung erzielt hat, die das DuckDB-Team selbst veranlasst hat. 59 Prozent weniger Text musste ein Sprachmodell lesen, um dieselben Fragen richtig zu beantworten. Den Agent-Modus gibt es seit DuckDB v2.0 in der Shell, vorgestellt hat ihn das DuckDB-Team am 9. Oktober. Er ändert nichts an der Datenbank, wohl aber daran, wie ihre Ausgabe aussieht und wann die Shell eine ausufernde Abfrage stoppt.

Warum das nötig war, zeigt eine einfache Vorstellung. Ein Mensch am Terminal kann mit einem Ergebnis umgehen: hochscrollen, zurückblättern, nochmal nachfragen. Ein KI-Agent bekommt einen einzigen Blick. Er sieht, was durch die Pipe kommt, einmal, und alles, was nicht in diesem Text steht, existiert für ihn nicht. Nachfordern geht nicht, nachfragen auch nicht, und jedes Zeichen kostet — auch die Rahmenlinien und Leerzeichen, mit denen die CLI Spalten ausrichtet. Hier setzt der Agent-Modus an. Die Idee dahinter: Die Ausgabe soll für einen Leser gebaut sein, der nur einmal hinschaut.

Agentenerkennung: Wie DuckDB einen KI-Agenten erkennt

AI Coding Agents wie Claude Code, Codex, Cursor, Gemini CLI oder GitHub Copilot markieren ihre Befehle mit Umgebungsvariablen. Eine einheitliche Konvention gibt es nicht, also prüft die Shell eine ganze Liste. Claude Code, Goose und Amp setzen AI_AGENT oder AGENT, Claude Code zusätzlich CLAUDECODE. Codex nutzt CODEX_CI, CODEX_SANDBOX und CODEX_THREAD_ID, Cursor setzt CURSOR_AGENT, Gemini CLI setzt GEMINI_CLI, GitHub Copilot bringt COPILOT_AGENT, COPILOT_CLI und COPILOT_AGENT_SESSION_ID mit. Taucht eine dieser Variablen auf, weiß die Shell, dass ihr Gegenüber wahrscheinlich kein Mensch ist.

Das allein reicht nicht. Der Modus springt erst an, wenn drei Bedingungen zusammenkommen: eine der Variablen ist gesetzt, die Standardausgabe ist kein Terminal, und es wurde kein Ausgabeformat über die Kommandozeile vorgegeben. Wer -csv, -json oder -markdown übergibt, hat sich bewusst für ein Format entschieden, und der Agent-Modus hält sich raus. Zwei Flags überstimmen die Erkennung: -agent erzwingt den Modus, -no-agent schaltet ihn ab. Beide lassen sich mit Formatflags kombinieren, -agent -csv behält also das Agent-Verhalten und ändert nur die Darstellung der Zeilen. Mit .show prüfst du jederzeit, ob der Modus aktiv ist und welcher Agent erkannt wurde.

Nicht jeder Agent setzt eine passende Variable. Für diese Fälle gibt es einen leisen Hinweis: Scheitert ein Lauf beim Schreiben in eine Pipe, ohne dass ein Agent identifiziert wurde und ohne dass ein Flag gesetzt war, erscheint eine einzige Zeile auf stderr. Ein Agent, dem niemand vom Modus erzählt hat, kann ihn so beim ersten Fehler selbst entdecken.

Wie der Agent-Modus die Ausgabe für KI-Agenten optimiert

Im Agent-Modus druckt DuckDB Ergebnisse als Markdown-Tabellen ohne Ausrichtungs-Padding, mit dem Spaltentyp direkt in der Kopfzelle. Ein Modell liest die senkrechten Striche als Trennzeichen und braucht keine sauber ausgerichteten Spalten. Weil das weiterhin gültiges Markdown ist, bekommt auch ein Mensch, der später das Transkript liest, eine ordentlich gerenderte Tabelle. Auf typischen Ergebnissen ist dieses Format 25 bis 65 Prozent kleiner als die Kasten-Darstellung, bei breiten Ergebnissen am stärksten.

Bei der Ausgabemenge steckt der eigentliche Kniff. Alle Zeilen zu drucken würde stille Kürzungen vermeiden, aber eine Million Zeilen sind schnell 17 Megabyte durch die Pipe. Deshalb gibt der Agent-Modus ein Ergebnis bis 1.000 Zeilen und 10.000 Byte vollständig aus. Alles darüber wird zu einer Stichprobe aus den ersten und letzten 20 Zeilen, dazwischen eine explizite Markierungszeile, und eine Fußzeile erklärt, was passiert ist. Diese Fußzeile sagt auch, wie du den Rest bekommst. Die Grenzen passen sich mit .maxrows N und .maxbytes N an, -1 oder 0 steht für „kein Limit“. Lange Zellwerte werden bei 500 Zeichen abgeschnitten, mit sichtbarem Marker wie …(+4500 chars), steuerbar über .maxcellwidth N. Alle diese Werte sind nur Voreinstellungen: Ausdrückliche Einstellungen wie .mode, .maxrows, EXPLAIN (FORMAT …) oder Einträge in der .duckdbrc haben weiterhin Vorrang.

Ein Detail, das leicht übersehen wird: Die Fußzeile enthält einen Hash des gesamten Ergebnisses, auch der Zeilen jenseits der Kappungsgrenze. Der Hash ist unabhängig von der Zeilenreihenfolge und unterscheidet NULL von der Zeichenkette ‚NULL‘. Ein Agent, der wissen will, ob sich ein Ergebnis nach einer Änderung verschoben hat, vergleicht zwei Fußzeilen statt zwei vollständige Ausgaben. Die Fußzeile erscheint bei leeren Ergebnissen, ab zehn Zeilen und immer, wenn die Ausgabe gekappt wurde. Nur wenn die Abfrage früh abgebrochen wurde, fehlt sie — dann würde der Hash nicht das ganze Ergebnis abdecken.

Abgebrochene Abfragen und Kosten vor dem Start

Die kompakte Tabelle braucht keine Spaltenbreiten, deshalb kann das Ergebnis gestreamt werden. Ist die Obergrenze erreicht, werden die restlichen Zeilen nur noch gezählt und gehasht. Nach weiteren 100.000 Zeilen stoppt die Shell die Abfrage und meldet die Zahl als Untergrenze. Das Beispiel im Beitrag, eine Abfrage über eine Milliarde generierte Zeilen mit FROM range(1_000_000_000), liefert so in 30 Millisekunden ein Ergebnis, begleitet von der Fußzeile „first 20 of at least 102400 rows“. Wer wirklich alles sehen will, setzt .maxrows -1 und nimmt die Wartezeit in Kauf.

Noch einen Schritt früher greift die Kostenschätzung. Erwartet der Planer, dass eine Anweisung eine Million Zeilen oder mehr liest, geht seine Schätzung noch vor der Ausführung an stderr. Der Agent kann dann entscheiden, ob er wartet oder abbricht und die Abfrage umschreibt. Kleinere Abfragen geben nichts aus, die Zeile wäre nur Rauschen. Während eine lange Abfrage läuft, ersetzt eine schlichte Zeile auf stderr alle fünf Sekunden den Fortschrittsbalken, den ein Mensch im Terminal gewohnt ist.

Fehler als JSON und kompakte Query-Pläne

Fehler landen im Agent-Modus als JSON auf stderr, gesteuert über die bestehende errors_as_json-Einstellung. Auch Fehler, die die Shell selbst wirft — etwa ein unbekannter Punkt-Befehl —, werden in dieselbe Struktur verpackt. Ein Feld namens candidates fällt weg, weil die Meldung die Kandidaten ohnehin auflistet. Ohne diese Änderung wiegt ein einzelner „no matching function“-Fehler 2,7 Kilobyte, die ein Modell erst durcharbeiten muss.

Auch der Ausführungsplan schrumpft. EXPLAIN nutzt standardmäßig ein neues compact-Format mit einem Operator pro Zeile, eingerückt nach Tiefe; Schätzungen, tatsächliche Zeilenzahlen und Zeiten stehen in Klammern, gefolgt von den Eigenschaften des Operators. EXPLAIN ANALYZE beginnt mit einer Zusammenfassungszeile wie „QUERY (time=0.0012s, read=1.2 MB)“. Das ist ein reguläres Format, du kannst also auch außerhalb des Agent-Modus EXPLAIN (FORMAT compact) verwenden. Beim Schema hilft .tables, das jetzt eine Zeile pro Tabelle mit ungefährer Zeilenzahl und Spaltenliste ausgibt — durch eine Pipe deutlich lesbarer als das übliche Kastenlayout. Und beim Start druckt die Shell genau eine Zeile auf stderr, die erklärt, warum der Modus an ist und wie man ihn abschaltet. Die ausführliche Erklärung holst du dir bei Bedarf über .help agent, wo auch Hinweise auf SET max_execution_time, DESCRIBE, SUMMARIZE und duckdb_functions() stehen.

Die ehrliche Token-Bilanz: 59 Prozent sind nicht 59 Prozent

Nun zur Messung, mit der alles begann. Gemessen hat das DuckDB-Team nicht selbst, es hat Claude damit beauftragt: Claude Code beantwortete die 22 TPC-H-Fragen auf einem Datensatz der Skalierung 100 und schrieb Aufbau und Ergebnisse anschließend in einem Bericht zusammen. Es ist also eine Messung im Auftrag des Herstellers, kein unabhängiger Benchmark. Die Fragen waren in einfachem Englisch formuliert, ohne SQL. Jede Frage wurde dreimal mit Agent-Modus und dreimal mit -no-agent beantwortet. Alle 132 Läufe lieferten die richtige Antwort. Die Ausgabe, die das Modell lesen musste, schrumpfte von 123.600 auf 50.800 Token, also um 59 Prozent. Das ist die Token-Einsparung, um die es in der ganzen Diskussion geht.

Diese Zahl klingt spektakulärer, als sie ist, und der Bericht räumt das selbst ein. Die Einsparung tauchte weder in den Gesamtkosten noch in der Laufzeit nennenswert auf. Der Grund: In jedem Zug liest das Modell seinen eigenen System-Prompt erneut, und der ist deutlich größer als die Abfrageausgabe. Unterm Strich machten die gesparten Token etwa 0,5 Prozent der gesamten Eingabe aus. Die Läufe mit Agent-Modus brauchten sogar leicht mehr Schritte — 237 gegenüber 224. Claude Fable 5.1 fasste das Ergebnis so zusammen: Der Modus repariere die Dinge, die in einer Terminal-Shell ein Modell still in die Irre führen, und die gelesenen Token sanken um rund 60 Prozent, während jede Antwort weiterhin stimmte. Eine präzise, aber bewusst begrenzte Aussage.

Ausprobieren: Was Nutzer von Coding-Agenten tun müssen

Für die Praxis ist die Sache unspektakulär: Wer einen Coding-Agenten nutzt, muss nichts konfigurieren. Claude Code, Codex, Cursor, Gemini CLI und GitHub Copilot setzen bereits eine der Variablen und fangen die Ausgabe über eine Pipe ab — zwei der drei Bedingungen sind damit erfüllt. Solange die duckdb-Binary im Pfad des Agenten Version 2.0 oder neuer ist und kein Formatflag wie -csv, -json oder -markdown im Spiel ist, schaltet sich der Modus von selbst ein. Ein Formatflag gilt bewusst als Entscheidung, deshalb überstimmt es den Agent-Modus. Um zu sehen, was der Agent sieht, schickst du eine Abfrage mit gesetztem Flag durch eine Pipe — dann bekommst du genau das, was ein Modell zu lesen bekäme.

Der Agent-Modus ist kein Kostenturbo, und er macht ein Modell nicht klüger. Er räumt eine bestimmte Schwäche aus dem Weg: Ein Agent soll ein Ergebnis nicht für vollständig halten, wenn es nur ein Ausschnitt ist, und er soll nicht für Rahmenlinien bezahlen, die ihm nichts sagen. Das ist eine Designentscheidung für einen Leser, der nur einmal hinschaut. So gesehen ist der Modus weniger ein neues Feature als eine Korrektur an einem Werkzeug, das für Augen gebaut wurde, die zurückblättern können. Der Rest ist Feinschliff an den Konventionen, und da ist die Sache noch im Fluss: Das DuckDB-Team nennt das aktuelle Verhalten selbst einen ersten Versuch und bittet um Rückmeldungen, wenn ein Agent nicht erkannt wird oder die Ausgabe ihn verwirrt.

Quelle: duckdb.org

„Nach unzähligen Stunden der Härtung, Wartung und aktiven Entwicklung ist Pi jetzt ein solides Fundament, auf dem man bauen kann.“ So begründet das Team von Earendil in seiner Ankündigung vom 1. Oktober den Schritt, den es zusammen mit der Pi-Community vollzogen hat: Pi 1.0 ist erschienen. Die Ankündigung kommt ohne Pathos aus. Statt eines großen Versprechens steht dort eine nüchterne Feststellung über Reife.

Wer sich mit Coding-Agenten beschäftigt, kennt die Grenze, um die es hier geht. Ein Agent, der im Terminal einer einzigen Person dient, ist ein Werkzeug. Ein Agent, der stundenlang läuft, aus mehreren Oberflächen erreichbar ist und einen Absturz übersteht, ist Infrastruktur. Zwischen beidem liegt keine Modellverbesserung, sondern eine Schicht Software, die man Harness nennt. Um diese Schicht geht es im Kern — und sie ist der Grund, warum neben Pi 1.0 noch ein zweites Paket auftaucht.

Pi 1.0 als stabiler Kern, Pi Durable als offenes Experiment

Pi 1.0 soll der stabile Kern sein, auf dem gebaut wird. Der Coding-Agent Pi bleibt, was er war: Er läuft in einem Terminal, wird von einer Person gesteuert, und wenn der Prozess stirbt, schaut man nach, was passiert ist, und sagt ihm, es soll weitermachen. Das ist kein Mangel, sondern so ist dieses Werkzeug gedacht, und daran ändert Pi 1.0 nichts.

Parallel erscheint mit Pi Durable ein ausdrücklich experimentelles Paket. Laut Earendil ist es für lang laufende, durable und formbare Agenten gebaut, die überall laufen können – wobei „überall“ derzeit heißt: überall dort, wo eine JavaScript-Laufzeit vorhanden ist. Es geht nicht um ein einzelnes Produkt: Die Technologie soll in der Form angeboten werden, die jeweils am besten passt, statt in einer einzigen vorgegebenen. Dafür braucht es ein Agenten-Framework, das an jedem Ort läuft, aus unterschiedlichen Oberflächen erreichbar ist, unbegrenzt lange Gespräche trägt, katastrophale interne wie externe Fehler übersteht und mehrere Menschen und Clients gleichzeitig mit denselben Gesprächen arbeiten lässt.

Pi Durable ersetzt den Coding-Agenten nicht. Es teilt nicht nur Code mit ihm, etwa die Bibliothek pi-ai, sondern auch dessen Prinzipien: Minimalismus und Formbarkeit. Deshalb können beide nebeneinander existieren. Pi Durable dient als Spielwiese, auf der Entwürfe erprobt werden, ohne den Coding-Agenten im Alltag zu stören. Was sich dort bewährt, fließt später zurück in Pi.

Was ein Harness ist: Storage, Gespräche, Tools und Tasks

Ein Harness ist nach dem Verständnis von Earendil Storage plus die Maschinerie, die nötig ist, um ein oder mehrere Gespräche mit großen Sprachmodellen parallel zu betreiben. Er stellt die Werkzeuge bereit, die diese Modelle aufrufen, und die Umgebungen, in denen diese Werkzeuge laufen. Am besten lässt sich das als Leitstand mit Logbuch vorstellen: Der Leitstand fährt mehrere Vorgänge gleichzeitig, und jede Handlung wird vorher ins Logbuch geschrieben, damit sie nicht verloren geht.

Ein Gespräch wiederum ist eine Interaktion zwischen einem Menschen und einem Agenten, festgehalten als Transkript. Der Agent ist das Sprachmodell zusammen mit seinen Einstellungen, etwa dem Thinking Level, und den Werkzeugen, die es aufrufen darf. Die Werkzeuge arbeiten über eine Ausführungsumgebung, und das kann ein Laptop sein, eine entfernte virtuelle Maschine oder eine Sandbox im Arbeitsspeicher. Welche Werkzeuge und welche Umgebung ein Agent bekommt, entscheidet jedes Gespräch für sich. Alles, was der Harness ausführt, vom Modellaufruf bis zur Werkzeugausführung, ist ein Task.

Auffällig ist vor allem die Größe. Der gesamte Quellcode liegt ohne Tests bei rund 15.000 Zeilen, was mit GPT etwa 150.000 und mit Claude etwa 250.000 Tokens entspricht. Das ist der Worst Case, denn für den Aufbau einer Anwendung braucht ein Agent selten alles; allein die Storage-Backends umfassen 3.000 Zeilen, die er in der Regel überspringen kann. Die Absicht: Der Agent soll den Harness selbst verstehen können, auf dem er läuft.

Lange Läufe an jedem Ort: SQLite, JSONL und der Speicherbedarf

Langlebige Agenten brauchen einen Ort, an dem sie liegen. Ein Harness in Pi Durable öffnet deshalb über einem Storage-Backend, und mitgeliefert werden drei Varianten: Speicher, SQLite und JSONL. Dazu kommen eine Konformitäts-Suite und Benchmarks, damit eigene Backends geprüft werden können. Der Code für SQLite und JSONL verwendet keine Node-APIs, sodass er mit einem kleinen Adapter auch unter Bun oder innerhalb eines Cloudflare Durable Object läuft. Das Interface selbst ist klein genug, um es auf einen Key-Value-Store oder auf Postgres zu setzen.

Zur Ordnung gehört, dass immer nur ein Prozess einen Storage besitzt, während sich andere Clients an diesen Prozess anhängen. Bei SQLite hält der Harness ausschließlich das Arbeits-Set im Speicher: die aktiven Transkripte, laufenden Tasks und wartenden Eingaben. Alles andere bleibt auf der Platte, bis es gebraucht wird. Aktive Transkripte sind dabei von Natur aus begrenzt, weil die Kompaktierung ältere Nachrichten zusammenfasst, bevor sie das Kontextfenster sprengen. So passt selbst ein Gespräch mit zehntausenden Nachrichten bequem in den Arbeitsspeicher.

Die Kompaktierung ist dabei kein Sonderfall, sondern ein Task wie jeder andere, und sie läuft, während das Gespräch weitergeht. Nähert sich der Kontext dem Limit, fasst eine Hintergrund-Kompaktierung ältere Nachrichten zusammen, und die Zusammenfassung wird an der nächsten Turns-Grenze eingesetzt. Gewartet wird nur, wenn die nächste Anfrage sonst nicht passen würde. Weist der Anbieter eine Anfrage dennoch als zu lang zurück, kompaktiert der Harness und versucht es einmal erneut. Ältere Nachrichten bleiben ohnehin im Storage, und ein reset() geht noch weiter: Es beginnt einen neuen Kontext, wahlweise aus einer Übergabenotiz, während alles Vorherige durchsuchbar bleibt.

Nach dem Absturz weiterlaufen: Checkpoints und genau-einmal

Entscheidend ist die Frage, was passiert, wenn der Prozess stirbt. Der Laptop schläft ein, der Container wird neu ausgerollt, der Speicher läuft über. In Pi Durable speichert jeder Schritt eines Laufs einen Checkpoint, bevor er weitergeht. Ein neuer Prozess öffnet denselben Storage, findet die unfertigen Tasks und setzt jeden an seinem letzten Checkpoint fort. Hier tut das Logbuch aus der Analogie seine Arbeit: Es muss nichts rekonstruiert werden, es wird gelesen.

Im Detail wird eine abgebrochene Modellanfrage erneut gesendet, während die Teilantwort im Transkript bleibt und als abgebrochen markiert wird. Ein abgebrochener Werkzeugaufruf läuft nur dann erneut, wenn er selbst erklärt, dass das sicher ist. Andernfalls teilt man dem Modell mit, dass der Aufruf unterbrochen wurde, und übergibt die bisherige Ausgabe, damit es entscheiden kann. Eingereihte Nachrichten bleiben eingereiht. Eine requestId macht eine Einsendung genau-einmal wirksam, sodass ein Client, der nach einem Absturz erneut sendet, die ursprüngliche Einsendung zurückbekommt statt zweimal zu fragen.

Subagenten sind in Pi Durable nicht eingebaut, aber laut den Entwicklern in wenigen Zeilen Code gebaut. Ein Subagent läuft in einem eigenen Gespräch und setzt nach einem Absturz ebenfalls an seiner Stelle fort. Ein Subagenten-Werkzeug, das gefahrlos wiederholt werden kann, findet seinen Subagenten wieder und wartet auf dessen Antwort. Damit ist der Subagent kein Sonderfall der Architektur, sondern schlicht ein Gespräch, das von einem Werkzeugaufruf besessen wird.

Viele Gespräche gleichzeitig, Forks und eigene Agenten je Unterhaltung

Ein einzelner Harness fährt so viele Gespräche gleichzeitig, wie gebraucht werden, und zwar mit denselben Garantien wie im Einzelfall. Ein Gespräch startet neu oder forkt ein anderes an einer beliebigen Stelle seines Transkripts und sieht dessen Historie bis zu diesem Punkt, ohne sie zu kopieren. Das Beispiel, das Earendil dafür anführt, ist ein Slack-Kanal, in dem ein Agent Erwähnungen beantwortet und jemand einen Thread öffnet. Der Kanal ist ein Gespräch, der Thread ein Fork an genau der Nachricht, auf die geantwortet wird. Beide laufen gleichzeitig, ohne sich zu blockieren.

Jedes Gespräch speichert zudem seinen eigenen Agenten: das Modell, den Thinking Level, die ausgewählten Erweiterungen samt aktiven Werkzeugen, zusätzliche Anweisungen und das Arbeitsverzeichnis in seiner Ausführungsumgebung. Ein Prüfer, der neben dem Hauptagenten läuft, kann so ein günstigeres Modell nutzen, nur lesende Werkzeuge erhalten und in einem eigenen Checkout arbeiten. Die Trennung von Gespräch und Agent erlaubt damit unterschiedliche Rollen im selben System, ohne dass eine Rolle die andere verlangsamt.

Ebenso wichtig ist Earendil, dass viele Menschen und Clients gleichzeitig mit denselben Gesprächen arbeiten können. Weil alles, was eine Oberfläche braucht, als festgeschriebener Zustand vorliegt, kann sich eine beliebige Zahl von Clients an jedes Gespräch im Harness anhängen. Ein Client bekommt zuerst die aktuelle Ansicht – Transkript, die gerade gestreamte Antwort, laufende Werkzeuge samt Ausgabe, eingereihte Nachrichten, den Agenten und den Verbrauch – und danach nur noch die Änderungen. Wer später dazukommt oder die Verbindung verliert, startet wieder bei der aktuellen Ansicht, und jeder Client kann ein laufendes Gespräch steuern oder eine Folgefrage einreihen.

Erweiterungen, Hooks und was davon in Pi zurückfließt

Alles, was ein Agent tun kann, soll nach dem Willen der Entwickler steckbar sein, und jedes eingesteckte Teil soll an der Dauerhaftigkeit teilnehmen. Eine Erweiterung ist deshalb ein benanntes Bündel aus Systemprompt-Abschnitten, Werkzeugen, Hooks und Tasks. Die Anwendung installiert Erweiterungen in einer Registry, und jedes Gespräch wählt aus, was es nutzt, wobei es nur die Namen speichert. Der Systemprompt wird vor jeder Anfrage aus den Abschnitten der gewählten Erweiterungen neu gebaut, und Änderungen werden im Transkript an der Stelle festgehalten, an der sie passiert sind. Ein Neustart oder ein Fork sieht damit genau das, was das Modell gesehen hat; bei Modellen, die Änderungen mitten im Gespräch unterstützen, wird nur die Änderung gesendet, damit der Prompt-Cache gültig bleibt.

Werkzeuge werden ähnlich behandelt: Jeder Aufruf ist ein eigener dauerhafter Task, dessen Absicht vor der Ausführung gespeichert wird. Ein gleichnamiges Werkzeug in einer späteren Erweiterung ersetzt das frühere, und ein wrap verkleidet das jeweils gewinnende Werkzeug. Hooks greifen in Tasks ein, etwa in die Erzeugung einer Modellantwort, den Aufruf eines Werkzeugs oder die Kompaktierung. Sie können eine Anfrage umschreiben, einen Aufruf blockieren oder ein Ergebnis ersetzen. Da ein Hook nach einem Absturz erneut laufen kann, speichert eine Entscheidung sich in einem Memo, bei dem der erste Schreibvorgang gewinnt. Fehler in einem Hook werden gemeldet, und die Kette läuft weiter, außer bei beforeTool, wo ein Fehler den Aufruf blockiert.

Formbar heißt bei Pi Durable auch: Der Code eines laufenden Agenten lässt sich ändern, ohne ihn anzuhalten. Die Registry darf sich ändern, während Gespräche laufen; wer eine Erweiterung unter einem bereits vergebenen Namen installiert, ersetzt sie in einem Schritt. Ein Werkzeugaufruf, der schon läuft, endet mit dem Code, mit dem er begonnen hat, erst der nächste nutzt den neuen. Weil Gespräche nur Namen speichern und nie Code, übernehmen sie nach einem Neustart, was der neue Prozess installiert.

Auch der durable Anwendungszustand gehört zu diesem Bild: eine To-do-Liste, ein Plan, ein Ticket sollen so dauerhaft sein wie das Gespräch selbst. Solche Dokumente sind typisiertes JSON, liegen neben dem Transkript und werden in denselben atomaren Commits geändert, sodass der Zustand nie dem Transkript widerspricht, aus dem er entstanden ist. Tasks und Gespräche bilden dabei einen gemeinsamen Besitzbaum, und das Abbrechen eines Tasks bricht ab, was er besitzt, von unten nach oben. Vordergrund-Tasks gehören zur aktuellen Arbeit eines Gesprächs, Hintergrund-Tasks laufen weiter, während das Gespräch untätig ist. Damit lässt sich ein Subagent bauen, der den Turn überlebt, der ihn gestartet hat. Durable heißt nicht fehlerfrei, sondern wiederaufsetzbar. Ein System, das nach einem Absturz an der richtigen Stelle weitermacht, ist etwas anderes als eines, das nie abstürzt — und für lang laufende Agenten ist das die realistischere Eigenschaft. Wer einen Coding-Agent mit langer Laufzeit baut, bekommt hier einen Werkzeugkasten, der ausdrücklich experimentell ist; die API kann sich laut Earendil noch ändern. SQLite-Storage, Forks und Hooks sind kein fertiges Produkt, sondern eine Grundlage, auf die man die eigene Anwendung stellen kann.

Quelle: earendil.com

„Today we’re launching the Anthropic Cyber Mission, a long-term commitment to securing the systems everyone depends on.“ Mit diesem Satz eröffnet Anthropic die Ankündigung eines Programms, das sich ausdrücklich an Verteidiger richtet, nicht an Angreifer. Auffälliger als das Versprechen ist, was im selben Text danebensteht: Dieselben Modelle, die Schwachstellen aufspüren, lassen sich auch dafür missbrauchen, sie auszunutzen.

Cybersicherheit ist keine Produktkategorie, sondern eine Dauerbaustelle. Es gibt Werkzeuge, es gibt Budgets, und trotzdem stehen Lücken seit Jahren offen: weil Anlagen sich nicht abschalten lassen, und weil den Verteidigern die Mittel fehlen. Die Ankündigung löst diesen Widerspruch nicht mit einer einzelnen Funktion, sondern mit einer langfristigen Verpflichtung. Ein Bild hilft beim Einordnen: ein Haus, das niemals leer steht. Renovieren lässt es sich nur Zimmer für Zimmer, während darin gelebt und gearbeitet wird.

Zwei Säulen: Betriebstechnik und gemeinsamer Quellcode

Die Cyber Mission startet mit zwei Bereichen, die wenig gemeinsam haben und doch dasselbe Problem teilen. Auf der einen Seite steht kritische Infrastruktur: Stromnetze, Wasserwerke, Verkehrsnetze und staatliche Systeme, also Dinge, deren Ausfall nicht ärgerlich, sondern folgenreich ist. Auf der anderen Seite steht Open-Source-Software, jener frei verfügbare Code, auf dem fast jede moderne Anwendung aufsetzt, häufig gepflegt von kleinen Teams und Freiwilligen. In beiden Fällen geht es nicht um neue Angriffsflächen, sondern um alte, die über Jahre gewachsen sind.

Anthropic beschreibt die Ausgangslage selbst als unbefriedigend. Staatlich unterstützte Angreifer hätten über Jahre Fuß gefasst, in vielen Branchen, mit dem Ziel, Systeme im Ernstfall stören zu können. Die Verteidiger wiederum verfügen über jahrzehntelange Erfahrung, aber nicht über die Mittel, die diese Erfahrung verdient hätte. Dort setzt die Mission an: nicht mit einem fertigen Produkt, sondern mit Werkzeugen, Personal und Bedrohungsforschung.

Warum sich Kraftwerke nicht wie ein Laptop aktualisieren lassen

Stromnetze, Wasserwerke, Fabriken und Verkehrsnetze laufen auf speicherprogrammierbaren Steuerungen, Steuerungssoftware und industriellen Netzwerken, die auf Jahrzehnte ausgelegt sind. Diese Welt heißt operative Technologie, kurz OT, und sie unterscheidet sich in einem entscheidenden Punkt von gewöhnlicher IT: Sie lässt sich nicht einfach abschalten, um einen Patch einzuspielen. Bekannte Schwachstellen können deshalb jahrelang ungelöst bleiben, nicht aus Nachlässigkeit, sondern weil das Risiko eines Updates gegen das Risiko eines Ausfalls abgewogen wird.

Zurück zum Bild vom nie leeren Haus. Wer die Elektrik erneuern will, während im Erdgeschoss noch produziert wird, braucht jemanden, der weiß, welche Leitung zuerst dran ist und wann der Strom kurz weg sein darf. In der realen Welt sind das eine Handvoll spezialisierter Dienstleister: Die Anlagen sind proprietär, jede Änderung ist riskant, und ein Fehler kann ein ganzes Werk stilllegen. Betreiber jeder Größe verlassen sich auf diesen kleinen Kreis, der ihnen sagt, was exponiert ist und welche Korrekturen auf einem laufenden System vertretbar sind.

Das Critical Infrastructure Defense Program und seine Partner

Hier greift das Critical Infrastructure Defense Program, kurz CIDP. Es bringt nach Angaben von Anthropic drei Dinge zu diesen Dienstleistern: Frontier-Modelle von Claude, Ingenieure vor Ort und die eigene Bedrohungsforschung für kritische Infrastruktur. Als Gründungspartner nennt das Unternehmen Accenture, Booz Allen, CrowdStrike, Deloitte, Dragos, Hitachi, Insane Cyber, Nozomi Networks, Palo Alto Networks, PwC und Rockwell Automation. Die Auswahl ist kein Zufall: Es sind Beratungs- und Technologiekonzerne, die Sicherheitsprogramme betreiben, Sicherheitsfirmen, die Business- und Industrienetze schützen, sowie Hersteller, die die Geräte selbst bauen und pflegen.

Einige Partner arbeiten laut Ankündigung bereits mit Claude daran, Schwachstellen zu beheben. Die begleitenden Statements ordnen die Erwartungen unterschiedlich ein. PwC verweist auf die Schwere möglicher Folgen in OT-Umgebungen und fordert ein branchenweites, koordiniertes Vorgehen. CrowdStrike argumentiert, Angreifer nutzten KI mit Maschinengeschwindigkeit, weshalb Verteidigung ebenfalls mit Maschinengeschwindigkeit arbeiten müsse. Insane Cyber beschreibt das eigentliche Problem nüchtern: Die Orte, die den meisten Schutz brauchen, etwa abgelegene Umspannwerke, Offshore-Plattformen oder luftgetrennte Anlagen, sind genau die Orte, an denen klassische Werkzeuge nicht greifen und Spezialisten nicht hinkommen. Daten gebe es mehr, als ein Team abarbeiten könne; gefehlt hätten die Arbeitsstunden.

Anthropic selbst formuliert eine Einschränkung, die man festhalten sollte: Kritische Infrastruktur sei in vielerlei Hinsicht schwer zu verteidigen, und manches davon könne KI nicht lösen. Der erste Schritt ist bewusst klein gehalten, eine kleine Gruppe von Anbietern, um zu lernen, welche Strategien praktikabel sind. Firmen, die Sicherheitsprodukte für kritische Infrastruktur bauen, können ihr Interesse registrieren.

OSS Scanner: Schwachstellen im gemeinsamen Fundament

Der zweite Bereich betrifft Open-Source-Software, also den Code, der in fast jedem Produkt steckt und oft von kleinen Teams aus Freiwilligen gepflegt wird. Unter dem Namen Project Glasswing hat Anthropic nach eigenen Angaben hunderte viel genutzte Projekte gescannt, viele Funde von Menschen prüfen lassen und die Ergebnisse über den koordinierten Disclosure-Prozess vertraulich an die Maintainer gemeldet. Einige Projekte mit eigener Triage-Kapazität baten darum, alles zu erhalten, was die Modelle gefunden hatten, geprüft oder nicht.

Daraus ist OSS Scanner entstanden, ein Opt-in-Dienst nach dem Vorbild von Googles OSS-Fuzz. Teilnehmende Projekte bekommen regelmäßig Scans von den stärksten Modellen des Hauses, kostenlos. Jeder Bericht enthält einen Nachweis, wie sich der Fehler ausnutzen ließe, eine Erklärung und, wo möglich, einen Reparaturvorschlag. Die Berichte sind modellgeneriert und werden ohne menschliche Prüfung versandt. Das macht sie schneller, bedeutet aber auch, dass einzelne Angaben falsch sein können, etwa eine zu hohe oder zu niedrige Schweregrad-Einstufung. Anthropic erwartet eine Trefferquote von über 90 Prozent und will diese sowie die Qualität der Fixes mit der Zeit verbessern.

Der Dienst richtet sich an Projekte, die die Flut an Hinweisen überhaupt abarbeiten können. Für alle anderen bleibt es bei menschlich geprüften Meldungen. Als nächste Schritte nennt das Unternehmen: Funde schneller zu den Maintainern bringen, OSS Scanner auf mehr Projekte ausweiten, Triage und Patchen stärker automatisieren sowie neue, sicherere Architekturen und Programmierpraktiken erforschen. Finanziell unterstützt hat Anthropic unter anderem die Python Software Foundation, Alpha-Omega und OpenSSF über die Linux Foundation sowie die Apache Software Foundation, dazu Akrites und Gold Eagle, die Schwachstellenmeldungen sammeln und koordinieren. Kostenlos bleibt der Scanner über den im August gestarteten Defender Advantage Fund (0xDAF); Maintainer können zudem über Claude for Open Source kostenlose Claude-Max-Abos beantragen.

Von Glasswing zur Cyber Verification

Project Glasswing ist in dieser Woche in ein erweitertes Cyber Verification Program übergegangen, das deutlich mehr Verteidigern Zugang zu den leistungsfähigsten Modellen geben soll. Bereits im Juni hatte Anthropic ein Programm für staatliche und kommunale Verwaltungen aufgelegt und nach eigener Darstellung mehr als die Hälfte aller US-Bundesstaaten sowie einige der größten öffentlichen Betreiber kritischer Infrastruktur erreicht. Dort ging es um Code-Scans, Patch-Prozesse, Incident Response und Red-Team-Übungen.

Wichtiger als jede Partnerliste ist die Bilanz, die Anthropic aus Glasswing zieht: Die Partner hätten viele Schwachstellen gefunden, das Cyberrisiko sei aber noch nicht ausreichend gesunken. Es sei heute einfacher denn je, Schwachstellen zu finden, doch das Verifizieren, Priorisieren und Beheben der Funde bleibe schwierig. Das ist der ehrlichste Satz der Ankündigung, weil er den Kern des Problems benennt. Zwischen Fund und Fix vergingen bei Glasswing oft Monate; bei Betriebstechnik kann eine Korrektur warten müssen, bis sie sich sicher auf laufende Maschinen aufspielen lässt, in seltenen Fällen Jahrzehnte. Anthropics Prognose: In zwei Jahren werde KI die Verteidiger begünstigen, kurzfristig gelte das womöglich nicht. Ein Scanner, der mehr Hinweise liefert, als ein Team prüfen kann, verlagert Arbeit, statt sie zu erledigen. Für kritische Infrastruktur wie für Open-Source-Software gilt dasselbe: Entdeckung ist billig geworden, Verantwortung nicht.

Was das konkret bedeutet

Für Betreiber von Stromnetzen, Wasserwerken und Fabrikanlagen ändert sich kurzfristig wenig. Das CIDP arbeitet zunächst mit einer kleinen Gruppe von Dienstleistern, nicht direkt mit jedem Stadtwerk. Wer operative Technologie absichern muss, wird aber früher oder später mit Anbietern zu tun bekommen, die Claude einsetzen, und sollte dann genau fragen, was das Modell gefunden hat, wer die Funde bewertet hat und wer für die Entscheidung geradesteht, ein laufendes System zu verändern.

Für Open-Source-Projekte ist OSS Scanner ein kostenloses Angebot mit einem Haken, den man kennen sollte. Wer die Kapazität hat, Meldungen zu sortieren, bekommt Tempo. Wer sie nicht hat, bekommt weiterhin von Menschen geprüfte Meldungen. Die erwartete Trefferquote von über 90 Prozent klingt hoch, heißt in der Praxis aber auch: Bis zu jeder zehnte Bericht kann Aufmerksamkeit kosten, ohne Ertrag zu bringen, und auch zutreffende Berichte können Fehler enthalten, etwa beim Schweregrad. Bei einem Projekt mit zwei Maintainern in der Freizeit ist das eine echte Belastung.

Und es wäre naiv, darin reine Philanthropie zu sehen. Ein Anbieter von Frontier-Modellen braucht Zugang zu echten, sensiblen Umgebungen, um seine Fähigkeiten für Sicherheitsaufgaben zu belegen und zu verbessern. Das ist kein Vorwurf, sondern ein Interesse, das man benennen kann, während man die Werkzeuge nutzt. Was zählt, ist nicht die Ankündigung, sondern die Wartung danach. Häuser, in denen immer jemand wohnt, brauchen keine großen Reden, sondern Handwerker, die wiederkommen.

Quelle: anthropic.com

Google hat für BigQuery drei Suchfunktionen vorgestellt, die einem Gedanken folgen: Die Bedeutung eines Textes soll dort erschlossen werden, wo der Text liegt. Lange war das anders. Wer PDFs, Audiodateien oder Bilder auswerten wollte, baute eine zweite Welt daneben – einen Vector Store hier, eine LLM-Pipeline dort, dazu Skripte, die beide Seiten halbwegs synchron hielten. Google nennt diesen Zustand in der Ankündigung eine fragmentierte Architektur.

Die Ankündigung stammt aus dem Google-Cloud-Blog, geschrieben von Produktmanager Joe Malone und Engineering Manager Francis Lan, und erschien bereits am 8. August. Alle Leistungsangaben darin sind Herstellerangaben.

Der Ausgangspunkt ist ein Ungleichgewicht, das viele Unternehmen kennen. Strukturierte Daten in Tabellen lassen sich mit SQL sauber abfragen. Unstrukturierte Daten sammeln sich in Ablagen und wachsen schneller, als man sie erschließen kann. BigQuery will diese Trennung auflösen und Bedeutung, Suche und Auswertung im selben System zusammenführen. Wer verstehen will, was KI dabei leistet, sollte nicht mit den Modellen anfangen, sondern mit der Frage, wo die Daten liegen und wie man sie wiederfindet.

Die Bibliothek als Bild: warum zwei Suchwege nötig sind

Man kann sich das als Bibliothek vorstellen. Der eine Weg führt über den Zettelkasten: Man schlägt unter einem Stichwort nach und bekommt genau die Bücher, in denen dieses Wort steht. Der andere Weg führt über die Auskunft am Eingang: Man beschreibt, was man wissen möchte, und bekommt Bücher, in denen das gesuchte Wort gar nicht vorkommt, die aber inhaltlich passen. Beide Wege haben Stärken und blinde Flecken.

Die klassische Schlüsselsuche – in der Fachsprache lexikalische Suche – ist präzise und billig, aber sie ist wörtlich. Wer nach Behandlungen für fortgeschrittene Tumoren fragt, findet keine Dokumente, in denen nur von Chemotherapie die Rede ist. Die semantische Suche, also die Suche über Vektoren, versteht Bedeutungszusammenhänge und findet genau solche Dokumente. Dafür verliert sie die Genauigkeit bei Zeichenfolgen, die keine Bedeutung tragen – Bestellnummern, Produktcodes, Wirkstoffkürzel.

BigQuery setzt beide Wege nebeneinander und nennt das Hybrid Search. Für echte Unternehmensdaten ist das keine Spielerei, sondern notwendig. Reale Bestände enthalten immer beides: Prosa und Codes, Beschreibungen und Kennungen. Wer nur einen Weg anbietet, lässt regelmäßig die Treffer liegen, auf die es ankommt.

Embeddings, die sich von selbst aktualisieren

Damit semantische Suche funktioniert, braucht es Embeddings – Zahlenreihen, die den Inhalt eines Textes als Punkt in einem hochdimensionalen Raum abbilden. Ähnliche Inhalte liegen nahe beieinander, unähnliche weit auseinander. So findet eine Suche nach Behandlungen für fortgeschrittene Tumoren auch Dokumente über Chemotherapie – genau das Beispiel, das Google zeigt. Bisher musste man diese Embeddings selbst berechnen lassen, in einer eigenen Pipeline, mit Wiederholungsversuchen, Fehlerprotokollen und einer Warteschlange, die bei jedem neuen Datensatz anspringt.

Die nun allgemein verfügbare Funktion Autonomous Embedding Generation nimmt diesen Teil ab. Man definiert im Schema eine Spalte, und BigQuery erzeugt die Embeddings asynchron und fortlaufend, sobald neue Daten eintreffen. Die Modellwahl bleibt offen: entweder ein externes Modell wie die Text-Embeddings von Vertex AI oder ein Gemma-Modell direkt in BigQuery. Ändert sich der Quelltext, werden die Embeddings automatisch nachgezogen.

Ein Detail am Rand: Die Funktion unterstützt inzwischen auch Bilder, die über Objektverweise eingebunden sind. Damit wird multimodale Suche möglich, also die Suche über Text und Bild in einem Abfrageweg. Das klingt nach einem Zusatz, ist aber der Bruch mit der alten Architektur. Wer Bildinhalte durchsuchen wollte, brauchte bisher ein separates System mit eigener Indexierung.

AI.SEARCH: suchen in normaler Sprache

Auf den Embeddings sitzt die zweite Neuerung. AI.SEARCH erlaubt Suche in natürlicher Sprache, ohne dass man im Suchpfad selbst Embeddings erzeugen muss. Wer eine Suchanfrage stellt, will keine Vektorrechnung anstoßen, sondern ein Ergebnis sehen.

Google hat nach eigener Angabe die Ausführung einzelner Abfragen stark optimiert, wie sie vor allem in Online-Anwendungen und bei Agenten vorkommen, und berichtet dort von einer bis zu 133-fach besseren Slot-Effizienz. Slots sind die virtuellen Recheneinheiten, die BigQuery Abfragen zuteilt. Das ist ein Höchstwert des Herstellers, kein Durchschnitt. Er zeigt aber die Richtung: Der Ressourcenbedarf pro Suche sinkt, und davon hängt ab, ob sich viele gleichzeitige Suchanfragen von Nutzern direkt aus BigQuery bedienen lassen.

Dieselbe Modellkonfiguration wird verwendet, die schon für die Embeddings im Datensatz zuständig war. Das ist unspektakulär, aber wichtig. Ein häufiger Fehler in solchen Aufbauten: beim Indexieren ein anderes Modell nutzen als beim Suchen. Die Vektoren liegen dann in unterschiedlichen Räumen, und die Ergebnisse sind still falsch. Man merkt es nicht an einer Fehlermeldung, sondern daran, dass die Suche schlecht trifft.

Hybrid Search: wenn der Wirkstoffname kein Bedeutungsumfeld hat

Das eingängigste Beispiel in der Ankündigung ist ein Wirkstoffkürzel wie „MK3475“. Eine reine Vektorsuche tut sich damit schwer, weil eine solche Zeichenfolge kaum semantischen Gehalt besitzt. Sie ist ein Etikett, kein Begriff. Ein Forscher, der genau dieses Kürzel sucht, will keinen thematisch verwandten Treffer, sondern diesen einen. Hier greift Hybrid Search ein und kombiniert die lexikalische Übereinstimmung mit der semantischen Nähe.

Technisch geschieht das über Verfahren wie Reciprocal Rank Fusion und BM25 – zwei etablierte Algorithmen aus dem Information Retrieval, die Ranglisten zusammenführen und Worthäufigkeiten gewichten. Man muss sie nicht selbst implementieren. Es hilft aber zu wissen, dass hier keine neue Zauberei am Werk ist, sondern jahrzehntealte Suchtechnik, neu verdrahtet. In der Praxis aktiviert man den Hybridmodus in den Funktionen AI.SEARCH und VECTOR_SEARCH über den Parameter mode => ‚HYBRID‘ oder lexical_search_columns. Für mehr Tempo lassen sich die Vektorindizes um die Schlüsselwortspalten erweitern.

Ein zweiter Effekt, den Google hervorhebt: Durch das Neusortieren der Treffer nach Schlüsselwort und Bedeutung sinkt die Zahl der Fehlinformationen, die ein Sprachmodell später verarbeitet. Man nennt das Halluzinationen, und ihre Kosten sind nicht nur inhaltlicher Natur. Jeder unnötige Dokumentkontext, der in ein Modell fließt, verbraucht Rechenzeit und Geld. Gute Suche ist damit auch eine Kostenmaßnahme.

Der komplette Weg von der PDF-Datei bis zur Antwort

Die drei Neuerungen sind Teil eines größeren Ablaufs, den Google in fünf Schritten beschreibt: Access, Process, Ground, Relate, Activate. Im ersten Schritt werden PDFs und Dokumente direkt dort abgefragt, wo sie liegen – über Objekttabellen in Google Cloud Storage, ohne vorherige Kopie. Im zweiten Schritt kommen Funktionen zum Einsatz, die Dokumente layoutgerecht zerlegen (die Funktion dafür ist erst angekündigt), Entitäten extrahieren, zusammenfassen und klassifizieren. Das geschieht innerhalb der SQL-Pipeline, nicht in einem separaten Werkzeug.

Der dritte Schritt – Ground – ist der, um den sich die drei Ankündigungen drehen: Embeddings und Hybridsuche erzeugen den inhaltlich belastbaren Kontext, auf dem ein Sprachmodell sinnvoll arbeiten kann. Im vierten Schritt werden extrahierte Entitäten wie Studien, Sponsoren und Medikamente in einen Graphen überführt, um verborgene Zusammenhänge sichtbar zu machen, ohne eine spezialisierte Graphdatenbank zu betreiben. Der fünfte Schritt bringt alles in eine dialogfähige Oberfläche, in der man mit den Daten spricht und Auswertungen erzeugen lässt.

Für Einsteiger ist vor allem die Reihenfolge lehrreich. Viele beginnen mit dem Modell und wundern sich, dass die Antworten unzuverlässig sind. Der Hebel liegt weiter vorn: Welche Daten sind zugänglich, und wie präzise findet man sie wieder? Das ist weniger spektakulär als ein neues Sprachmodell, entscheidet aber über das Ergebnis.

Was das konkret bedeutet – und wo die Grenzen liegen

Google wirbt damit, dass BigQuery komplexe Vektordatenbanken von Drittanbietern überflüssig mache. So pauschal stimmt das nicht, spezialisierte Vektorsuche hat weiterhin ihren Platz. Aber ein Teil der typischen KI-Anwendungen kommt ohne eigene Vektordatenbank aus, wenn das Data Warehouse die Aufgabe übernimmt. Für Unternehmen bedeutet das weniger bewegliche Teile: keine zweite Kopie der Daten, keine Synchronisationslogik, kein eigener Dienst, der nachts ausfällt. Weniger Architektur ist fast immer ein Vorteil, weil jede zusätzliche Komponente betrieben, überwacht und bezahlt werden muss.

Zugleich sollte man die Reifegrade auseinanderhalten. Embedding-Erzeugung und AI.SEARCH sind allgemein verfügbar, Hybrid Search ist in öffentlicher Vorschau. Wer darauf produktiv aufsetzen will, sollte Schnittstellen und Verhalten beobachten, denn in Vorschaufunktionen ändern sich Details noch. Und keine Technik ersetzt eine durchdachte Datenvorbereitung: Wie man Dokumente zerlegt, welche Spalten man indexiert, welche Metadaten man mitführt – diese Entscheidungen wirken stärker auf die Trefferqualität als die Wahl des Modells.

Eine Grenze verschiebt sich, die lange selbstverständlich schien. Unstrukturierte Daten waren der Sonderfall, den man irgendwie daneben verwaltete; jetzt werden sie ein normaler Teil der Abfragesprache. Wer KI-Anwendungen baut, wird künftig häufiger über Indexierung, Zerlegung und Trefferlisten sprechen als über Modellparameter. Weniger spektakulär, aber hier entscheidet sich, ob die Suche funktioniert.

Quelle: cloud.google.com

Im Log einer Citrix NetScaler ADC tauchen Meldungen auf, die nach einem abgestürzten Prozess aussehen: Die Paketverarbeitungs-Engine habe sich mit „unexpectedly died“ verabschiedet oder „missed too many heartbeats“. Solche Zeilen bedeuten nicht zwingend ein technisches Problem. Sie können auch heißen, dass gerade jemand über die Protokolldatei der Appliance Befehle einschleust.

Diesen Angriffsweg beschreibt ein Advisory, das das Sicherheitsunternehmen Sygnia am 28. September 2026 veröffentlicht hat. Sygnia verkauft selbst Incident-Response-Dienste und empfiehlt sich am Ende des Berichts auch dafür. Der Bericht mit dem Titel „Actively Exploited NetScaler Vulnerabilities“ stützt sich auf öffentliche Meldungen und ergänzt sie um Beobachtungen aus laufenden Felduntersuchungen, Eindämmungs- und Wiederherstellungsarbeiten. Die Empfehlung der Autoren Omer Kidron, Roey Bartov, Josh Geise und Avishay Asido fällt deutlich aus: Wer NetScaler ADC oder NetScaler Gateway selbst betreibt, soll die Appliances unverzüglich patchen, nach einer möglichen Kompromittierung suchen und den Zugriff der Geräte auf sensible interne Systeme einschränken.

Der Grund für diesen Ton liegt in der Rolle, die solche Appliances im Netz spielen. Sie stehen im Internet und bilden gleichzeitig eine Vertrauensgrenze nach innen: Sie sprechen mit Authentifizierungssystemen, Virtualisierungsplattformen, Backup-Infrastruktur und Management-Werkzeugen. Wer eine solch exponierte Appliance übernimmt, erbt einen Teil ihres Vertrauens. Aus einer Schwachstelle wird dann kein Patch-Eintrag mehr, sondern ein möglicher Sicherheitsvorfall.

Was Citrix am 27. September 2026 veröffentlicht hat

Citrix hat am 27. September 2026 das Bulletin CTX697096 veröffentlicht und darin acht Schwachstellen adressiert. Zwei davon sind zentral, weil sie in freier Wildbahn ausgenutzt wurden: CVE-2026-88771 und CVE-2026-88772, beide mit einem CVSS-v4-Wert von 9,5. Die US-Behörde CISA hat beide in ihren Katalog der bekannt ausgenutzten Schwachstellen aufgenommen und von einer globalen Ausnutzung berichtet. Bei den übrigen sechs Lücken handelt es sich um konfigurationsabhängige Probleme, für die Citrix keine aktive Ausnutzung gemeldet hat.

Unbequem ist vor allem, dass CVE-2026-88771 keine optionale Funktion voraussetzt. Die Lücke betrifft alle selbst betriebenen NetScaler-ADC- und NetScaler-Gateway-Installationen, unabhängig davon, ob zusätzliche Module aktiviert wurden. Betroffen ist deshalb jede Umgebung mit einer solchen Appliance am Netz, nicht nur große Konzerne. Ein Patch ist verfügbar. Aber verfügbar heißt nicht eingespielt.

Die vergiftete Meldung: wie CVE-2026-88771 technisch funktioniert

Stell dir die Appliance als Pförtner eines Gebäudes vor, der ein Wachbuch führt. Jeder Vorfall wird dort eingetragen, und später liest ein Hausmeister das Buch, um Reparaturen anzustoßen. Das ist praktisch, solange alle Einträge echt sind. Hier setzt CVE-2026-88771 an: Ein nicht authentifizierter Angreifer kann über eine Anfrage Daten liefern, die als gefälschte Fehlermeldung der Paketverarbeitungs-Engine in ein NetScaler-Log geschrieben werden. Der Angreifer kontrolliert also den Inhalt einer Zeile, die später als technische Information gelesen wird.

Das legitime Wartungsskript /netscaler/ns_monuploadd_err.pl verarbeitet eine solche vergiftete Zeile anschließend mit einer unsicheren Shell-Operation. Der eingebettete Befehl wird dabei mit Root-Rechten ausgeführt. Damit ist die Kette geschlossen: von einer nicht authentifizierten Anfrage bis zur vollständigen Kontrolle über das Gerät. Wichtig ist der Zeitversatz. Die Verarbeitung kann verzögert stattfinden, weshalb Verteidiger die ursprüngliche Anfrage mindestens 24 Stunden lang mit der Systemaktivität abgleichen sollten. Wer nur das Zeitfenster der Anfrage betrachtet, übersieht die Ausführung.

Die zweite aktiv ausgenutzte Lücke, CVE-2026-88772, folgt einer anderen Mechanik. Hier handelt es sich um einen Speicherüberlauf, der zu Remote-Code-Ausführung oder einem Denial of Service führen kann, wenn DTLS aktiviert ist – auf VPN-vServern ist das die Voreinstellung. Die übrigen sechs Lücken des Bulletins reichen von HTTP Request Smuggling bis zu vorhersagbaren TCP-Sequenznummern und greifen nur bei bestimmten Konfigurationen.

Was ein Angreifer nach erfolgreicher Ausnutzung erreichen kann

Ein erfolgreicher Zugriff auf die Appliance ist erst der Anfang. Laut dem Advisory kann ein Angreifer beliebige Befehle als Root ausführen, Web-Shells oder andere Persistenzmechanismen in webzugänglichen Verzeichnissen ablegen und die Apache- sowie NetScaler-Konfiguration so verändern, dass ausführbarer Inhalt getarnt wird. Zusätzlich gelangt er an Zertifikate, Token, Zugangsdaten und gemeinsam genutzte Geheimnisse, die auf der Appliance liegen oder über sie laufen. Und er kann die vertrauenswürdige Netzwerkposition des Geräts nutzen, um auf Identitäts-, Virtualisierungs-, Backup- und Management-Systeme zuzugreifen. Verkehr kann über die Appliance geleitet oder getunnelt und die Sichtbarkeit durch Manipulation der Protokollierung reduziert werden.

Sygnia beschreibt dazu eine eigene Feldbeobachtung. Noch bevor Citrix korrigierte Builds veröffentlichte, untersuchte das Team eine Remote-Code-Ausführung durch einen Angreifer auf einer NetScaler-Appliance, die zum damaligen Zeitpunkt mit der aktuellsten verfügbaren Herstellerversion lief. Die anschließenden Aktivitäten reichten bis in Virtualisierungs- und Identitätsinfrastruktur hinein. Der ursprüngliche Zugriffsweg ließ sich nicht abschließend klären, und Sygnia schreibt den Vorfall ausdrücklich nicht den neu veröffentlichten CVEs zu. Der Fall zeigt dennoch, wie groß der Wirkungsradius einer kompromittierten Edge-Appliance sein kann.

Die ersten 24 Stunden: NetScaler ADC und Gateway patchen

Die Sofortmaßnahmen folgen einer klaren Reihenfolge. Zuerst wird jede Instanz aktualisiert, also aktive Knoten, Standby-Knoten, Disaster-Recovery-Systeme, FIPS- und NDcPP-Knoten, jeweils auf einen korrigierten Build oder eine spätere Version desselben Zweigs. Laut Advisory sind das mindestens 14.1-73.37 und 13.1-64.23, für die FIPS- und NDcPP-Varianten 14.1-73.37 FIPS bzw. 13.1.37.279. Wer auf 13.1-64.23 geht, soll vorher mit show ns variable prüfen, ob Variablen konfiguriert sind, und in diesem Fall 13.1-64.24 oder später einspielen. Parallel dazu müssen Beweise gesichert werden, bevor irgendetwas neu gestartet oder neu aufgebaut wird: Appliance-Logs, NetScaler-Console, Firewall-, Authentifizierungs-, Netzfluss- und externe Syslog-Daten. Danach folgen die Kompromittierungsprüfungen, etwa der IoC-Scan von Citrix oder die Rücksprache mit dem Support. Ein negatives Ergebnis ist kein Freispruch, es fehlt nur ein Hinweis.

Dazu kommt die retrospektive Suche. Mindestens 30 Tage rohe NetScaler-Logs sollten durchgesehen und verdächtige Authentifizierungs- oder HTTP-Aktivitäten mit Host- und Netzwerkereignissen der folgenden 24 Stunden korreliert werden. Gleichzeitig gehört die Angriffsfläche reduziert: Management-Dienste dürfen nicht aus dem Internet erreichbar sein, und für die Appliance selbst sollten strikte Allow-Lists für ein- und ausgehenden Verkehr gelten. Wer Exploit-Payloads, Web-Shell-Artefakte, unerklärliche ausgehende Verbindungen oder unautorisierte Konfigurationsänderungen findet, isoliert das Gerät und startet die Incident-Response. Wurden Web-Shells identifiziert, müssen alle aktiven Citrix-Sitzungen beendet und Sitzungstoken ungültig gemacht werden. Das reine Löschen der Shells genügt nicht, denn bereits etablierte Sitzungen laufen sonst weiter.

Die nächsten 72 Stunden: verbundene Systeme, Geheimnisse, Neuaufbau

Innerhalb von drei Tagen verschiebt sich der Fokus von der Appliance auf ihre Nachbarschaft. Bei verdächtiger Aktivität gehören Identitätsanbieter, Domain-Controller, vCenter, ESXi, Jump-Hosts und Backup-Infrastruktur auf den Prüfstand, also alles, was von der Appliance aus erreichbar war. Parallel werden Zugangsdaten, Token, Zertifikate, Schlüssel und gemeinsam genutzte Geheimnisse widerrufen oder rotiert, sofern sie auf dem potenziell kompromittierten Gerät lagen oder über es verwendet wurden. Zusätzlich sollte die Konfiguration der NetScaler-Appliances durchgesehen werden, einschließlich Startvorgang, Boot-Skripten und geplanten Aufgaben. Schadcode kann auch dort eingebettet oder referenziert sein.

Lässt sich eine erfolgreiche Befehlsausführung nicht ausschließen, ist der Neuaufbau aus einem sauberen Image mit validierter Konfiguration aus der Zeit vor dem Vorfall besser als ein weiterer Patch. Zudem sollten die Vertrauenspfade verkleinert werden, sodass nur noch die wirklich benötigten Verbindungen von NetScaler zu internen Identitäts-, Virtualisierungs-, Backup- und Management-Diensten bestehen. Und die Überwachung braucht eine Selbstkontrolle: rohe Management-, Authentifizierungs-, HTTP-Zugriffs-, Shell-, Audit- und Konfigurationsänderungslogs müssen extern weitergeleitet werden, mit Alarmierung, wenn die Weiterleitung abbricht. Bei begründetem Verdacht gilt: erst isolieren und Beweise sichern, dann die erreichbaren Systeme untersuchen und erst danach destruktiv aufräumen.

Worauf die Logs hinweisen

Dieser Angriff hinterlässt Spuren. Ausnutzungsversuche können als gefälschte PPE-Fehlermeldungen erscheinen, die vom Angreifer kontrollierte Shell-Befehle enthalten. Auffällig sind dabei Formulierungen wie „unexpectedly died“ und „missed too many heartbeats“. Sygnia berichtet zusätzlich von einer Variante, die in neuerer Telemetrie auftauchte: Ein weiteres „unexpectedly died“-Muster diente dem Versuch, Konfigurationen offenzulegen, entfernte Payloads auszuführen und die Befehlsausführung zu validieren. Wer solche Zeilen im Log sieht, sollte sie als möglichen Angriffsindikator behandeln, nicht als Betriebsstörung. Auch eine HTTP-404-Antwort macht eine solche Anfrage nicht harmlos: Es genügt, dass sie im Log landet, damit ein später eingeschleuster Befehl den dort abgelegten Inhalt wieder hervorholen und ausführen kann.

Für die Härtung heißt das: erst patchen, den Patch aber als Arbeitsbeginn verstehen. Danach prüfen, ob vor dem Patch jemand auf dem Gerät war. Angriffsfläche verkleinern, Geheimnisse rotieren und neu aufbauen, wenn Zweifel bleiben. Das ist die Kernaussage des Advisorys: Das Aktualisieren schließt die Schwachstelle, entfernt aber weder einen Angreifer noch eine Web-Shell, eine veränderte Konfiguration, ein gestohlenes Geheimnis oder einen Persistenzmechanismus. Schwachstellen dieser Art lassen sich also nicht mit einem Wartungsfenster erledigen. Wer sie beheben will, muss zwei Fragen beantworten: Ist das Gerät aktuell, und war es vorher schon kompromittiert? Die zweite Frage ist unangenehmer – und wichtiger.

Quelle: sygnia.co