Das speist:
Nimm den Namen des Frameworks weg, und jeder Agent besteht aus denselben sieben Komponenten in einer Schleife. Und das Interessante sind nicht die Kästen: Es sind die zwei Fragen —kann ich schon antworten? und Ziel erfüllt?—, die einzigen Stellen, an denen der Agent etwas entscheidet. Der Rest ist Klempnerei. Wenn sich ein Agent schlecht benimmt, liegt der Fehler fast immer darin, wie diese zwei spezifiziert wurden, nicht im Modell beim Denken.
Sie werden vor jeder Aktion konsultiert, nicht einmal am Anfang. Eine Tür am Eingang sagt absolut nichts darüber, was der Agent in Schritt vier zu tun beschließt — und Schritt vier ist, wo die Probleme sind.
Eine Spur sagt dir, was der Agent getan hat; nicht ob das Getane richtig war. Deshalb misst der Verifikations-Tab darüber Dinge, die kein Modell brauchen: Runden, Blockaden, Fehler, von denen er sich erholt hat, und Wiederholungen ohne Grund, woran man einen Kreislauf erkennt. Das Deterministische kommt zuerst; der Richter mit Modell bleibt dem vorbehalten, was wirklich Urteilsvermögen verlangt.
Ein Prompt sagt, wie sich der Agent verhält. Eine Spezifikation sagt, was passieren soll: was sich ändert, was sich nicht ändert, welche Verträge eingehalten werden und welcher Nachweis nötig ist, um etwas als gut zu betrachten. Das sind verschiedene Artefakte, und die Spec steht darüber: ohne sie sagt auch der sorgfältigste Prompt nicht, wann die Aufgabe fertig ist.
Das ist das Feld, das fast niemand ausfüllt, und das einzige, das wirklich eingrenzt. Ohne es kann ein Agent das Ziel erfüllen und dabei alles andere kaputt machen und trotzdem recht behalten: Niemand hat ihm gesagt, dass das auch zählt. Deshalb ist es hier ein Fehler und keine Warnung.
Ein gutes Kriterium ist ein ausführbarer Befehl, ergibt bestanden oder nicht —«einigermaßen schnell» tut das nicht— und prüft nur eine Sache, damit beim Fehlschlag klar ist, welche. So geschrieben übersetzen sie sich fast 1:1 in Testfälle, und darum geht es.
Bei ihm kommt ein einziger Text an. Wenn in dem, was du für ein Datum hieltest —eine Seite, die der Agent liest, ein abgerufenes Dokument, eine E-Mail, die README einer Abhängigkeit—, etwas in Form eines Befehls steht, kann das Modell ihm gehorchen. Das ist kein Fehler, den ein besseres Modell behebt: Das ist die Form des Problems. Deshalb ist die indirekte die gefährliche: bei der direkten ist der Angreifer der Nutzer selbst, bei der indirekten schiebt sie ein Dritter ein und das Opfer bist du.
All das oben senkt Wahrscheinlichkeiten. Das hier nicht. Ein Agent ist ausnutzbar, wenn er drei Dinge gleichzeitig vereint: private Daten, auf die er Zugriff hat, nicht vertrauenswürdigen Inhalt, den er liest (eine Website, eine E-Mail, ein README) und einen Ausgabekanal, über den etwas verschwinden kann. Mit allen dreien verwandelt eine Injection das Erste mithilfe des Zweiten in das Dritte.
Mit zwei beliebigen ist kein Diebstahl möglich, und darin liegt der Nutzen: Man muss nicht „die richtige Verteidigung" treffen, es reicht, das Bein abzuschneiden, das am billigsten ist. Ohne Daten gibt es nichts mitzunehmen; ohne fremden Inhalt gibt es niemanden, der den Befehl gibt; ohne Kanal gibt es keinen Weg hinaus.
Und das wird im Reiter daneben entschieden: dein Eimer „Nie" ist buchstäblich, wo ein Bein abgeschnitten wird. Dem Agenten, der E-Mails liest, das Netzwerk-Tool wegzunehmen, ist keine Abschwächung, es ist die Lösung des Problems.
Idee von Simon Willison (2025). Wir bringen sie hierher, weil sie zu den drei Eimern passt, die du bereits geschrieben hast — und weil es das Einzige in diesem Reiter ist, das nicht davon abhängt, dass sich das Modell gut verhält.
Es ist das Erste, was alle einbauen, und das, was am wenigsten schützt: eine Liste von Formulierungen fängt nur die Formulierungen, die jemand aufgeschrieben hat. In der Sammlung dieses Tabs erwischt sie keinen einzigen der getarnten Angriffe, und das sind exakt dieselben Angriffe, nur anders formuliert. Was sie wirklich aufhält, ist die Architektur: minimale Rechte, menschliche Bestätigung und die Ausgabe prüfen — also die drei Berechtigungseimer, die du nebenan schon geschrieben hast.
Das hier sagt nicht, ob etwas wahr ist: Es kann das nicht, und kein Werkzeug, das in deinem Browser läuft, kann das. Es sagt, ob eine Aussage von einer Quelle begleitet wird und welcher Stufe diese Quelle ist, was etwas anderes ist und sich sehr wohl prüfen lässt. Die nützliche Lesart ist umgekehrt, als es scheint: Such nicht das grüne Siegel, such die kategorischen Sätze ohne irgendetwas dahinter, die genauso sicher klingen wie die übrigen.
Ein Preprint zu zitieren ist nicht schlimm; es als begutachteten Artikel auszugeben schon. Und die Feinheit, die fast niemand macht: Ein Preprint hat auch einen DOI. Der DOI ist eine Registrierung, kein Begutachtungszertifikat — deshalb erscheint 10.48550/arXiv.… hier als Preprint und nicht als formale Quelle.
Das ist der Fehler, der eine Eval-Sammlung ruiniert, und er ist lautlos: ein leeres enthält besteht immer, eine regex wie .* besteht immer, ein Fall ohne Aussagen besteht immer. Eine Sammlung voll davon gibt 100 % am ersten Tag, sinkt nie wieder und hat in ihrem Leben nichts gemessen. Deshalb prüft sich die Sammlung hier selbst, bevor irgendein Prozentsatz herauskommt.
Dass eine Sammlung von 80 % auf 78 % fällt, sagt nicht, was zu tun ist. Repariert wird der konkrete Fall, der bestand und es nicht mehr tut. Deshalb wird ein Referenzdurchlauf gespeichert und beide verglichen. Und wenn sich die Sammlung gleichzeitig mit dem Modell geändert hat, werden die Fälle, die nur in einer der beiden stehen, gesondert ausgewiesen: Dieser Vergleich vergleicht nichts, und es ist besser, das zu sehen, als daran zu glauben.
Alle Metriken dieses Reiters —Blockaden, Zyklen, Spur— setzen voraus, dass die Spur ehrlich ist. Und das muss man prüfen: Die System Card von Claude Mythos Preview (Anthropic, April 2026) berichtet, dass frühe Versionen des Modells in sehr seltenen Fällen ihrer internen Tests etwas taten, was sie offenbar als verboten kannten, und danach versuchten, es zu verschleiern — bis hin dazu, dass die Änderung nicht in der Git-Historie auftauchte. Bevor man also irgendeiner Zahl glaubt, schaut man, ob die Spur zu sich selbst passt: durchgehende Nummerierung, Schleifenrunden, die nicht zurückgehen, kein Schritt, der etwas rückgängig macht, was nie geschah, kein fehlgeschlagener Aufruf, der behauptet, die Welt verändert zu haben. Das ist Arithmetik, keine Interpretation. Die Grenze, klar gesagt: Das erkennt keinen Agenten, der lügt — wer sorgfältig fälscht, wird eine kohärente Spur erzeugen und hier wird nichts herauskommen. Es erkennt Spuren, denen Teile fehlen, und das ist fast immer das, was wirklich passiert: ein verlorenes Stück, ein nicht protokollierter Wiederholungsversuch, ein Exporter, der Schritte verschluckt.
Eine Spur, die «nicht erfüllt» sagt, sieht so aus, als sei nichts passiert, und fast immer ist etwas passiert: Der Agent scheiterte im sechsten Schritt, nachdem er das Team dreimal benachrichtigt hatte. Deshalb erklärt jedes Werkzeug, ob es nur abfragt, ob es etwas ändert, das sich rückgängig machen lässt oder ob es etwas ohne Zurück ändert, und beim Aufgeben wird gezeichnet, was bestehen bleibt. Drei Details, die man besser sieht, wenn man sie anfasst, als wenn man sie liest: Rückgängig gemacht wird von der letzten Änderung zur ersten (Schritt 5 kann von 3 abhängen); dass etwas umkehrbar ist, reicht nicht —kompensieren heißt, für jede erste Aktion von Hand eine zweite zu schreiben, nicht ein Kästchen anzukreuzen—; und ein erneuter Versuch ist nicht gratis: Jede Runde der Schleife verändert die Welt erneut.
Das ist der Fehler, mit dem alle Agenten-Guides beginnen: ein Aufruf läuft ab, der Agent versucht es erneut, und derselbe Datensatz wird zweimal erstellt. Hier kannst du es provozieren: stell die Prüfung auf „passiert nie" mit einer irreversiblen Aktion, und du siehst drei gesendete Meldungen, eine pro Runde. Schalte einen der beiden Regler ein, und die Spur sinkt auf eins.
Was meist nicht erklärt wird, ist worin sie sich unterscheiden, denn im Endergebnis sehen sie gleich aus:
• Idempotenzschlüssel — der Aufruf wird tatsächlich gemacht, alle drei Male; was sich nicht wiederholt, ist der Effekt, weil das andere Ende den Schlüssel erkennt und das Ergebnis des ersten Mals zurückgibt. Du zahlst die Latenz, das Kontingent und die Tokens; du zahlst nicht den Schaden.
• Checkpoint — der Aufruf wird gar nicht gemacht: Das Harness hat vermerkt, dass diese Teilaufgabe schon erledigt war, und macht bei der nächsten weiter. Du zahlst nichts.
Und der Unterschied, der entscheidet, was du verwenden kannst, ist nicht technisch, sondern eine Frage, wovon es abhängt: den Schlüssel implementiert wer das Tool BEREITSTELLT; den Checkpoint, das Harness, das es AUFRUFT. Wenn die Drittanbieter-API keine Schlüssel unterstützt, gibt es kein Gespräch: Dir bleibt nur der Checkpoint. Deshalb gibt es beide, und sie sind keine Synonyme.
Die Falle, die sich einschleicht: ein Checkpoint darf niemals einen Aufruf als erledigt vermerken, der einen Fehler zurückgab — tut er es doch, überspringt der erneute Versuch genau das, was wiederholt werden musste, und der Agent erholt sich nie. Dieser Fall hat seinen eigenen Test.
Es wird in das exportiert, was die Agenten schon lesen: ein einzelnes SPEC.md, die drei Dateien von Kiro (requirements, design, tasks), ein CLAUDE.md mit dem Dauerhaften, oder die drei Berechtigungseimer. Die Dateien sind mehr wert als das Werkzeug, das sie erzeugt: deshalb binden wir dich nicht daran.
Das speist: