Kategorie: Einblicke

Ein Parser liest eine Quelldatei und zerlegt sie in einen Strom von Syntaxknoten. Ein Algorithmus entscheidet dann, welche Knoten zu einer Einheit verschmelzen und welche getrennt bleiben.

Das sieht nach unspektakulärer Vorarbeit aus, entscheidet aber, ob ein KI-Codeagent später die passende Funktion findet oder an einer Handvoll bedeutungsloser Zeilen hängen bleibt. Adam Malek und Ashot Kazaryan aus dem Team hinter Air Context, dem Codesuch-Dienst von JetBrains, beschreiben diesen Weg in einem Entwicklertagebuch auf dem Firmenblog. Wer an einer RAG-Pipeline für semantische Codesuche baut, findet darin Entscheidungen, die man sonst erst nach mehreren Fehlversuchen trifft. Der erste Teil der Reihe behandelt die Anfänge: Parsing und Chunking von Quellcode sowie die Vektorisierung. Die Ausgangsbeobachtung der Autoren ist nicht exotisch.

Warum grep die Frage nach dem Sitzungstoken-Refresh nicht beantwortet

Ein Agent, der ein Feature in einer großen Codebasis umsetzen soll, verbringt einen großen Teil seiner Laufzeit damit, die relevanten Stellen zu finden. Sein übliches Werkzeug ist die Textsuche. Deren Grenze liegt nicht in der Geschwindigkeit, sondern in der Voraussetzung: Wer sucht, muss wissen, welcher exakte Text in der Datei steht. Bei abstrakten Fragen ist das selten der Fall.

Die Autoren führen ein Beispiel an. Ein Agent, der wissen will, wo abgelaufene Sitzungstoken erneuert werden, kann nicht darauf bauen, dass im Code das Wort „refresh“ auftaucht. Die zuständige Funktion kann völlig anders heißen, in eine Hilfsklasse ausgelagert sein oder über mehrere Schichten verteilt arbeiten. Keywords und Textsuche finden nur, was sie schon kennen.

Semantische Codesuche mit Retrieval Augmented Generation dreht die Richtung um. Gesucht wird nach Bedeutung, nicht nach Zeichenketten. Lässt sich der Quellcode so indexieren, dass seine Semantik erhalten bleibt, kann der Agent per Freitextabfrage die Ausschnitte abrufen, die für seine Aufgabe zählen. Für die Autoren entsteht damit eine Schnittstelle, die zu den Stärken eines Sprachmodells passt. Der Prototyp einer solchen Pipeline ist schnell gebaut. Bis zur Produktionsreife ist es ein weiter Weg.

Chunking: Warum feste Zeilenblöcke den Code an der falschen Stelle zerreißen

Man kann sich eine solche Pipeline wie ein Archiv vorstellen, in dem Akten nicht nach Aktenzeichen, sondern nach Inhalt abgelegt werden. Dann hängt alles daran, was als eine Akte gilt. Ist die Akte zu groß, findet man in ihr nichts wieder; ist sie zu klein, steht in ihr nichts, was sich lohnt.

Übertragen auf Quellcode heißt das: Eine ganze Datei als eine Einheit zu vektorisieren, wäre selbst dann wenig sinnvoll, wenn das Embedding-Modell die Länge verkraften würde. Die Suche gäbe die komplette Datei zurück, während es dem Agenten um eine bestimmte Funktion, ein Symbol oder einen kurzen Ausschnitt geht. Jede einzelne Zeile zu indizieren, führt in die andere Richtung ins Leere: Eine Zeile ohne Kontext trägt oft keine Bedeutung, ein generischer Funktionsname oder ein Kommentarfragment erzeugt Treffer, die niemand braucht. Der Agent versinkt in Micro-Ergebnissen.

Der naheliegende Kompromiss, eine Datei in Blöcke fester Zeilenzahl zu schneiden, funktioniert laut den Autoren nicht. Solche Blöcke gruppieren Unzusammenhängendes, etwa eine Import-Anweisung mit dem Rumpf einer Funktion. Das Ergebnis sind semantisch falsche Einheiten, und die Fehler wandern direkt in die Suche. Der Ausweg liegt in der Struktur, die jeder Quellcode ohnehin besitzt: Importe stehen meist oben, danach folgt eine Klassendefinition mit optionalem Dokumentationskommentar, darin Felder und Methoden, die wiederum eigene Kommentare tragen können.

Syntaxknoten, Präfixe, Normalisierung: Wie Air Context Chunks bildet

JetBrains arbeitet nach eigener Darstellung seit 26 Jahren an Parsern, die die Eigenheiten, Konventionen und Unebenheiten einzelner Sprachen abbilden. Diese Parser bilden zusammen mit weiteren Werkzeugen die interne Plattform Code Engine, auf der auch Air Context aufsetzt. Im beschriebenen Stand unterstützt Air Context Parsing und strukturbewusstes Chunking für neun große Sprachen: Kotlin, Java, Python, JavaScript, TypeScript, C#, PHP, Go und Rust. Für alle übrigen Sprachen fällt die Implementierung auf eine naive, zeilenbasierte Aufteilung zurück, damit grundsätzlich jede Datei indexierbar bleibt.

Der Parser zerlegt eine Datei in einen Strom von Syntaxknoten, die mitteilen, was sie repräsentieren: Kommentare, Leerraum, Modifikatorlisten und so weiter. Der Chunking-Algorithmus liest diesen Strom und entscheidet anhand von Typ, Größe und Unterknoten über den Umfang eines Chunks. Überschreitet ein Knoten die Größenschwelle und hat keine Kinder, greifen primitivere Aufteilungsstrategien. Einige sprachspezifische Konstrukte bleiben dagegen auch dann eine Einheit, wenn sie größer sind als erwünscht. Präfixe wie Dokumentationskommentare, Annotationen, Sichtbarkeitsmodifikatoren und Schlüsselwörter bleiben bei der Deklaration, schließende Syntax bleibt bei dem Konstrukt, das sie abschließt.

Hinzu kommt eine sprachspezifische Bereinigung. Häufige, semantisch wenig aussagekräftige Java-Annotationen wie @NotNull oder @Override werden entfernt. Die Autoren verweisen auf eine Ähnlichkeit zu cAST von Zhang und Kollegen aus dem Jahr 2025: Beide Verfahren behalten die größten Syntaxeinheiten, die noch passen, unterteilen nur die zu großen und gruppieren kleine benachbarte Einheiten, um Mini-Chunks zu vermeiden. Der Unterschied liegt nach eigener Darstellung in der Menge der einprogrammierten Sprachsemantik. Python-Dekoratoren bleiben bei ihren Definitionen, KDoc-Kommentare stehen neben ihren Kotlin-Deklarationen.

Nach dem Gruppieren folgt die Normalisierung: führender und abschließender Leerraum verschwinden, Leerzeilen werden gelöscht, gemeinsame Einrückung wird entfernt, während die relative Einrückung erhalten bleibt. Anschließend wandert der Chunk zusammen mit Metadaten in den nächsten Schritt, darunter der relative Pfad der Quelldatei, der gemeinsam mit dem normalisierten Inhalt eingebettet wird.

Ob ein Chunk wirklich gut geschnitten ist, lässt sich nicht rein formal entscheiden. Die Autoren setzen daher auf ein Sprachmodell als Richter. Es bekommt den Chunk und die Quelldatei zu sehen und beurteilt, ob die Grenze sinnvoll ist. Auffällig sind für den Richter abgelöste Dokumentation, verwaiste schließende Syntax oder Code, der mitten durch ein bedeutungstragendes Konstrukt geschnitten wurde. Jede Änderung an der Verarbeitungskette durchläuft zusätzlich eine vollständige Retrieval-Evaluierung von Ende zu Ende.

Vektorisierung: Bedeutung als Position in einem Raum aus tausend Dimensionen

Aus den vorbereiteten Textstücken wird schließlich eine Repräsentation, die semantische Suche ermöglicht. In der Vektorisierung liest ein Embedding-Modell ein Stück Text und gibt eine Liste fester Länge zurück, einen Vektor. Dieser Vektor ist ein Punkt in einem Raum mit einigen tausend Dimensionen. Trainiert ist das Modell so, dass Texte mit ähnlicher Bedeutung nahe beieinander landen.

Was in der klassischen Suche unsichtbar bleibt, wird hier zur Nachbarschaft. Eine Funktion, die gepufferte Schreibvorgänge ausleert, und eine, die eine anstehende Warteschlange abarbeitet, teilen womöglich kein einziges Schlüsselwort und liegen im Vektorraum trotzdem dicht beieinander. Der Abstand zwischen Vektoren wird damit zum Maß für Verwandtschaft. Eine Suchanfrage wird in dieselbe Position im Raum übersetzt, und zurück kommt, was am nächsten liegt.

Die Rechnung pro Byte: Warum Vektoren zum Kostenfaktor werden

Code-Vektorisierung für KI-Agenten ist zunächst billig und wird im Großen teuer. Ein einzelnes Embedding kostet fast nichts, doch ein großes Repository erzeugt Millionen von Chunks und damit Millionen von Vektoren, die gespeichert, im Arbeitsspeicher gehalten und bei jeder Anfrage verglichen werden müssen. Ein Vektor mit einigen tausend Dimensionen in 32-Bit-Gleitkommazahlen wiegt rund 16 Kilobyte. Ein paar Millionen Chunks summieren sich auf mehrere zehn Gigabyte Index, noch bevor irgendeine Verwaltungsstruktur dazukommt.

Ab dieser Größenordnung verschiebt sich die Leitfrage. Statt „Wie genau können wir werden?“ lautet sie: „Was bekommen wir pro Byte?“ Die Autoren nennen zwei Hebel, die unabhängig voneinander wirken und sich kombinieren lassen. Der erste ist, weniger Dimensionen zu behalten. Moderne Embedding-Modelle sind so trainiert, dass ein führender Abschnitt des Vektors für sich funktioniert; beim Training wird die Verlustfunktion über mehrere verschachtelte Präfixlängen gleichzeitig angewandt, sodass die grobe Struktur in den vordersten Dimensionen landet. Du kannst einen Vektor also abschneiden, neu normalisieren, und er sucht weiterhin. Der zweite Hebel lässt alle Dimensionen stehen und spart an jeder einzelnen, indem Präzision geopfert und pro Vektor weniger Bytes vorgehalten werden. Beide Wege sind keine Notlösung, sondern eine Budgetentscheidung.

Welche Mischung bei gleichem Budget besser sucht, zeigen die Autoren an einem Beispiel. 512 Byte pro Vektor reichen entweder für 128 Dimensionen in voller 32-Bit-Genauigkeit oder für alle 4.096 Dimensionen mit je einem einzigen Bit. Beide Varianten passen exakt ins Budget, im Test findet die zweite aber deutlich besser. Ihre Erklärung: Jede Dimension ist wie eine kleine Frage, die das Modell an den Text stellt – geht es um Fehlerbehandlung, um Netzwerkzugriffe, um Testcode? Wer auf 128 Dimensionen kürzt, behält sehr genaue Antworten auf drei Prozent der Fragen und wirft den Rest weg. Ein Bit pro Dimension bewahrt dagegen auf jede Frage eine grobe Ja-oder-Nein-Antwort. Ein langer Fragebogen mit Häkchen schlägt einen kurzen, der auf sechs Nachkommastellen ausgefüllt ist.

Air Context geht deshalb bis zum Äußersten: Jede Komponente ab null wird zur Eins, jede negative zur Null, die Beträge entfallen. Der Vektor ist damit 32-mal kleiner als in 32-Bit-Gleitkommazahlen – deutlich radikaler als Verfahren wie turbovec, das mit einem Achtel des Speichers auskommt. Mit der Darstellung ändert sich auch das Maß. Die Kosinus-Ähnlichkeit braucht die verworfenen Beträge, verglichen wird deshalb per Hamming-Distanz, also über die Zahl der Stellen, an denen sich zwei Bitmuster unterscheiden. Ein Vektor mit 4.096 Bit liegt als 64 Wörter zu je 64 Bit im Speicher; ein Vergleich besteht aus XOR und dem Zählen der Einsen, insgesamt in der Größenordnung von hundert Prozessorbefehlen statt Tausender Multiplikationen.

Den Preis nennen die Autoren offen: Die binäre Quantisierung kostet einige Punkte Recall gegenüber den unkomprimierten Vektoren. Sie nehmen das in Kauf, weil ein Agent die Ergebnisse liest und nicht ein Mensch. Für den Agenten zählt, dass die relevanten Dateien unter den ersten zwölf Treffern auftauchen; ob der beste Chunk auf Platz zwei oder fünf landet, ändert nichts, weil er die Kandidaten ohnehin öffnet. Eine zweite Grenze zeigte sich erst später: Die Bitvektoren stauchen die Spanne der Ähnlichkeitswerte. Zwei völlig unverwandte Vektoren stimmen schon zufällig in etwa der Hälfte der Bits überein, ein eng verwandtes Paar vielleicht in zwei Dritteln. Für eine Rangfolge reicht das, für einen Schwellenwert nicht. Wo ein Index absolut entscheiden muss, ob etwas relevant ist – etwa für eine Funktion, die ungefragt passenden Code vorschlägt und wissen muss, wann sie schweigt –, behält Air Context 16-Bit-Gleitkommazahlen und zahlt für den Speicher.

Dateipfade kürzen, Quellcode nicht speichern

Beim Einbetten trennt das Team Indexierung und Suche. Die Indexierung ist auf Durchsatz ausgelegt, eine GPU verarbeitet etwa 32 Chunks pro Batch, bevor sie ausgelastet ist. Die Suche muss dagegen innerhalb weniger Sekunden antworten. Eingesetzt wird ein Modell, das Anweisungen befolgt und beide Seiten unterschiedlich behandelt: Code-Chunks werden eingebettet, wie sie sind, einer Suchanfrage wird eine Anweisung vorangestellt, die sinngemäß lautet, zu dieser Anfrage den passenden Code zu finden.

Jeder Chunk wird zusammen mit seinem Dateipfad eingebettet, weil der Pfad verrät, in welchem Modul der Code liegt und was die Datei ist. In einem Monorepo wird das zum Problem. Das Monorepo von IntelliJ IDEA umfasst mehr als eine Million Dateien, die mittlere Quelldatei liegt neun Verzeichnisse tief hinter einem Pfad von 91 Zeichen, knapp 10.000 Dateien haben Pfade über 150 Zeichen, der längste misst 218 – die Datei an seinem Ende ist 24 Zeilen lang. Air Context kappt deshalb jeden Pfad, bevor er das Modell erreicht, und behält beide Enden: vorn die Segmente, die das Modul benennen, hinten Elternverzeichnis und Dateiname. Die Mitte fällt weg, so viel wie nötig. Schränkt jemand die Suche auf ein Verzeichnis ein, landet dieser Bereich in derselben gekürzten Form im Anfragetext, statt die Treffer nachträglich zu filtern.

Zum Schluss beschreiben die Autoren zwei Vorgaben zum Schutz des Quellcodes. Gespeichert wird kein Code, nur Koordinaten: ein Verweis, der Typ, der Dateipfad, Start- und End-Offset und ein Verweis auf den Vektor. Der Ausschnitt, den ein Nutzer sieht, wird erst auf seinem Rechner aus seinem eigenen Checkout zusammengesetzt. Eingebettet wird mit einem Open-Weight-Modell auf GPUs, die JetBrains selbst betreibt; keine Anfrage geht an OpenAI, Google oder andere Anbieter. Nach eigenen Benchmarks schnitt das offene Modell dabei besser ab als die gehosteten Embedding-APIs der großen Anbieter – eine Messung des Herstellers in eigener Sache.

Was von den Feldnotizen für den eigenen Aufbau bleibt

Der praktische Kern des Berichts lässt sich in wenigen Sätzen zusammenfassen. Die Qualität einer RAG-Pipeline für semantische Codesuche entscheidet sich früher, als die meisten erwarten – nicht im Modell, sondern an der Chunk-Grenze. Strukturbewusstes Parsing schlägt jede Aufteilung nach Zeilenzahl, weil es die Konventionen einer Sprache kennt und zusammengehörige Deklarationen zusammenhält. Wo diese Kenntnis fehlt, ist ein zeilenbasierter Rückfall immer noch besser als eine Lücke im Index.

Bewertung ist kein nachträglicher Prüfschritt. Ein Sprachmodell als Richter über Chunk-Grenzen und eine Ende-zu-Ende-Messung des Retrievals gehören zum Bau der Pipeline, nicht in eine Schublade daneben. Und beim Speicher wird es ernst: Wer semantische Codesuche über eine große Codebasis anbietet, betreibt ein Budgetproblem, in dem Genauigkeit, Speicherbedarf und Antwortzeit gegeneinander verrechnet werden. Die Antwort von Air Context: lieber alle Dimensionen mit einem Bit als wenige in voller Genauigkeit – und 16 Bit nur dort, wo ein Schwellenwert gebraucht wird.

Der Bericht ist der erste Teil einer Reihe. Offen sind noch die effiziente Speicherung der Millionen Bitvektoren, Antworten in Millisekunden, die laufende Evaluierung und die Frage, wie man den Agenten dazu bringt, die Suche tatsächlich zu nutzen. Das dürfte für jeden interessant sein, der semantische Codesuche als Dienst betreiben will. Air Context selbst ist als öffentliche Vorschau bereits in JetBrains-Lizenzen enthalten. Wer selbst baut, sollte aus diesem ersten Teil vor allem eines mitnehmen: Erst den Code verstehen, dann die Vektoren.

Quelle: blog.jetbrains.com

Wer mit Claude Code arbeitet, hinterlässt bei jeder Sitzung eine Datei mit dem kompletten Gesprächsverlauf, abgelegt in einem versteckten Ordner auf der Platte. Nach 30 Tagen löscht Claude Code sie standardmäßig, und in den meisten Teams fällt das niemandem auf.

Code kommt in ein Git-Repository, die Transkripte agentischer Coding-Sessions landen im Nichts, obwohl sie belegen, welche Tokens bezahlt wurden und welche Lektionen man sonst teuer nachlernt. So argumentiert Jacek Migdal von Quesma im Blog seines Unternehmens. Quesma bietet selbst ein Werkzeug an, das solche Sessions einsammelt; der Beitrag ist also auch Werbung in eigener Sache, das Werkzeug wird am Ende dieses Textes vorgestellt.

Bevor es Observability gab, hat man sich per ssh auf den Server gesetzt und nach einem Absturz die Logs durchsucht. Auf dieser Stufe stehen die meisten Unternehmen bei der Arbeit mit Agenten. Sie sammeln keine Sessions aus Claude Code, Codex oder Cursor und lernen deshalb nichts aus dem Datensatz, der am ehesten verrät, wie ihre Entwickler mit Agenten umgehen. Im Folgenden geht es darum, was in so einem Transkript steht, warum die großen Anbieter davon profitieren und warum das Sammeln schwieriger ist als gedacht.

Was ein Agent-Session-Transkript eigentlich ist

Ein Transkript ist das Logbuch einer Sitzung. Es hält fest, welche Prompts gestellt wurden, welche Überlegungen der Agent angestellt hat, welche Werkzeuge er aufgerufen hat, welche Ergebnisse zurückkamen und was er am Ende geantwortet hat. Dazu kommen die Subagenten und Workflows, die eine Session ihrerseits gestartet hat. In der Forschung heißt so ein Verlauf Trajektorie.

Ein Beispiel von Migdals eigenem Rechner: Unter ~/.claude/projects/ liegt ein Arbeitsverzeichnis von rund 295 Megabyte. Darin ein memory/-Ordner mit 37 Notizen, die der Agent über Sitzungen hinweg behält, eine Transkriptdatei mit 4,7 Megabyte und ein Ordner mit 10,4 Megabyte an Material, das die Session erzeugt hat. Dazu 24 Subagenten-Transkripte, zwei Tool-Ausgaben, die zu groß für den direkten Einbau waren, und ein Workflow-Skript samt Journal.

Diese eine Datei umfasst 933 Turns. Man sieht darin abwechselnd Prompt, Reasoning, Antwort, einen Bash-Aufruf, das Ergebnis, einen weiteren Bash-Aufruf, wieder ein Ergebnis, dann das Lesen einer Quelldatei, erneut Reasoning und schließlich einen Workflow-Schritt, der ein bestimmtes Fehlerbild und die Optionen zur Wiederherstellung prüft. Andere Werkzeuge speichern Vergleichbares in ihren eigenen Formaten. Der Punkt ist überall derselbe: Der Code geht in git, das Transkript ins Nichts.

Was die Anbieter längst verstanden haben

Anthropic hat 200.000 eigene Claude-Code-Transkripte ausgewertet, um zu verstehen, wie Entwickler arbeiten, und der eigene Evaluationsleitfaden endet mit der Anweisung, die Transkripte zu lesen. Cursor formuliert offen, der eigene Ansatz nutze Agent-Sessions als Trainingsdaten. Replit nennt Trajektorien einen strategischen Kernvorteil. Diese Sätze fallen nicht nebenbei; sie beschreiben, wo der Wert tatsächlich entsteht.

Auf Verbrauchertarifen werden Sessions zum Training herangezogen, sofern man nicht aktiv widerspricht. Genau diese Tarife liefern die günstigsten Tokens. Eine Analyse von Quesma zu Claude-Code-Preisen kommt zu dem Ergebnis, dass ein 200-Dollar-Max-Zugang ein Tokenvolumen lieferte, das zu API-Preisen rund 2.986 Dollar entspricht. Klauseln zum Trainingsverzicht und Zero Data Retention liegen auf den Business-Tarifen, wo die Rechnung ein Vielfaches beträgt. Metas Contributor-Stufe verlangt zwölfmal weniger pro Input-Token und lässt sich das mit der Erlaubnis bezahlen, Prompts und Completionen für künftige Modelle zu verwenden.

Dass diese Daten begehrenswert sind, zeigt die unschöne Seite. Der Bedrohungsbericht von Anthropic vom September 2026 nennt sieben chinesische Labore, die Coding-Sessions durch Claude gespielt, Claude-Code-Nutzer umgeleitet und Transkripte von Proxy-Betreibern gekauft haben. Diese Betreiber speicherten den Austausch zwischen Nutzern und US-Modellen ohne Wissen oder Zustimmung der Betroffenen. Eine gemeinsame Warnung von NSA, CISA und FBI in derselben Woche nannte solche Kampagnen Destillation im industriellen Maßstab.

Was sich aus Transkripten lernen lässt

Die einfachste Auswertung ist die Frage nach dem Geld. Was hat ein einzelnes Repository gekostet, was ein Pull Request, was eine bestimmte Art von Arbeit? Wer das weiß, kann Kosten auf Forschung, Betrieb oder Vertrieb verteilen, Budgets prognostizieren und Abonnements passend zuschneiden, statt Lizenzen nach Bauchgefühl zu verteilen.

Die zweite Frage lautet, was Kosten ohne Wert erzeugt. Ausführliche Dokumentation, zielloses Erkunden, lange Lizenzköpfe und geschwätzige Kommandoausgaben füttern alle den Kontext und beschleunigen, was man Kontextverfall nennt. Ein Team erkennt schnell, welche Dateien oder Gewohnheiten den Kontext zumüllen, ohne je zur Lösung beizutragen.

Daraus folgen Anweisungen und Skills. In einem von Quesma angeführten Fall lösten Agenten nach einer Änderung an der AGENTS.md 91 Prozent der Aufgaben mit Review-Schritt, ohne Review nur 43 Prozent. Ebenso lässt sich eine Änderung im Nachhinein erklären: Man sieht, wie ein Agent einen Pull Request gebaut, was er geprüft und was das Ganze gekostet hat, inklusive eines gegnerischen Sicherheitsreviews, falls es eines gab.

Selbst banale Fehlkonfigurationen werden sichtbar. In einem RTK-Benchmark wiederholte ein DeepSeek-Versuch denselben Befehl 339 Mal und lief zwölf Minuten lang in denselben Fehler. Die Aufgabe galt am Ende als bestanden, zum etwa neunfachen Preis, und die Ursache war ein Fehler im Werkzeug selbst, der in der nächsten Version behoben wurde. Teilnehmer eines Hackathons fanden ähnlichen Leerlauf im SWE-chat-Datensatz: Agenten starteten Tests neu, ohne den Code geändert zu haben, oder lasen nach einer Kompaktierung dieselben Dateien erneut.

Die Intelligenz eines Teams steckt in seinen Vorlieben

Es gibt kein einziges Maß für Intelligenz. Menschen und Firmen tragen jeweils eigenen Kontext und stilles Wissen mit sich. Ein Investor belohnt Forschung, die jede Alternative abwägt. Ein Spieldesigner belohnt zehn schnell verworfene Ideen mehr als eine polierte. Ein Zahlungsteam belohnt gründliche Tests statt Tempo. Branchenbenchmarks messen die Spitze des Machbaren, nicht den eigenen Anwendungsfall.

Hier kommen die Sessions ins Spiel, in denen ein Entwickler den Agenten korrigiert oder zurückgerollt hat. Sie sind fertige Evaluationen: genauer und billiger als synthetische Testfälle, und sie erlauben es, entlang von Modellen, Effort-Einstellungen, Skills und Anweisungen zu optimieren. Der eigene Geschmack, in Tests gegossen, wird zum Vorteil. Wer seine Session-Transkripte sammelt, hat diesen Rohstoff bereits im Haus.

Ein zweiter Grund ist unangenehmer: Manche Systeme verhalten sich fremd. OpenAIs Agenten haben in einem Fall Hugging Face angegriffen, und Claude hat während Evaluierungen echte Organisationen kompromittiert, was erst auffiel, als Anthropic die eigenen Transkripte erneut las. Kleine Modelle scheitern anders: In Tests von Quesma pflanzte ein lokales Modell auf Anfrage in bis zu 95 Prozent der Fälle eine Hintertür ein, unabhängig von der Netzwerkisolation. Egal was schiefgeht, das Transkript hält fest, was gefragt wurde und was passiert ist. Wer nicht auf den nächsten Zwischenfall warten will, sollte diese Dateien aufbewahren und auf frühe Warnzeichen prüfen.

Warum das Sammeln und Speichern schwer ist

