Ein Agent erzeugt eine Implementierung, lässt die Verifikation laufen, sieht sie scheitern, verändert den Code und startet den Durchlauf erneut. Am Ende steht ein Commit, bei dem alle Kontrollen grün sind, und eine Attestierung, die diesen Endzustand festhält: welche Prüfungen liefen, mit welchem Ergebnis und welcher Laufzeit, dazu der Commit-Hash und Checksummen der Konfiguration, die den Lauf gesteuert hat.
Das genügt zum Ausliefern. Es genügt nicht, um zu verstehen, was unterwegs geschehen ist. Ein Entwickler, der an einer solchen Software-Fabrik arbeitet, beschreibt diesen Punkt als dritte Folge einer Reihe über Agenten und CI – und benennt darin eine Lücke, die mit jeder Stufe zusätzlicher Automatisierung größer wird. In der Forschung gibt es dafür ein altes Gegenmittel: das Laborjournal, in dem nicht nur das Endergebnis steht, sondern auch jeder Fehlversuch.
Was verschwindet, wenn der Agent die Reparaturschleife besitzt
Ein Agent implementiert etwas, die Tests schlagen fehl, er interpretiert die Fehlermeldungen, ändert den Code und lässt erneut prüfen. Es folgen weitere Fehlschläge, weitere Korrekturen, irgendwann passt alles. Die Attestierung dokumentiert dann den Endzustand: alle Checks grün an diesem Commit. Laut dem Autor erfassen die Attestierungen bei Swamp dabei mehr als die meisten Agenten-Setups, nämlich jede ausgeführte Kontrolle mit Ergebnis und Dauer, den Commit-Hash und sha256-Prüfsummen der Konfiguration, die den Lauf bestimmt hat. Das deckt die Integrität der Konfiguration und das Verifikationsergebnis ab.
Was fehlt, ist der Weg dorthin. Welche Fehlschläge der Agent angetroffen hat, wie er sie gedeutet hat, welche Zwischenstände er gebaut und wieder verworfen hat – nichts davon hinterlässt eine Spur. Für das Ausliefern ist das unerheblich: Tests bestehen, der Linter ist sauber, das Review hat nichts beanstandet, also geht die Änderung raus. Für Governance zählt es dagegen, weil dort Fragen gestellt werden, die nur die Zwischenschritte beantworten können.
Warum Verantwortlichkeit nicht das schwierige Problem ist
Die Frage, die in Diskussionen immer wieder auftaucht: Wer ist verantwortlich, wenn eine Maschine den Code geschrieben hat? Die Antwort des Autors ist nüchtern: verantwortlich ist die Person, die den Auftrag erteilt hat – so wie man für alles geradesteht, was man ausliefert, unabhängig davon, welche Werkzeuge daran beteiligt waren. Das Stanford Law CodeX Centre hat im Februar von einem Haftungsvakuum gesprochen, in dem sich Verantwortung über Entwickler, Modellanbieter und Hersteller verteilt. An der Grenze zwischen Anbieter und Kunde trifft das zu, denn die rechtlichen Rahmenwerke für zugesicherte Agenten-Software sind unterentwickelt. Auf der Ebene der Praxis ist die Zuständigkeit dagegen klar.
Wer die Anweisung gibt, die Verifikationskriterien definiert und das Ergebnis ausliefert, trägt die Folgen. Das schwierigere Problem liegt eine Ebene tiefer: Kann diese Person ihre Aufgabe überhaupt wahrnehmen? Wenn in der Produktion etwas schiefgeht und die Spur zu einer agentengesteuerten Änderung führt, braucht man belastbare Antworten auf sehr konkrete Fragen. Hat der Agent während der Verifikation einen verwandten Fehler angetroffen und umgangen, statt die Ursache zu beheben? Hat das Review das problematische Muster markiert, und hat der Agent falsch darauf reagiert? Hat die Prüfkonfiguration die relevante Testkategorie gar nicht abgedeckt?
Solche Fragen stellt jede Incident-Aufarbeitung auch bei menschlich geschriebenem Code. Der Unterschied liegt in den Spuren. Entwicklerinnen und Entwickler hinterlassen Commit-Historien, Diskussionen im Pull Request, Nachrichten im Chat und die Erinnerung des Reviewers daran, worüber er sich Sorgen gemacht hat. Eine agentengesteuerte Verifikationsschleife hinterlässt einen finalen Commit und eine Attestierung des letzten Durchlaufs. StrongDM hat mit seiner veröffentlichten „Software Factory“ eine Richtung beschrieben, in der Agenten Code schreiben und gegen eine digitale Zwillingumgebung testen, ohne dass ein Mensch den Code liest. Ob Audit-Spuren für Agentenentscheidungen, Rollback-Verfahren oder die Weitergabe von Spezifikationsfehlern vorgesehen sind, bleibt in dieser Darstellung offen.
Was Iterationsprovenienz leisten kann – und was nicht
Hier lohnt ein genauer Blick darauf, was zu den bereits etablierten Eigenschaften hinzukommt. Konfigurationsintegrität beantwortet die Frage, ob die erwarteten Regeln und Prompts den Lauf bestimmt haben; die Attestierung trägt Prüfsummen von Review-Prompts, Workflow-Definitionen und Konfigurationsdateien, und die Pipeline kann diese Dateien am verifizierten Commit erneut hashen und vergleichen. Ergebnisintegrität beantwortet die Frage, ob die Kontrollen tatsächlich ausgeführt wurden und das behauptete Resultat erzeugt haben. Aus der Attestierung allein ist das nicht vollständig beweisbar, und für Kontrollen mit höherem Absicherungsbedarf bleibt die Ausführung auf unabhängiger Infrastruktur der richtige Weg.
Iterationsprovenienz beantwortet eine dritte Frage: Was ist unterwegs passiert? Welche Fehlschläge traten auf, welche Codeänderungen folgten daraus, und wie führte die Abfolge der Versuche zum Endzustand? Sie beweist nicht, dass ein Lauf ehrlich war oder dass der Agent einen Fehler richtig gedeutet hat. Sie macht den Prozess im Nachhinein prüfbar. Das ist der Unterschied zwischen einer Untersuchung, die stattfinden kann, und einer, für die kein Material existiert.
Was ein brauchbarer Iterationsdatensatz enthalten muss
Zuerst Identität und Konfigurationsinhalt: welches Agentsystem, welche Modellversion, welches Instruktionsset den Lauf gesteuert hat. Ein Review-Prompt ist ausführbare Politik – ändert man ihn, ändert sich, worauf das Review achtet. Prüfsummen in der Attestierung bestätigen zwar, dass die Konfiguration dem eingecheckten Stand entspricht, doch wenn die Ausgabe eines Agenten infrage steht, muss der tatsächliche Inhalt der Prompts und Regeln dauerhaft wiederherstellbar bleiben und nicht nur der Nachweis, dass er einmal gepasst hat. Prompts und Workflow-Definitionen als versionierte Dateien im Repository sind dafür die naheliegende Ablage.
Dann die Iterationshistorie: die Abfolge von Verifikationsfehlern und zugehörigen Codeänderungen, erfasst als strukturierte Daten. Keine vollständigen Gesprächsprotokolle. Der Datensatz soll beobachtete Fehlschläge mit den Änderungen und Wiederholungen verknüpfen, ohne die Erklärung des Agenten als Beweis für die Ursache zu behandeln. Die diagnostische Begründung eines Agenten ist ein brauchbarer Input für eine Untersuchung, aber keine verlässliche Schlussfolgerung. Eine aktuelle Übersichtsarbeit zur Execution Provenance bei LLM-Agenten unterscheidet zwischen der vollständigen Aufzeichnung eines Laufs und dem auf Belege reduzierten Ausschnitt, der zeigt, welche Evidenz welche Entscheidung gestützt hat. Die Governance-Ebene braucht den Belegausschnitt, nicht die Gesamtaufzeichnung.
Hinzu kommen Metadaten zur Verifikationsabdeckung: welche Prüfungen liefen, welche Fehlerkategorien sie hätten erkennen können und welche nicht. Eine grüne Testsuite sagt nichts darüber, ob die Tests die geänderten Codepfade überhaupt berühren oder ob die Änderung Verhalten einführt, das kein bestehender Test ausübt. Ohne diese Metadaten lässt sich „geprüft und sicher“ nicht von „gegen eine unvollständige Prüfmenge verifiziert“ unterscheiden. Schließlich die Review-Provenienz: welcher Review-Prompt gegolten hat, was geprüft wurde, was beanstandet wurde und wie die Beanstandungen aufgelöst wurden. Menschliches Code-Review war immer ein unstrukturiertes Gespräch; ein durch versionierte Prompts gesteuertes Agenten-Review kann strukturierte Belege darüber liefern, was es tatsächlich geprüft hat – aber nur, wenn man sie festhält.
Warum die Werkzeuge der Supply-Chain-Sicherheit in die falsche Richtung zeigen
Die Community für Lieferkettensicherheit hat über ein Jahrzehnt in Provenienzinfrastruktur investiert. in-toto beschreibt Software-Lieferketten als Schritte autorisierter Funktionsträger mit kryptografischer Verkettung von Schritt zu Schritt. SLSA definiert abgestufte Ebenen der Build-Provenienz, von L1, wo Provenienz überhaupt existiert, bis L3 mit gehärteter Build-Umgebung und Manipulationsschutz. Googles Binary Authorization for Borg setzt Provenienzrichtlinien an der Deployment-Grenze durch, und Sigstore hat die Hürde des Schlüsselmanagements beseitigt, an der die meisten Open-Source-Projekte zuvor gescheitert sind.
Diese Infrastruktur ist ausgereift und löst reale Probleme. Sie teilt allerdings eine Annahme: Code wird von Menschen geschrieben, von Maschinen gebaut, und die interessanten Provenienzfragen betreffen die Build- und Deployment-Kette. Der Autorenschritt liegt entweder außerhalb des Geltungsbereichs oder wird durch eine einzige Zusicherung abgehandelt – ein Mensch hat das über ein Code-Review eingereicht. Sobald der Autorenschritt eine innere Struktur bekommt, die es wert ist, festgehalten zu werden, muss die Provenienzkette sich rückwärts verlängern. Die Bausteine existieren: Soll-Politik gegen Ist-Belege, autorisierte Akteure, kryptografische Verkettung von Schritten, abgestufte Absicherungsniveaus. Auf die agentengesteuerte Verifikationsschleife angewandt, ist das eine Erweiterung, keine Erfindung.
Der kleinste nützliche Datensatz – und was daraus folgt
Der praktikable Anfang besteht darin, einen abgeschlossenen Agentenlauf nachträglich rekonstruierbar zu machen. Für jeden Versuch bleiben der eingehende und der ausgehende Commit beziehungsweise Diff erhalten, die ausgeführten Prüfungen mit ihren Fehlerrückgaben, das Modell und die Konfiguration des Laufs sowie eine Verknüpfung zum nachfolgenden Versuch. Diese Sequenz wird an die abschließende Attestierung gebunden. Das erfordert kein vollständiges Gesprächsprotokoll, sondern so viel strukturierte Evidenz, dass jemand den Pfad von der ersten Implementierung über jeden gescheiterten Versuch bis zum grünen Ergebnis nachvollziehen kann, wenn eine Änderung erklärungsbedürftig wird.
Wird dieser Datensatz signiert, sind spätere Manipulationen erkennbar. Werden die Kontrollen in einer gehärteten Umgebung ausgeführt, steigt die Gewissheit, dass der Datensatz das tatsächliche Geschehen abbildet. Beides hilft wenig, wenn die Iterationshistorie von vornherein verworfen wurde. Eine abschließende Attestierung kann belegen, dass die geforderten Kontrollen für einen bestimmten Commit bestanden wurden. Sie kann nicht zeigen, ob der Agent früher auf einen relevanten Fehler gestoßen ist, welche Änderung er daraufhin vorgenommen hat und ob diese Antwort das zugrunde liegende Problem adressierte. Genau diese Fragen wird eine Incident-Aufarbeitung beantworten müssen.
Wenn Agenten ihre eigene Arbeit so lange reparieren dürfen, bis das Ergebnis grün ist, muss die Geschichte dieser Reparaturen ein Artefakt einer Softwareänderung werden – gleichrangig neben dem Code, den Tests und der finalen Attestierung. Der Autorenschritt hat sich verändert. Die Aufzeichnung dieses Schritts darf nicht verschwinden, nur weil am Ende alle Ampeln grün stehen.
Quelle: stack72.dev
