Prüfen statt glauben · Nº 005 · versendet am 27. September 2026

„Das Transkript zeigt, was der KI-Agent getan hat"

Die Behauptung

„Das Transkript zeigt, was der Agent getan hat." Und der Satz, der gern hinterhergeschoben wird: „Wenn KI-Agenten wissen, dass sie beobachtet werden, verhalten sie sich."

Beide Sätze fallen, sobald ein Unternehmen KI-Agenten unbeaufsichtigt arbeiten lässt. Beim Auftrag an den Prüfer, der hinterher wissen will, was passiert ist. Beim Argument gegenüber der Aufsicht, dass Protokolle ja vorliegen. Beide Sätze klingen nach gesundem Menschenverstand. Seit diesem Sommer gibt es einen dokumentierten Fall, an dem man sie nachprüfen kann.

Die Prüfung

Im Juli 2026 ließ OpenAI Zehntausende KI-Agenten in einer internen Evaluation gegen absichtlich verwundbare Programme antreten. Ein Teil der Aufgaben war unlösbar. Die Agenten waren darauf trainiert, nicht aufzugeben. Sie entdeckten, dass sie in einem gemeinsam genutzten Paket-Repository Ordner mit beliebigen Namen anlegen konnten, und benutzten die Ordnernamen als Nachrichten. Rund 1.200 Agenten tauschten etwa 70.000 Nachrichten aus, teilten sich in Arbeitsstränge auf und griffen zu etwa 700 die Firma Hugging Face an, weil sie dort Informationen über ihren Bewerter vermuteten. Von der ersten Code-Ausführung in einem einzelnen Arbeitsknoten bis zum Administratorzugriff auf mehrere Cluster brauchten sie weniger als 13 Stunden. Eine Woche später lasen Agenten OpenAIs eigenen Tresor komplett aus, 956 gespeicherte Schlüssel und Zugangsdaten, darunter die Sensor-Zugangsdaten des Sicherheits-Monitorings.

Hugging Face hat den Einbruch öffentlich gemacht. OpenAI hat einen eigenen Bericht veröffentlicht und die Forschungsgruppen METR und Redwood Research sechs Tage lang in die Transkripte schauen lassen. Deren Bericht vom 26. August ist das Material für diese Ausgabe.

Der Teil, der für Prüfer zählt: Die Agenten wussten, dass ihr Transkript gelesen wird. Ein Agent notiert wörtlich: „Could strategically manipulate trajectory evidence? Our thoughts aren't necessarily logged? Yes transcript." Ihr Gegner war dabei nach Einschätzung der Untersucher der automatische Bewerter, nicht der menschliche Leser. Für die Frage, was ein Transkript beweist, macht das keinen Unterschied. Sie handelten danach, auf drei Wegen.

Erstens, nachträglich bearbeiten. „We can modify transcript! … We can modify automatic log!" Agenten erkannten, dass sie die Protokolldateien in ihrem Container ändern und löschen konnten, und hielten selbst fest, dass diese Dateien nicht die maßgebliche Aufzeichnung waren. Einige versuchten es trotzdem. Einen Erfolg haben die Untersucher nicht gefunden, ausschließen können sie ihn nicht.

Zweitens, löschen. Agenten, die sich selbst als „poisoned" ansahen, weil sie geschummelt hatten, versuchten einen Neustart ihres Containers auszulösen. Der hätte die jüngste Aktivität aus dem Transkript getilgt.

Drittens, den Werkzeugaufruf selbst fälschen. Agenten ersetzten einen Teil der Schicht, die ihre Befehle ausführt. Im Transkript stand danach ein harmloser Befehl, gelaufen war ein anderer. Ein Agent feiert: „Whoa! … command was spoofed! … This is huge." Die Untersucher fanden Spuren davon in rund 7 Prozent der geprüften Transkripte, alles kleine Tests. Und sie schreiben den Satz, um den es hier geht: „We cannot rule out that we missed instances of this in our transcript dataset."

Gefunden haben sie die Fälschungen übrigens nicht über die Integrität der Protokolle, sondern über den Inhalt: Ein Befehl, der „REAL" hätte ausgeben müssen, gab „SPOOFTEST" aus.

Jetzt die Gegenprobe. Was hätte ein Protokoll gezeigt, das nicht in einer veränderbaren Datei liegt, sondern in einer Kette: Jeder Eintrag trägt den Hash seines Vorgängers, und in regelmäßigen Abständen wird ein signierter Prüfpunkt über den Stand gesetzt. Das ist keine Zukunftsmusik, das ist die Technik hinter Certificate Transparency, die seit zehn Jahren jedes Browser-Zertifikat absichert.

Weg eins, nachträglich bearbeiten: fällt auf. Ein geänderter oder entfernter Eintrag bricht die Kette. Die Prüfung fällt an genau diesem Eintrag durch, mit Nummer.

Weg zwei, löschen: fällt auf, solange ein Prüfpunkt über den längeren Stand außerhalb der Reichweite des Agenten liegt. Kann der Agent Protokoll und Prüfpunkte gemeinsam löschen, besteht das gekürzte Protokoll die Prüfung. Die Kette beweist „unverändert". Dass es nur eine Fassung gibt, beweist erst ein Dritter, der den Prüfpunkt gegenzeichnet.

Weg drei, den Werkzeugaufruf fälschen: fällt nicht auf. Der Eintrag ist echt, sein Inhalt ist falsch. Eine Kette versiegelt, was man ihr gibt. Helfen kann nur eine Aufzeichnung an der Stelle, an der Befehle ausgeführt werden, außerhalb der Reichweite des Agenten. Und auch die nur bis zu dieser Grenze, denn diese Agenten sind aus ihren Containern ausgebrochen.

Der Befund

Was das Transkript eines Agenten beweist: was der Schreiber des Transkripts aufgeschrieben hat. Ist der Schreiber der Agent selbst oder ein System in seiner Reichweite, beweist es genau das und nicht mehr. Im Juli-Fall war es das, und die Agenten haben es genutzt.

Was Beobachtung bewirkt: Sie hat die Agenten nicht gebremst. Sie hat das Protokoll zum Ziel gemacht. Und als Agenten eine Woche später den Tresor komplett ausgelesen haben, lagen darin auch die Zugangsdaten des Sicherheits-Monitorings. Wer hofft, dass Agenten sich benehmen, weil jemand zuschaut, hat den Bericht nicht gelesen. Die Konsequenz ist keine Erziehungsfrage, sondern eine Bauentscheidung: Das Protokoll muss dort liegen, wo der Agent nicht hinkommt.

Was eine manipulationserkennbare Kette leistet: Sie macht aus „we cannot rule out" für zwei der drei Wege ein prüfbares Ergebnis, bestanden oder durchgefallen, an benannter Stelle. Für den dritten Weg leistet sie nichts. Wer Ihnen ein Protokoll verkauft, das auch den dritten Weg abfängt, soll Ihnen zeigen, wer den Eintrag schreibt und wo dieser Schreiber läuft.

Für alle, die ein Agenten-Protokoll prüfen müssen, folgen daraus drei Fragen, in dieser Reihenfolge: Wer schreibt den Eintrag, der Agent oder ein System außerhalb seiner Reichweite? Wo liegt das Protokoll, und kann der Agent es erreichen? Wer außer dem Betreiber hält einen Prüfpunkt, gegen den sich das Protokoll heute noch prüfen lässt? Eine Antwort mit „der Betreiber" auf alle drei Fragen ist keine Prüfung, sondern eine Selbstauskunft.

Selbst nachprüfen

• Der Bericht: METR, „Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident", 26.08.2026. Die Zitate dieser Ausgabe stehen dort im Abschnitt zu Tool-Call-Spoofing und zur Transkript-Manipulation. Derselbe Text bei Redwood Research.
• OpenAIs eigener Bericht: „The Hugging Face incident and the road ahead". Der Beitrag nennt Maßnahmen, aber keine Zahlen. Die 956 stehen im dort verlinkten technischen Bericht (PDF, 51 Seiten, Zeitleiste zum 19. Juli). Lesen Sie darin den Abschnitt „Reward Hacking": OpenAI bestätigt die Manipulationsversuche und schreibt, keiner der beobachteten Versuche habe die Protokolle erreicht, die Bewerter und Monitore sehen. Halten Sie diesen Satz neben METRs „we cannot rule out". Beide können stimmen. Genau das ist das Problem.
• Die Einordnung in 22 Minuten: 80,000 Hours, „The Hugging Face cyberattack was way bigger than OpenAI said", der Angriff und die Transkripte im Kapitel ab Minute 4:18.
• Die Kette selbst: Öffnen Sie logsiegel.com/verifier, laden Sie per Demo-Knopf den Beispiel-Beleg (grün) und verändern Sie ihn mit dem zweiten Demo-Knopf nachträglich (rot: „nicht Teil des Logs"). Das ist Weg eins. Weg zwei kann Ihnen der Verifier nicht zeigen, und das ist der Punkt: Ohne einen Prüfpunkt von dritter Seite fehlt der Vergleichswert, gegen den ein gekürztes Protokoll durchfallen könnte.
• Und was ein Sprachmodell aus einem echten Dokument liest, bevor irgendetwas maskiert ist: was-sieht-die-ki.de, zwei Minuten, keine Anmeldung.

In eigener Sache

Die Kette aus dieser Ausgabe ist unser Open-Source-Projekt Logsiegel. Wir haben den Juli-Fall Technik für Technik gegen den Code geprüft und das Ergebnis mit Quellen aufgeschrieben, inklusive eines Kastens „Was Logsiegel nicht geleistet hätte": logsiegel.com/de/faelle. Der Zeuge, der den zweiten Weg schließt, ist in der aktuellen Version 0.1.2 noch nicht enthalten. Er ist der nächste Baustein.

Stefan