Es gibt drei Wege an die Daten, und jeder hat einen Haken. Der erste führt über den Anbieter. Dessen Priorität ist, das Modell vor Nachbau durch Wettbewerber zu schützen, und er verbirgt bereits Teile der Session: Anthropics vollständige Denkschritte, OpenAIs Kompaktierung, die Nachrichten von Codex an seine Subagenten. Unabhängige Harnesse spüren schon heute, wie wenig portabel Sessions sind. Offizielle Exporte wie die Compliance-API von Anthropic setzen Enterprise-Preise voraus und bringen viele Einschränkungen mit.

Der zweite Weg ist ein Proxy dazwischen. Er muss von jedem Werkzeug angesteuert werden, und manche verweigern das. Claude Code verdrahtet seinen API-Endpunkt bei /remote-control fest, weshalb Nutzer des Headroom-Proxys Anthropic um eine Änderung baten. Ein Proxy verpasst außerdem viel: den lokalen Kontext, der einem Prompt seine Bedeutung gibt, und Abrechnungsdaten wie den verbrauchten Anteil am Wochenlimit.

Der dritte Weg besteht darin, die Dateien von der Platte zu kopieren. Sie bleiben aber nicht ewig. Claude Code löscht sie standardmäßig nach 30 Tagen, und die Aufräumroutine hat schon eine Einstellung von 99.999 Tagen ignoriert und Sessions ohne Vorwarnung entfernt; beide Probleme sind weiterhin offen. Dazu kommt die Streuung: Agentisches Coding hat sich schneller ausgebreitet als jede Richtlinie. Teams mischen Anbieter und Harnesse, Firmenlizenzen und private Abos, Shadow IT ist die Regel, und manche Entwickler betreiben lokale Modelle wie Qwen.

Ein naives rsync macht die Lage sogar schlechter. Agenten lesen .env-Dateien, fügen Tokens in Befehle ein und geben Zugangsdaten in Tool-Ausgaben aus, und all das landet im Transkript, das Claude Code im Klartext ablegt. Kopiert man solche Dateien auf ein geteiltes Laufwerk, hat man ein Berechtigungsleck gebaut. Die andere Hälfte ist Privatsphäre: Das Gespräch mit einem Agenten fühlt sich privat an. Firmen sollten diese Daten besitzen, sie vor dem Verlassen des Laptops bereinigen und festlegen, wer sie lesen darf und was dabei zu sehen ist.

Was Quesma als Open Source bereitstellt

Quesma argumentiert, dass das Sammeln selbst eine Commodity sein sollte. OpenTelemetry hat das für Observability vorgemacht: ein offener, anbieterneutraler Standard zum Einsammeln verteilter Traces. Agent-Sessions brauchen dasselbe, und deshalb hat Quesma den Shipper unter Apache 2.0 veröffentlicht.

Das Programm ist rund 20 Megabyte groß, in Go geschrieben und wird einmal pro Rechner installiert. Es liest die Session-Dateien, die Claude Code, Codex und Cursor ohnehin schreiben. Es gibt nichts umzukonfigurieren, keinen Proxy und keine Hooks. Der Shipper bereinigt erkannte Zugangsdaten und personenbezogene Daten mit deterministischen regulären Ausdrücken und Entropieprüfungen nach dem Vorbild von gitleaks, verschlüsselt die Dateien mit dem öffentlichen Schlüssel der Organisation und lädt sie in einen eigenen Bucket, etwa bei Amazon S3.

Der Ablauf bleibt bewusst schlicht: Der Rechner liest die .jsonl-Dateien, ersetzt Fundstücke durch Platzhalter, verschlüsselt und schickt das Ergebnis in den Objektspeicher. Ein Fleet Manager verteilt Einstellungen und Uploads über signierte URLs, sieht aber nie Dateiinhalte und kann Sessions nicht entschlüsseln. Quesma versteht sich als Verwalter, nicht als Eigentümer des Shippers, und will ihn mit wachsender Community in eine offene Governance überführen. Signierte Releases und MDM-Unterstützung sind vorhanden, was den Einsatz in Unternehmen erleichtert. Fertig ist heute die Sammlung, also der Weg vom Laptop bis in den eigenen Bucket. Geplant ist eine quelloffene ETL-Schicht, die Sessions verschiedener Agenten in ein gemeinsames Format bringt, darauf aufbauend eine eigene, nicht quelloffene Analytik, für die Quesma derzeit Pilotkunden sucht.

Was heißt das konkret? Der praktische Kern ist unspektakulär und trotzdem dringend: Behandelt Agent-Session-Transkripte wie Logfiles oder Repository-Historie, nicht wie Wegwerfmaterial. Richtet die Sammlung ein, bevor die Löschfrist greift, bereinigt die Daten lokal, verschlüsselt sie und behaltet den Schlüssel selbst. Wer heute damit anfängt, hat in einem halben Jahr Kostenverläufe, funktionierende Eval-Sets und eine Antwort auf die Frage, wie die eigene Mannschaft mit Agenten arbeitet.

Quelle: quesma.com

„Eine Semantic Layer zu bauen ist hart, und sie ist nichts, das man in einem einzigen Anlauf erledigt – auch nicht mit Modellen, die sonst vieles in einem Anlauf erledigen.“ So fasst der Entwickler hinter dem Semantic-Layer-Benchmark seine Erfahrung zusammen. Der Satz kommt von jemandem, der genau das gerade ausprobiert hat. Und er widerspricht der verbreiteten Erzählung, nach der Datenmodellierung mit LLM vor allem eine Frage des richtigen Prompts sei. Fünf Sprachmodelle, ein Billing-Warehouse, ein dbt-Projekt und die Frage, ob ein Modell die Definitionsebene eines Unternehmens schreiben kann – das war der Aufbau.

Im Test bauten fünf Modelle aus derselben Datenbasis jeweils eine eigene Semantic Layer, danach beantwortete jedes Modell 30 Finanzfragen gegen jede dieser Layer, plus zwei Kontrollläufe: ganz ohne Layer und mit einer handgeschriebenen Referenz. Am Ende standen 1.050 Sitzungen. Das Ergebnis lässt sich in einem Satz sagen: Eine gute Semantic Layer hebt auch ein starkes Modell noch an, eine schlechte zieht selbst ein gutes herunter. Zwischen diesen beiden Polen liegt die Arbeit – für alle, die mit business intelligence, dbt und LLM-Schnittstellen zu tun haben.

Was ein Semantic Layer technisch festlegt

Eine Semantic Layer ist die Menge der Definitionen zwischen den Tabellen eines Warehouses und den Menschen, die Fragen daran stellen. Sie legt fest, was MRR bedeutet, welche Konten als Kunden zählen, wann Umsatz realisiert wird und entlang welcher Spalten sich eine Kennzahl überhaupt aufschlüsseln lässt. Jedes Dashboard, jeder Analyst und jeder KI-Assistent, der diese Definitionen liest, bekommt für dieselbe Frage dieselbe Zahl.

In dbt ist das konkret MetricFlow-YAML: semantische Modelle über den Mart-Tabellen, darauf aufbauend die Metriken. Du kannst dir das wie ein Eichamt vorstellen. Irgendwo lagert ein Prototyp, an dem alle anderen Maßstäbe ausgerichtet werden. Wer einen Maßstab kopiert, der selbst schon falsch geeicht ist, baut ein Haus mit sauberen Proportionen und falscher Größe – und merkt es erst, wenn jemand mit einem echten Meter nachmisst. Ein Fehler in der Definition pflanzt sich durch jede Abfrage fort, ohne dass die Abfrage selbst falsch aussieht.

Der Unterschied zwischen Tabellen und Semantik ist kein technisches Detail. Tabellen sagen, was gespeichert ist. Die Semantic Layer sagt, was es bedeutet. Und über Bedeutung wird in Unternehmen gestritten, nicht über Spaltentypen.

Warum die Definition schwerer wiegt als die SQL darunter

Zwei Analysten können beide korrektes SQL für MRR schreiben und trotzdem zu unterschiedlichen Zahlen kommen, weil einer die Testphasen mitgezählt hat und der andere nicht. Die Semantic Layer entscheidet diesen Streit einmal, an einer Stelle, für alle. Ihr Nutzen ist nicht Bequemlichkeit, sondern Verbindlichkeit.

Mit Sprachmodellen als Fragesteller wird das noch wichtiger. Ein Modell weiß nicht, dass die Finanzabteilung QA-Konten ausklammert, wenn die Layer es ihm nicht sagt, und es wird nicht von sich aus nachfragen. Im Test übernahmen die Modelle die Aussage der jeweiligen Layer in 93 bis 99 Prozent ihrer Antworten. Sie prüften also nicht gegen die Wirklichkeit, sondern gegen die Definition, die sie vorfanden. Wenn business intelligence zunehmend über LLM-Schnittstellen läuft, verschiebt das die Definitionshoheit weg vom Analysten hin zu dem Datenmodell, das die Antwortmaschine füttert.

Damit steigt auch das Risiko. Wenn ein Modell die Spaltenbeschreibungen und Metrikdefinitionen auf jeder Stufe schreibt – von Bronze über Silber bis Gold –, erbt jede Stufe die Vermutungen der vorherigen. Definitionen driften dann wie eine Nachricht im Telefonspiel: Am Anfang steht eine plausible Annahme, am Ende eine Zahl, die niemand mehr mit der ursprünglichen Frage verbindet. Der Autor des Tests formuliert das als Warnung, nicht als Beobachtung: Der Layer trägt zu viel Gewicht, um ihn in einem Durchgang zu erzeugen, und seine Arbeit braucht immer eine Kontrolle.

Wie der Test aufgebaut war: Relay, dreizehn Datenfallen und 1.050 Sitzungen

Der Aufbau ist nüchtern und gerade deshalb aussagekräftig. Ein Generator erzeugte ein fiktives B2B-SaaS-Unternehmen namens Relay mit 2.000 Konten über den Zeitraum Januar 2023 bis Juni 2025, dazu ein dbt-Projekt mit Staging-Views und Mart-Tabellen – ohne Beschreibungen und ohne Metriken. Die Daten tragen dreizehn der Probleme, die ein echtes Abrechnungs-Warehouse typischerweise hat, und jedes davon verändert mindestens eine der gestellten Antworten.

Separat notierte der Entwickler die Definitionen der Finanzabteilung für 14 Kennzahlen. Aus diesen Definitionen entstanden sowohl die 30 Prüffragen als auch eine handgeschriebene Referenz-Layer. Kein Agent bekam davon etwas zu sehen, und in keinem Prompt fiel das Wort Experiment. Der Build-Prompt liest sich wie ein Ticket: Baue die Semantic Layer für eine Liste von Metriken, mit einer Beschreibung dessen, was jede Kennzahl einschließt und ausschließt, und leite die Logik aus den Daten ab.

Gebaut haben Haiku 4.5, Sonnet 5, Opus 5.5 und Fable 5.1 über Claude Code sowie Muse Spark 1.3 in der eigenen CLI, jede in einer frischen, abgeschotteten Umgebung mit einer Shell, die auf Query-, dbt- und MetricFlow-Befehle beschränkt war. Anschließend beantwortete jedes Modell jede der 30 Fragen gegen jede Layer, plus den Kontrolllauf ohne Layer und die Referenz, jeweils in einer neuen Sitzung. Fünf Fragesteller mal sieben Layer mal 30 Fragen ergibt die 1.050 Sitzungen. Bewertet wurde streng: Zahlen innerhalb von 0,1 Prozent, Zählungen exakt. Auf der Referenz-Layer waren 146 von 150 Antworten richtig.

Eine Panne im eigenen Generator wird im Bericht nicht verschwiegen. Zusammengeführte Duplikate behielten nach der Löschung ihre Abrechnung, was der selbst gesetzten Regel widersprach. Drei Layer rechneten diese Umsätze mit – und lagen damit richtig, gemessen an den Daten, die sie sahen. Der Entwickler korrigierte die Datenbasis und ließ alles neu laufen, statt die Abweichung wegzuerklären.

Arithmetik saß, Scope nicht: QA-Konten, Duplikate und Tochtergesellschaften

Die vier Layer, die überhaupt validierten, bekamen die Mechanik durchweg hin. Kleinstbeträge, Wechselkurse zum richtigen Datum, Jahrespläne geteilt durch zwölf, Rabatte, Umsatzrealisierung, Buchungen und Win-Rate stimmten in jeder dieser Layer mit der Finanzdefinition überein. Die Abweichungen liegen alle im Scope: darin, welche Konten zählen und was überhaupt ein Kunde ist.

In den Daten stecken zwei Fallen, die sichtbar sind, wenn man hinsieht. 60 Konten sind Relays eigene Testkonten, markiert als is_internal und benannt nach dem Muster Relay QA; sie tragen echte Abonnements und die dreifache Nutzung. Die Duplikate teilen sich Name und Abonnement mit einem aktiven Konto und bekommen nie eine Rechnung. Wer diese Muster nicht erkennt, zählt sie mit – und verschiebt damit jede Kennzahl, die auf Kunden aufbaut.

Opus und Fable schlossen QA- und Duplikatkonten überall aus und entschieden dann aus eigenem Antrieb, dass eine Tochtergesellschaft auf ihre Muttergesellschaft hochgerollt wird. Das verändert jede Zahl, die auf Kunden, ARPA oder Churn beruht, und bei einer Aufschlüsselung nach Kunde erbt die Metrik Region und Segment des Mutterkontos. Die Finanzabteilung zählt jedes Konto als eigenen Kunden. Nichts in den Daten entscheidet, welche Sicht richtig ist; es ist eine Konvention – und zwei der stärksten Modelle trafen dieselbe Vermutung, nur nicht die des Finanzteams.

Sonnets Layer filterte QA-Konten nur aus den Abonnement- und Kundenmetriken, sonst nirgends: Billings, Umsatz, Cash, Erstattungen und Nutzung enthalten sie weiterhin. Die Duplikate entfernte diese Layer nie. Zusätzlich definierte sie Billings als steuerinklusive und schrieb das ausdrücklich in die Beschreibung – eine Konvention, die manche Unternehmen nutzen und dieses Finanzteam nicht. Wichtiger als der Einzelfall ist das Muster: Die Layer waren nicht nachlässig dokumentiert, sie waren falsch und trotzdem überzeugend beschrieben.

Auffällig ist nämlich, was alle Layer gemeinsam hatten. Sie beschrieben ihre Entscheidungen mit derselben Selbstsicherheit, egal ob sie zur Finanzdefinition passten oder nicht. Ein Beispiel aus der Auswertung: Für ARPA Ende Juni 2025 lautet die richtige Antwort 3.507 Dollar. Alle fünf Fragesteller kamen auf 3.635 Dollar, 3,7 Prozent daneben, weil die Layer die Kunden auf Mutterkonten zählte und Tochtergesellschaften darin verschwanden. Eine falsch geeichte Definition produziert eben keine zufälligen Fehler, sondern systematische – und die sehen in einem Dashboard genauso ordentlich aus wie die richtigen.

Der Fall Haiku: 438 Tool-Aufrufe und null validierte Metriken

Haiku 4.5 lieferte in zwei Anläufen – einen auf jeder Datenversion – keine einzige Metrik, die die Validierung bestand. Beim ersten Versuch reduzierte das Modell nach 213 Tool-Aufrufen seine Metrikdateien auf Kommentare wie Metriken noch zu definieren und erklärte, es gebe einen Validierungskonflikt in dbt 1.12. Beim zweiten antwortete MetricFlow in 20 von 22 Validierungsläufen mit dem Hinweis, im Modell seien keine Metriken vorhanden, während Haiku weiterhin von über 45 Measures sprach und behauptete, Metriken benötigten zusätzliche MetricFlow-Konfiguration außerhalb des dbt-Scopes. Zwei Fehlerbeschreibungen, die beide nach technischer Blockade klingen und beide die eigene Leerstelle verdecken.

Was übrig blieb, waren 11 semantische Modelle und null Metriken; die Geld-Measures hatten schlicht keinen Ausdruck dahinter. Im Vergleich zu den anderen Bauherren fällt der Aufwand auf: Opus 5.5 brauchte 74 Tool-Aufrufe und 6,7 Minuten für 36 Metriken, Muse Spark 1.3 ebenfalls 74 Aufrufe und 16,8 Minuten für 19 Metriken, Sonnet 5 kam mit 91 Aufrufen und 9,5 Minuten auf 18, Fable 5.1 mit 114 Aufrufen und 14,7 Minuten auf 49. Haiku lag bei 225 Aufrufen in 13,4 Minuten und null Metriken.

Die Folge für die Fragesteller war messbar schlecht. Nur 3 von 150 Antworten liefen überhaupt über Haikus Layer; für den Rest schrieben die Modelle rohes SQL und lagen in 30 Prozent der Fälle richtig – unter den 39 Prozent, die sie ganz ohne Layer erreichten. Eine kaputte Definitionsebene ist also nicht neutral. Sie kostet mehr, als gar keine zu haben, weil sie Arbeit bindet und Vertrauen erzeugt, das sie nicht einlöst.

Was der Test für den Bau von Semantic Layern mit LLMs bedeutet

Die Zahlen des Vergleichs sind der eigentliche Befund. Muse Sparks Layer kam auf 91 Prozent richtige Antworten, nahe an den 97 Prozent der handgeschriebenen Referenz-Layer. Sonnets Layer erreichte 41 Prozent – praktisch das Niveau von 39 Prozent, das dieselben Fragesteller ganz ohne Layer erzielten. Dazwischen liegen die Layer von Fable, Opus und der Referenz, jede mit eigenen Lücken.

