Der Agentenlauf braucht eine Beweiskette

Ein Agent meldet, dass er eine Datei geändert und den Test bestanden hat. Für den Betrieb bleibt eine einfachere Frage offen. Was ist in diesem Lauf tatsächlich passiert?

Ein Receipt verbindet Auftrag, Ausführung und beobachtete Wirkung. Es ist kurz genug für den Alltag und konkret genug für eine spätere Untersuchung.

Was in das Receipt gehört

Für einen relevanten Lauf halte ich Run-ID, Auftrag, Datenklasse, verwendete Quellen, Agent und Modell, Tool-Aufrufe, Freigaben, geänderte Artefakte und Verifikation fest. Vollständige Prompts sind dafür meist nicht nötig.

Metadaten, Hashes und redigierte Auszüge reduzieren das Risiko, dass die Laufzeitspur selbst Secrets oder personenbezogene Daten sammelt. Vollinhalte brauchen einen begründeten Untersuchungszweck und passende Zugriffskontrollen.

Die Spur folgt der Wirkung

Ein Shell-Befehl oder API-Aufruf erklärt noch nicht, warum er zulässig war. Das Receipt verknüpft die Aktion mit dem Auftrag und der Freigabe. Danach hält es fest, welcher Zustand sich wirklich geändert hat.

Bei einer Datei kann das ein Diff und ein Hashvergleich sein. Bei einer Nachricht zählen Empfänger und Versandstatus. Bei einem Deployment gehören Artefaktstand und ein unabhängiger Zustandscheck dazu.

OpenTelemetry als Transport

OpenTelemetry entwickelt semantische Konventionen für generative KI und Agenten. Sie enthalten unter anderem Agentenidentität, Modell, Tool-Aufrufe und verteilte Abläufe. Das ist ein brauchbarer Transport für Laufzeitspuren.

Die Security-Bedeutung entsteht aber nicht automatisch. Auftrag, Trust-Klasse, Freigabe und realer Seiteneffekt müssen im eigenen Kontrollmodell ergänzt werden. Ein Trace-Backend ersetzt diese Entscheidung nicht.

Kurz gesagt

Das Receipt soll keinen inneren Gedankengang des Modells konservieren. Es soll zeigen, welcher Auftrag mit welchen Mitteln zu welcher Wirkung führte und wie diese Wirkung geprüft wurde.

Quellen

OpenTelemetry GenAI Semantic Conventions

NIST AI Risk Management Framework