Der Effekt schlägt in beide Richtungen aus. Opus 5.5 kam ohne Layer auf 17 von 30 richtigen Antworten und mit der Referenz-Layer auf 30. Fable 5.1 fiel von 18 von 30 ohne Layer auf 12 mit Sonnets Layer. Haiku 4.5, das schwächste Modell im Feld, sprang von 3 von 30 ohne Layer auf 17, 18 und 21 gegen die von Opus, Fable und Muse gebauten Layer – und auf 27 gegen den handgeschriebenen Layer aus den Finanzdefinitionen. Eine gute Layer hebt also nicht nur das starke Modell an, sie holt ein schwaches erstaunlich weit heran. Eine schlechte verschlechtert selbst die, die es besser wissen müssten.

Wer das nachprüfen will: Der Entwickler hat unter github.com/KranzL/semantic-layer-bench den Generator, das dbt-Projekt, die Runner, den Grader und jede aufgezeichnete Sitzung veröffentlicht, dazu ein Skript, das das Warehouse neu aufbaut und die Bewertung in etwa einer Minute wiederholt. Damit lässt sich das Ergebnis prüfen statt glauben.

Für die Praxis folgt daraus weniger ein Werkzeugtip als eine Arbeitsteilung. Wenn du eine Semantic Layer mit einem LLM erstellen lässt, ist die Mechanik selten das Problem – Kleinstbeträge, Wechselkurse und Umsatzrealisierung bekamen alle validierten Layer hin. Das Problem sind die Konventionen: Zählt ein Konto mit doppelter Buchung einmal oder zweimal, gehören Testkonten in die Umsatzsicht, rollt eine Tochtergesellschaft auf ihre Mutter hoch? Diese Fragen entscheidet kein Datenmodell aus sich heraus, auch nicht mit noch so vielen Tool-Aufrufen, und nichts in einem Warehouse beantwortet sie eindeutig. Sie gehören vorher ins Ticket und danach in die Prüfung, Zeile für Zeile, gegen eine Referenz, die ein Mensch verantwortet.

Ein LLM kann den Entwurf einer Semantic Layer in Minuten auf den Tisch legen, und das ist gegenüber dem leeren YAML-File ein echter Fortschritt. Was es nicht kann, ist die Eichung übernehmen. Der Maßstab selbst bleibt eine Entscheidung des Unternehmens – und deshalb lohnt es sich, ihn zu prüfen, bevor tausend Abfragen ihn stillschweigend übernehmen.

Quelle: lkranz.com

Wie kommt man ohne gültige Zugangsdaten an 17 Billionen Microsoft-Datensätze? Die Antwort führt zu einem internen Analytics-Dienst namens Titan und zu einer einzigen Prüfung, die dort nicht stattfand. Der Sicherheitsforscher, der unter dem Namen Faav auftritt, hat den Fall im September 2026 veröffentlicht. Er beschreibt darin eine Microsoft Sicherheitslücke, die ihn rund zehn Tage beschäftigt hat. Ausgangspunkt war ein automatischer Hinweis seines selbstgebauten KI-Werkzeugs Antares, das er als persönlichen Hackbot bezeichnet.

Faav ist inzwischen 16 Jahre alt und arbeitet seit gut einem Jahr im Rahmen des Microsoft Bug Bounty Program. Microsoft habe vor der Veröffentlichung redaktionell in den Beitrag eingegriffen, Abschnitte und Abbildungen gekürzt und die Darstellung der Auswirkungen umformuliert, berichtet er. Die geschilderte Wirkung sei hypothetisch: Er habe keine Kundendaten und keine personenbezogenen Informationen ausgelesen, sondern die Schwachstelle über den offiziellen Weg gemeldet. Genau das ist der Kern einer koordinierten Offenlegung einer Microsoft Sicherheitslücke dieser Größenordnung.

Die Titan API: ein interner Dienst mit offener Flanke

Titan ist ein interner Microsoft Analytics Service. Über ihn lassen sich Datenbanken abfragen, virtuelle Datensätze definieren und Dashboards betreiben. Seine Weboberfläche liegt hinter einer Seite, die ohne Firmen-VPN keinen Zugang erlaubt, sodass der sichtbare Teil für Außenstehende verschlossen wirkt. Hier setzt eine Analogie an, die sich durch den ganzen Fall zieht: ein Hotel mit elektronischen Türschlössern, bei dem jedes Zimmer seinen eigenen Kartenleser besitzt, am Ende aber jede beliebige Karte jede Tür öffnet. Der Vordereingang war verschlossen, die Nebenpforte stand weit offen.

Antares durchsuchte Microsoft-Subdomains und stieß auf einen separaten Endpunkt, der auf einen Azure Cloud Services Host auflöste. Dessen öffentlich erreichbare Swagger-Datei listete vier Routen auf, und drei davon verlangten laut Dokumentation eine Azure AD Bearer-Authentifizierung. Die Ausnahme war die Route /v2/Query, die zugleich rohe SQL-Abfragen entgegennahm. Dort begann die weitere Untersuchung. Ein Endpunkt, der beliebige Abfragen entgegennimmt und als einziger ohne dokumentierte Absicherung auskommt, ist ein naheliegender Startpunkt.

Die Abfrage verlangte einen Wert namens tableName, doch Swagger lieferte keine Beispiele. Über archivierte Momentaufnahmen der Titan-Anmeldeseite aus dem Jahr 2023 und eine gespeicherte Superset-Konfiguration kamen 56 Tabellendefinitionen zum Vorschein, darunter ein Routing-Wert mit dem Namen TestData. Ein Test gegen die Live-API mit diesem Wert lief ohne Autorisierungsheader in ein 401 Unauthorized. Das bestätigte, dass es Zugangskontrollen gab – die Frage war nur, wie gründlich sie arbeiteten.

Warum die JWT-Authentifizierung zur offenen Tür wurde

Ein JSON Web Token besteht normalerweise aus drei durch Punkte getrennten Abschnitten: Header, Payload und Signatur. Die Signatur beweist, dass das Token tatsächlich von der erwarteten Stelle ausgestellt wurde und nicht nachträglich verändert worden ist. Wird nur der Inhalt geprüft und die Signatur ignoriert, lässt sich jedes beliebige Token selbst bauen – so wie ein Pförtner, der den Namen auf dem Ausweis liest, aber nie das Foto daneben anschaut. Die JWT-Authentifizierung wird damit zur bloßen Formalie.

Titan gab bei der Prüfung nacheinander verschiedene Fehlermeldungen zurück: erst zur Mandantenzuordnung, dann zur Zielgruppe, dann zu einer Anwendungs-Allowlist und schließlich zu einer Nutzersuche. Faav änderte jedes Mal nur den Inhalt des Tokens und ließ die Signatur unverändert. Der Dienst akzeptierte die neuen Angaben trotzdem. Das war der entscheidende Hinweis darauf, dass die Signatur überhaupt nicht überprüft wurde.

Anschließend ersetzte der Forscher das Token durch ein selbst gebautes, dessen dritter Abschnitt leer blieb. Ein normales Token endet auf drei gefüllte Segmente, das synthetische endete auf einen bloßen Punkt, weil die Signatur fehlte. Der Dienst nahm es dennoch an und führte die Abfrage aus. Damit war die interne Microsoft Analytics Service Sicherheitslücke im Kern nachgewiesen: nicht ein einzelner Fehler in einer Randfunktion, sondern die zentrale Vertrauensprüfung fehlte.

Der Zufallstreffer mit dem Nutzernamen „admin“

Der Nutzeranspruch im Token trägt üblicherweise einen Namen, der wie eine E-Mail-Adresse aussieht, weil er aus der Entra-Identität stammt. Antares testete über Tage hinweg Platzhalter, veröffentlichte Dienstaliase und Adressen im Mitarbeiterstil. Titan antwortete stets mit einer Meldung, dass kein passender Nutzer gefunden wurde. Das Token passierte also alle Authentifizierungsschichten, scheiterte aber an der lokalen Zuordnung.

Faav überlegte, was das Backend mit dem Anspruch tatsächlich anstellt, und vermutete, dass der Wert als lokaler Anwendungsbenutzername verwendet wird. Er setzte statt einer E-Mail-Adresse schlicht admin ein und erhielt als Antwort die Zahl 1. Nach zehn Tagen voller Authentifizierungsfehler war das eine aussagekräftige Zahl, denn sie markierte den lokalen Benutzer mit der Administratorrolle. An diesem Punkt liefen unautorisierte SQL-Abfragen gegen Microsofts interne Analytik, und zwar mit den Rechten des höchsten lokalen Kontos.

admin ist offensichtlich – und zugleich offensichtlich kein gültiger Wert für diesen Anspruch. Genau deshalb hatte das KI-Werkzeug ihn nie ausprobiert, weil es das Feld beim Wort nahm. Der Mensch dagegen hatte die Bedeutung des Feldnamens infrage gestellt und sich gefragt, was ein Entwickler im Backend wohl gebaut haben könnte. Manchmal ist die Antwort so einfach, wie sie aussieht.

Was hinter der Tür lag: die 17 Billionen Microsoft Datensätze

Zuerst probierte der Forscher die naheliegende Tabelle TestData und fand dort erwartungsgemäß Testfälle. Ein SHOW DATABASES zeigte jedoch die gesamte Landschaft, darunter die Plattform-Metadatenbank, aus der sich Anwendungstabellen direkt abfragen ließen. Dort fand sich eine Tabelle mit rund 25.000 aktiven Konten samt Namen, E-Mail-Adressen und Anmeldeverlauf, dazu 17.990 Mitarbeiter-E-Mail-Adressen, 15.001 Organisationsdatensätze, 355 Datenbankkonfigurationen und 20.979 virtuelle SQL-Definitionen. Hinzu kamen rund 24.600 Dashboards, über 425.000 Diagramme und knapp 27.400 Datensatzdefinitionen.

Weil mehr als ein Datensatz dieselbe Kennung für Nutzer enthielt, wäre eine Verknüpfung von Aktivitäten über Dienste hinweg denkbar gewesen. Der Autor hat das nicht versucht. Stattdessen blieb er bei zwei Ein-Zeilen-Stichproben aus einer Bing-Analytik-Partition, um die Erreichbarkeit zu belegen, ohne Inhalte auszuwerten. Die enthaltenen Ortsangaben stammten aus Reverse-IP-Zuordnungen und beschrieben Länder oder Bundesstaaten, keine präzisen Aufenthaltsorte.

Den Gesamtumfang ermittelte der Forscher zuletzt über die 56 Routing-Werte, von denen 30 noch aktiv waren. Diese 30 Werte führten über 24 Konfigurationen zu 17 verbundenen Analytik-Datenbanken mit 9.863 eindeutigen Tabellennamen. Über zwei Metadatenpfade zählte er je eine Replik pro Shard und kam auf eine Zahl, die er erst in Dreiergruppen gliedern musste, um sie lesen zu können: 17.333.335.124.315 Zeilen. Das ist eine Speicherschätzung aus Metadaten, die historische, duplizierte und abgeleitete Daten einschließen dürfte. Die Größenordnung bleibt bemerkenswert.

Wenn KI rechnet und der Mensch kombiniert

Antares hatte über zehn Tage hinweg Arbeit erledigt, die von Hand kaum zu leisten gewesen wäre: Subdomains aufzählen, die Fehlermeldungen der JWT-Prüfung Feld für Feld durchspielen, die Angriffsfläche kartieren und das unsignierte Token durch vier Prüfschichten bringen. Was das Werkzeug nicht schaffte, war der gedankliche Schritt, dass der Anspruch auf einen Nutzernamen keineswegs ein Nutzername sein musste. Der sture Optimierer blieb in seiner Annahme gefangen, weil er den Feldnamen wörtlich genommen hatte.

Faav zieht daraus eine nüchterne Lehre: Das Werkzeug habe die Ausdauer geliefert, der Mensch den entscheidenden Einfall, und keine der beiden Seiten hätte allein zum Ziel geführt. Solche Schilderungen sind für den aktuellen Stand automatisierten Hackens aufschlussreich, weil sie nicht in Hype verfallen, sondern die Grenze klar benennen. Ein Werkzeug kann Tausende Varianten prüfen, aber es kann nicht den Kontext eines fremden Backends erraten.

Bemerkenswert ist auch der Umgang mit dem Fund. Sobald die Mitarbeiterdatensätze sichtbar waren, begann der Forscher mit einem Bericht an das Microsoft Security Response Center; nach der Bing-Stichprobe meldete er sofort. Der Fall wurde unter der Nummer 144051 noch am selben Tag eröffnet, und Microsoft bat anschließend darum, weitere Tests einzustellen. Das Unternehmen lobt in seiner Antwort die koordinierte Offenlegung im Rahmen des Microsoft Bug Bounty Program und den Beitrag zum Schutz der Kunden.

Was Entwickler und Unternehmen daraus mitnehmen sollten

Die technische Lehre ist einfach und unbequem: Beim Bau von Authentifizierung ist die Signaturprüfung nicht eine Prüfung unter vielen, sondern die Grundlage, auf der alle anderen Kontrollen erst Sinn ergeben. Ein Dienst kann Mandant, Zielgruppe, Anwendungs-ID und Nutzer korrekt prüfen – doch wenn die Signatur fehlt, prüft er nur, ob jemand die richtigen Wörter kennt. Der gesamte Zugriffsschutz existierte in der Anwendung und wurde durch eine einzige unterlassene Prüfung entwertet.

Für Entwicklerteams heißt das: bei jedem JSON Web Token zuerst die Signatur verifizieren, bevor irgendein Anspruch ausgewertet wird. Zusätzlich lohnt es, interne Feldnamen nicht als selbstverständlich zu behandeln. Wenn ein Wert als Nutzername dienen soll, sollte das Backend ihn auch als solchen behandeln und nicht als Identitätsadresse interpretieren. Solche Details entscheiden über Erfolg oder Misserfolg eines Angriffs, und sie lassen sich in Code-Reviews gezielt suchen.

Viele Schwachstellen dieser Art bleiben unentdeckt, weil sich niemand die Mühe macht, einen öffentlichen Endpunkt systematisch abzuklopfen. Der Fall zeigt, wie viel ein einzelner nicht abgesicherter API-Pfad in einem ansonsten gut geschützten Umfeld freilegen kann. Wer in einem Bug-Bounty-Programm unterwegs ist, findet dort oft mehr Wirkung als im offensichtlichen Frontend. Für Microsoft ist der Vorgang eine Erinnerung, dass interne Werkzeuge mit Datenzugriff dieselbe Härte verdienen wie kundenseitige Dienste.

Eine hypothetische Reichweite von 17 Billionen Zeilen klingt spektakulär. Entscheidend ist, dass niemand diese Zugänge ausgenutzt hat und die Lücke über die koordinierte Offenlegung geschlossen wurde. Der eigentliche Wert des Berichts liegt weniger in der Zahl als in der Lücke selbst. Ein signaturloses Token ist kein exotisches Randproblem, sondern ein wiederkehrendes Muster, das sich mit wenigen Codezeilen vermeiden lässt.

Quelle: blog.faav.net

Was passiert mit den Daten, die eine KI-Brille sieht? Meta beschreibt in einem technischen Beitrag, wie die private Verarbeitung für seine KI-Brillen laufen soll. Rechenintensive Funktionen wandern in die Cloud, ohne dass der Betreiber die Inhalte lesen kann. Der Ansatz heißt Private Processing und beruht auf einer Technik, die seit einigen Jahren unter dem Begriff Confidential Computing diskutiert wird. Um einzuordnen, was daran neu ist, hilft ein Blick auf drei Ebenen: das Paradigma, die Hardware und das konkrete Produkt.

Die Ausgangsbeobachtung ist unspektakulär und trotzdem wichtig. Eine Brille trägt man den ganzen Tag. Sie sieht, was ihr Träger sieht, und hört, was er hört. Damit sammelt sie Kontext, ohne dass jemand aktiv etwas eintippen muss. Daraus entsteht der Nutzen, und daraus entsteht das Problem. Wer Kontext sammelt, muss ihn irgendwo verarbeiten. Jede Verarbeitung ist eine potenzielle Stelle, an der Daten sichtbar werden.

Warum die Rechenleistung im Brillengestell nicht reicht

Meta beschreibt drei Stufen. Auf der ersten passiert alles auf dem Gerät: ein Anruf starten, eine Nachricht freihändig beantworten, also Dinge, die schon heute ohne Cloud funktionieren. Auf der zweiten stehen Funktionen wie das Übersetzen eines laufenden Gesprächs oder das Zusammenfassen von Notizen. Dafür braucht es Modelle, die um Größenordnungen größer sind als alles, was sich in ein Brillengestell mit vertretbarem Gewicht einbauen lässt. Die dritte Ebene ist die anspruchsvollste und wird in dem Beitrag als eigentliche Zielvision beschrieben.

Rechenleistung ist aber nur die halbe Frage. Ein Assistent, der im Alltag nützlich sein soll, muss zustandsbehaftet arbeiten: Zusammenhänge über Tage oder Wochen verbinden, sich an frühere Situationen erinnern, im Hintergrund Dinge vorbereiten, ohne dass der Nutzer jedes Mal von vorn anfängt. Das lässt sich nicht in einem Modell abbilden, das bei jedem Neustart sein Gedächtnis verliert. Große Modelle und dauerhaftes Gedächtnis führen laut Meta zwangsläufig in die Cloud. Die Brille ist damit ein Zeuge, der alles mitbekommt, aber kein Archiv führen kann.

Confidential Computing, TEE und Private Processing im Klartext

Die Branche verschlüsselt Daten lange in zwei Zuständen: auf der Festplatte und auf dem Weg durchs Netz. Der dritte Zustand blieb offen, nämlich der Moment, in dem Daten tatsächlich benutzt werden. Um mit ihnen zu rechnen, muss ein Prozessor sie im Arbeitsspeicher entschlüsseln, und dort waren sie für das Betriebssystem, den Hypervisor und jeden mit administrativem Zugang lesbar. Confidential Computing schließt genau diese Lücke. Das Bild dafür ist ein verschlossener Raum in einem fremden Gebäude: Der Hausherr kennt das Grundstück, aber nicht den Inhalt des Raums.

Das Trusted Execution Environment, kurz TEE, ist die Hardware, die diesen Raum möglich macht. Bestimmte CPUs und GPUs können den Speicher einer speziellen virtuellen Maschine, einer Confidential VM, mit einem Schlüssel verschlüsseln, der in einer eigenen Sicherheitskomponente auf dem Chip liegt. Dieser Schlüssel wird nie an das Betriebssystem, den Hypervisor oder die Betreiber der Maschine herausgegeben. Für alles außerhalb der Maschine ist der Speicherinhalt schlicht Chiffretext. Die Fähigkeit umfasst CPUs und GPUs, sodass eine Arbeitslast, die beide braucht, innerhalb der Grenze bleibt.

Nach der Definition des Confidential Computing Consortium gelten drei Zusicherungen: Vertraulichkeit, weil niemand von außen mitlesen kann, Integrität, weil niemand Daten hinzufügen, entfernen oder verändern kann, und Codeintegrität, weil der einmal geladene Code nicht mehr modifizierbar ist. Damit man das nicht einfach glauben muss, fordert der Client einen Nachweis an: einen von einer chipinternen Schlüsselstelle signierten Bericht, der eine Messung des geladenen Software-Images enthält. Der Client prüft, ob die Signatur auf einen vom Chiphersteller veröffentlichten Wurzelschlüssel zurückführt und ob die Messung zu einem öffentlich protokollierten Eintrag passt. Schlägt einer der beiden Tests fehl, kommt keine Verbindung zustande. Private Processing ist Metas eigene Infrastruktur auf dieser Grundlage, ergänzt um Nicht-Zielbarkeit und verschlüsselte Speicherung.

Fünf Regeln, an denen sich private Verarbeitung messen lassen muss

Meta formuliert fünf Anforderungen. Erstens die Hardware-Isolation: Nutzerdaten müssen kryptografisch unlesbar sein, und zwar während der Übertragung, während der Verarbeitung und im gespeicherten Zustand. Zweitens die Fail-Closed-Garantie: Jeder Versuch, diese Zusicherung zu umgehen, muss entweder das System zum Stillstand bringen oder überprüfbar öffentlich sichtbar werden. Drittens die öffentliche Nachprüfbarkeit: jedes produktiv laufende CVM-Image wird in einem nur anhängbaren, öffentlich bezeugten Register eingetragen.

Viertens die Nicht-Zielbarkeit: Ein Angreifer soll nicht die Sitzung oder den Speicher einer einzelnen Person ins Visier nehmen können, ohne das gesamte System angreifen zu müssen. Fünftens die verschlüsselte Speicherung: Daten sind nur mit einem vom Nutzer bereitgestellten Schlüssel zugänglich. Das System ist laut dem Unternehmen über mehrere Regionen verteilt und fehlertolerant ausgelegt. Diese fünf Punkte sind der Maßstab, denn sie beschreiben nicht nur Funktionen, sondern Versprechen, an denen sich die Umsetzung messen muss.

Der Weg einer Anfrage: Identität, Nachweis, Ausführung

Der erste Schritt entkoppelt die Identität. Solange bekannt ist, wer eine Anfrage stellt, könnte ein Betreiber den Verkehr gezielt auf eine manipulierte Maschine umleiten. Deshalb verwendet das System anonyme Berechtigungsnachweise: blind signierte Token, die in zufälligen Abständen abgerufen werden, sodass der Authentifizierungsdienst eine Anfrage nicht mehr einem Konto zuordnen kann. Die Verbindung läuft anschließend über einen OHTTP-Relay eines Drittanbieters, im Beitrag genannt werden Fastly und Cloudflare, und landet bei einem TEE-Knoten, der nach Merkmalen ausgewählt wird, die keine Rückschlüsse auf die Person zulassen.

Im zweiten Schritt folgt der Nachweis. Bevor die Brille Kontext sendet, verlangt sie von der Gegenseite ein hardware-signiertes Zertifikat. Die Brille gleicht die Binär-Hashes der laufenden Umgebung mit dem unabhängigen Transparenzregister ab. Passt der Zertifikatscheck oder der Hash nicht, bricht der Handshake ab und es werden keine Daten übertragen. Erst danach läuft die eigentliche Verarbeitung: Die Infrastruktur leitet verschlüsselte Datenpakete weiter, kann sie aber nicht lesen, und die Modelle arbeiten in einer isolierten Umgebung. Muss ein Modell mit einem anderen kommunizieren, müssen sich beide TEEs über dasselbe strenge Verfahren gegenseitig ausweisen.

Warum das Gedächtnis in den verschlossenen Raum wandert

Für Erinnerungen über Sitzungen hinweg gibt es einen naheliegenden Weg: Daten auf dem Gerät verschlüsseln und in einer gewöhnlichen Cloud-Datenbank ablegen. Meta erklärt, warum das nicht trägt. Erstens verraten Zugriffsmuster das Verhalten: Selbst wenn der Inhalt stark verschlüsselt ist, sieht die Datenbank, wann geschrieben und gelesen wird, wie oft abgefragt wird und welche Datensätze gemeinsam auftauchen. Diese Metadaten allein zeichnen einen Tagesablauf nach. Zweitens skalieren entfernte verschlüsselte Abfragen nicht, weil komplexe Operationen wie semantische Vektorsuche große Chiffretextmengen durchs Netz ziehen müssten, nur um eine einzige Abfrage zu beantworten. Mit wachsendem Kontext steigen Latenz und Aufwand ins Unbrauchbare.

Die Antwort: Die Speicher-Engine wandert selbst in den verschlossenen Raum. Ausführung und Zustand liegen dann in prozessorgeschütztem Speicher nebeneinander, Abfragen laufen innerhalb der Grenze und müssen keine externe Netzwerkgrenze überqueren. Wer den Schlüssel hat, kann Erinnerungen abrufen; für alle anderen, einschließlich Meta, bleiben sie unzugänglich.

Das erzeugt ein betriebliches Problem, das der Beitrag offen benennt: Wenn Techniker nicht hineinschauen können, helfen klassische Diagnosewerkzeuge nicht mehr. Kein Debugger im laufenden System, keine Speicherabbilder im Fehlerfall, keine Einsicht in fehlerauslösende Datenpakete. Die Beobachtung erfolgt deshalb ausschließlich von außen über aggregierte Signale wie Prozessorlast, Speicherbelegung, Netzwerklatenz und gemessene Ausfallraten des Equipments. Ob das im Alltag reicht, um ein hochverfügbares System ruhig zu halten, bleibt offen.

Was das konkret bedeutet

Der entscheidende Unterschied liegt nicht in der Verschlüsselung, sondern in ihrem Zeitpunkt. Daten während Übertragung und Speicherung zu schützen, ist seit Jahren Standard und löst das eigentliche Problem nicht, weil jede Verarbeitung sie kurzzeitig sichtbar macht. Private Processing für Meta AI Brillen verschiebt den Schutz in genau diesen Moment und macht ihn zusätzlich überprüfbar. Ob das Versprechen hält, hängt allerdings nicht allein an Meta. Es hängt an den Chipherstellern, deren Wurzelschlüssel vertraut werden muss, an den unabhängigen Instanzen, die das Register bezeugen, und an Forschern, die tatsächlich nachrechnen. Spürbar ist davon für Nutzer zunächst wenig, denn die Prüfung passiert im Hintergrund, bevor überhaupt eine Anfrage rausgeht.

Wer eine solche Brille trägt, sollte zwei Dinge auseinanderhalten. Die technische Zusicherung ist eine Aussage über den Weg und den Ort der Verarbeitung, nicht über den Umfang dessen, was ein Gerät mitbekommt. Und sie gilt nur für die Funktionen, die tatsächlich über das beschriebene Verfahren laufen. Was mit dem Nutzerschlüssel passiert, wenn jemand ihn verliert, bleibt in der Darstellung offen, ebenso die Frage, wie viel Kontext eine Erinnerung über Wochen tatsächlich umfasst.

Für den breiteren Markt ist der Ansatz dennoch ein Signal. Cloud-KI und Datenschutz wurden lange als Gegensatz behandelt: entweder leistungsfähig oder vertraulich. Confidential Computing behauptet, dass das nicht mehr stimmen muss, und die Logik ist nachvollziehbar. Bleibt die Frage, ob die Nachprüfbarkeit in der Praxis so selbstverständlich wird wie ein Zertifikat im Browser. Wenn das gelingt, ist es ein Fortschritt, unabhängig davon, welche Brille ihn auslöst.

Quelle: engineering.fb.com