ai-agents observability audit-logging agent-frameworks security opentelemetry

AI-Agent-Audit-Logs benötigen 12 Felder: Was LangChain, CrewAI und vier weitere Tools aufzeichnen.

Eine statische Zählung von sechs Agent-Frameworks – von LangChain und CrewAI bis zum OpenAI Agents SDK – im Vergleich zu einem Entwurf für eine 12-Felder-Auditrückverfolgung: Die durchschnittliche Abdeckung beträgt 5 von 12.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 202610 Min. Lesezeit2321 Wörter

Quellen: AI Agent Audit Logs Need 12 Fields. We Counted 6 Frameworks — the Median Records 5.

Ein Spur erscheint wie Beweismittel, ist es aber nicht

Stellen Sie sich vor, ein Agent ruft ein Tool auf: Es erfolgt eine Geldüberweisung, eine Zeile in einer Datenbank wird gelöscht oder eine Nachricht wird gesendet. Danach muss jemand eine Frage beantworten, nämlich ob die Handlungen des Agents nachgewiesen werden können. Die Spur wird geöffnet und zeigt einen Zeitraum mit Namen, Startzeit, Eingabe und Ausgabe an. Das sieht wie Beweismittel aus, ist aber nur ein Hilfsmittel zum Fehlersuchen, das die Gestalt von Beweismitteln angenommen hat.

Zur Messung der Lücke wurden am 4. September 2026 die neuesten Commit-Versionen von sechs Open-Source-Agenten-Frameworks sowie deren Instrumentierungs-Spezifikationen geklont: OpenAI Agents SDK, LangChain, CrewAI, LlamaIndex, smolagents und OpenInference. Die Felder aus den Tool-Call-Protokollen jedes Projekts wurden extrahiert und mit den zwölf obligatorischen Feldern im neuesten Format für Agenten-Auditrückverfolgung verglichen. Das Ergebnis: Das typische Framework erfasst fünf der zwölf für ein Auditrückverfolgungsprotokoll notwendigen Felder, und keines der sechs Frameworks verfügt über ein einziges Feld zur Nachweismöglichkeit von Manipulationen.

Welche Frameworks welche Felder erfassen, ist hilfreich für das Debuggen. Auditrückverfolgungsprotokolle dienen einem anderen Zweck, und der Unterschied zwischen diesen beiden Zwecken lässt sich quantifizieren.

Fünf Erkenntnisse aus der Analyse

Bei allen fünf Frameworks liegt die mittlere Abdeckung bei 5 von 12 obligatorischen Feldern: smolagents hat 1, LlamaIndex 3, OpenAI Agents SDK 5, CrewAI 5 und LangChain 6.
Der String trust_level kommt in keiner Datei in allen sechs Codebasen vor. Eine Suche in jeder Python- und TypeScript-Datei in jedem Repository ergibt nichts.
Auch prev_hash, previous_hash und hash_chain weisen keine Ergebnisse in Dateien auf. Kein Framework verknüpft einen Eintrag mit dem nächsten, sodass ein Trace-Store später unverändert bearbeitet werden kann, ohne Spuren zu hinterlassen.
OpenInference, die umfassendste Instrumentierungsspezifikation im Ökosystem mit 119 namensgebundenen Span-Attributen, erreicht dennoch nur 8 von 12 Feldern und enthält kein Feld zur Nachweispflege von Manipulationen.
Nur ein Feld, timestamp, wird von allen fünf Frameworks protokolliert. agent_id, session_id und record_phase kommen jeweils in einer von fünf Dateien vor, während agent_version, outcome und trust_level in keiner vorkommen.

Frameworks verfügen über gute Instrumentierung zur Fehlersuche und über schwache Instrumentierung zur Erstellung von Beweisen. Die beiden ähneln sich so sehr, dass der Ersatz unbemerkt bleibt, bis jemand nach Beweisen fragt. Die fehlenden Felder sind nichts Ungewöhnliches. Sie klären, wer gehandelt hat, unter wessen Autorität und ob die Aufzeichnung später verändert wurde – Fragen, auf die eine Fehlersuchungsprotokollierung niemals antworten musste.

Wie die Zählung durchgeführt wurde

Die Commits wurden pro Projekt korrigiert: OpenAI Agents SDK (openai-agents-python) bei 89c02c8, LangChain bei 0d50cbd, CrewAI bei 92eb5f9, LlamaIndex bei d2ac544, smolagents bei 30bb116 sowie OpenInference bei 479d168. Die Feldliste für jedes Projekt stammte von der Klasse, die einen einzelnen Tool-Aufruf protokolliert – also den Zeitraum zusammen mit dem für das jeweilige Tool spezifischen Payload – und wurde aus den Klassendefinitionen und nicht aus den Dokumentationen abgerufen. Anschließend wurden die Felder mit den zwölf obligatorischen Feldern im aktuellen Entwurf des Audit-Trail abgeglichen.

Falls ein Feld nur teilweise eine Anforderung erfüllt, erhielt es eine „teilweise“-Bewertung zusammen mit einer Begründung. Beispielsweise gibt LangChain’s error-Feld an, dass etwas fehlgeschlagen ist, unterscheidet jedoch nicht zwischen Fehlschlag, Zeitüberschreitung, Ablehnung oder Eskalation.

Die Aufnahme zeigt den Ablauf selbst: sechs Repositorien an der Spitze, jedes Feld der Tool-Aufrufe wurde extrahiert und gegen die zwölf Felder bewertet. trust_level und prev_hash ergeben überall den Wert null.

Die zwölf Felder

Als Maßstab dient das Internet-Draft „Agent Audit Trail“, Revision 02, das von Raza Sharif von CyberSecAI am 3. September 2026 veröffentlicht wurde. Es handelt sich um einen individuellen Vorschlag und nicht um ein anerkanntes IETF-Standard, weshalb er als sorgfältig durchdachtes Angebot und nicht als festgelegtes Gesetz gilt. Dennoch ist es die konkreteste veröffentlichte Antwort, und seine zwölf obligatorischen Felder lassen kaum Widerspruch zu:

record_id ist eine eindeutige Identifikationsnummer für die Aufzeichnung.
timestamp gibt die Zeit des Ereignisses im RFC 3339-Format an.
agent_id gibt die Instanz des Agenten an, der gehandelt hat, und agent_version gibt die Version seiner Software an.
session_id verknüpft die Aktion mit einer Sitzung.
action_type verwendet ein kontrolliertes Vokabular statt freier Texte, und action_detail enthält den für den Typ spezifischen Inhalt.
outcome kann success, failure, timeout, denied oder escalated sein.
trust_level gibt das Autorisierungslevel an, unter dem der Agent agiert hat, von L0 bis L4.
parent_record_id verweist auf das vorherige Record in der Kette, und prev_hash enthält dessen SHA-256-Hash.
record_phase angibt an, ob das Record vor, während oder nach der Ausführung geschrieben wurde.

Stellen Sie diese Liste neben ein Span-Objekt, und der Überblick über das Problem wird sichtbar. Die ersten acht Felder sind solche, die ein Debugger wahrscheinlich benötigen würde, während die letzten vier nur für einen Prüfer von Bedeutung sind – und genau diese vier fehlen.

Zählungen nach Framework

Anzahl der Felder im Tool-Aufruf-Record sowie der Abdeckungsgrad gegenüber den zwölf Frameworks:

CrewAI (ToolUsageFinishedEvent plus BaseEvent): 25 Felder, davon 5 vollständig, 3 teilweise und 4 fehlend.
LangChain und LangSmith (RunTree 0.12.1): 20 Felder, davon 6 vollständig, 1 teilweise und 5 fehlend.
OpenAI Agents SDK 0.22.0 (SpanImpl plus FunctionSpanData): 13 Felder, davon 5 vollständig, 2 teilweise und 5 fehlend.
LlamaIndex (SimpleSpan plus BaseEvent): 10 Felder, davon 3 vollständig, 1 teilweise und 8 abwesend.
smolagents 1.26.0 (Timing plus TokenUsage): 6 Felder, davon 1 vollständig, keine teilweise und 11 abwesend.
OpenInference semantic conventions definieren 119 namensraumbelegte Spann-Attribute (unterschiedliche mit Punkten versehene Attributnamenkonstanten bei Commit 479d168, wobei weitere 43, die Enum-Werte sind, ausgeschlossen werden), und bewerten 8 als vollständig, 1 als teilweise und 3 als abwesend.

Die Anzahl der Rohfelder sagt nichts über die Prüfbarkeit aus. CrewAI protokolliert zwar die meisten Felder, erfüllt aber weniger Anforderungen als LangChain, da ein Großteil der fünfundzwanzig Felder den Teamkontext beschreiben, wie beispielsweise agent_role, from_task, plan_step_number und delegations. Sie sind nützlich, beantworten aber weiterhin keine Prüfungsfragen. Die Umfangreiche Instrumentierung steht in kaum einem Zusammenhang mit der Eignung als Beweismittel.

Der Chart zeigt es eindeutig: CrewAI weist mehr Felder auf als jedes andere Framework, erfüllt aber weniger Anforderungen als LangChain, weil die meisten zusätzlichen Felder den Teamkontext und nicht Beweismittel betreffen.

Eines unterscheidet CrewAI von anderen: Es gibt ToolUsageStartedEvent und ToolUsageFinishedEvent als separate Klassen, wodurch es allein über eine echte record_phase verfügt – eine Aufzeichnung, die bereits vor dem Ausführen des Tools existiert. Das ist wichtiger, als es scheint, denn ein rein nachträglich erstellter Protokoll kann zwar anzeigen, dass etwas geschehen ist, doch nicht, ob es zuvor genehmigt wurde.

Was keine Frameworks aufzeichnen

Vier der zwölf Felder fehlen in allen fünf Frameworks, und zwei davon bleiben auch dann aus, wenn die Spezifikationen zur Instrumentierung berücksichtigt werden.

trust_level kommt in keinem der Dateien der sechs Repositorien vor. Ohne dieses Feld wird die Autorität, unter der ein Agent handelt, nicht erfasst, sodass ein Protokoll keine Unterscheidung zwischen erlaubten und verbotenen Aktionen vornehmen kann.
prev_hash kommt in keiner Datei vor, genauso wenig wie previous_hash und hash_chain. Es gibt keine Verknüpfung zwischen den Datensätzen, und ein Trace-Store ist eine gewöhnliche Datenbank, deren Zeilen geändert werden können.
agent_version fehlt in allen fünf Frameworks. Er existiert nur in OpenInference als Spiegelung von OpenTelemetrys gen_ai.agent.version – ein Wert, der gesetzt werden kann, der aber nach dieser Analyse von den Frameworks selbst im Grunde nie gesetzt wird.
outcome als Klassifizierung erhält von keinem Framework eine volle Punktzahl. Alle verfügen über ein Feld für Fehler, doch keines unterscheidet zwischen „abgelehnt“ und „fehlgeschlagen“, der Unterschied, den Prüfer am meisten schätzen.

Suchanfragen nach non_repudiation und pre_execution liefern ebenfalls keine Ergebnisse.

Warum die Felder fehlen

Diese Tools wurden für eine andere Frage entwickelt. Ein Protokoll hilft einem Ingenieur dabei herauszufinden, warum etwas langsam oder falsch ausgeführt wurde, und input, output, duration sowie ein Elternzeiger reichen dafür in der Regel aus. Die Beweise müssen auch gegenüber einem Gegner standhalten, einschließlich dessen, der das Protokoll kontrolliert, und keines dieser Systeme wurde unter Berücksichtigung dieser Bedrohung konzipiert. Die Lücken sind kein Versäumnis. Bis dieses Jahr hat niemand erwartet, dass Protokolle gleichzeitig als Beweismittel dienen können.

Der stärkste Gegenargument

Kann OpenTelemetry die Lücke schließen? Teils. OpenInference deckt 8 von 12 Aspekten ab, das beste Ergebnis in der Gruppe, und OpenTelemetries GenAI-Konventionen definieren gen_ai.agent.id und gen_ai.agent.version, wodurch die Identitätslücke theoretisch geschlossen wird. Bei konsequenter Anwendung würde allein die Einführung dieser Standards vier der zwölf Probleme ohne zusätzliche Arbeit lösen.

Doch die beiden schwierigsten Anforderungen sind noch ungelöst. Ein Manipulationsnachweis kann nicht als Attribut zu einem Span hinzugefügt werden, da er zum Store und nicht zum Record gehört. Eine Hash-Kette ist nur dann sinnvoll, wenn sie an einem Ort geschrieben wird, an dem der Schreiber sie nicht überschreiben kann. Zudem benötigt record_phase ein vor der Ausführung der Aktion erzeugtes Record – das ist eine architektonische Entscheidung bezüglich des Zeitpunkts und kein später hinzugefügtes Feld. Beides fällt nicht unter semantische Konventionen.

Beschränkungen der Messung

Eine Zahl ist nur nützlich, wenn ihre Grenzen eindeutig sind; daher sind die Einschränkungen wichtig:

Es handelt sich um eine statische Analyse und keine Laufzeit-Überwachung. Nur die von den Klassen definierten Felder wurden gezählt. Sechs Agenten wurden nicht mit ihren erzeugten Payloads verglichen, und ein Framework könnte ein Feld über ein Erweiterungsmechanismus füllen, der nicht nachverfolgt wurde.
metadata, tags und extra dienen als Ausweichmöglichkeiten und wurden als nicht vorhanden bewertet. Die meisten dieser Frameworks akzeptieren beliebige Schlüssel, sodass ein entschlossenes Team eine Hash-Kette in extra speichern könnte. Die Zählung bezieht sich auf Standardwerte und nicht auf Obergrenzen.
Das Naheliegendste an einer Signatur existiert tatsächlich nicht. OpenInference definiert message_content.signature, doch seine Dokumentation beschreibt einen undurchsichtigen, vom Anbieter bereitgestellten Wert, der unverändert gespeichert wird, ähnlich wie Geminis thoughtSignature. Er garantiert den Inhalt der Argumentation des Modells und nicht die Integrität der Aufzeichnung, und nur der Anbieter kann ihn überprüfen. Die bewusste Bewertung als nicht vorhanden dient als Beweis gegen Manipulationen.
Die Referenz mit zwölf Feldern ist ein Entwurf eines Autors aus Revision 02 und daher noch nicht ratifiziert; daher wird trust_level zu Recht in Frage gestellt. Wenn sich die Anforderungsliste ändert, ändern sich auch die Abdeckungszahlen.
Sechs Projekte bilden nicht das gesamte Ökosystem – Pydantic AI, Semantic Kernel, AutoGen sowie kommerzielle Plattformen wurden nicht berücksichtigt.
Die Existenz sagt wenig über die Qualität aus. timestamp gilt in allen fünf Fällen als erfüllt, doch ein einfacher datetime.now() ohne Zeitzone oder ohne Bezugspunkt ist weitaus schwächer als ein RFC 3161-Timestamp.

Was dies nicht entscheiden kann, ist, ob irgendetwas davon für ein bestimmtes System von Bedeutung ist. Ein Agent, der Dokumente liest und Texte erstellt, profitiert stark von einer Debugging-Trace, während auditfähige Aufzeichnungen übertrieben wären. Der Unterschied spielt nur dann eine Rolle, wenn die Handlungen eines Agents Konsequenzen haben, die später angefochten werden könnten.

Drei Änderungen nach Reihenfolge der Nutzenhaftigkeit

Führen Sie vor der Ausführung ein Protokoll auf. Das bedeutet vor dem Aufruf und nicht danach – dabei werden die Protokoll-ID, das Zeitstempel, die Agent-ID und Version, die auszuführende Aktion sowie die dahinterstehende Autorisierung notiert. CrewAI verwendet ein vorgefertigtes Muster für den Start-/End-Zustand, während andere Systeme dieses manuell erstellen müssen.
Vereinigen Sie Protokolle in eine nur zum Hinzufügen geeignete Speicherung. Das Hashen des vorherigen Protokolls mit SHA-256 kostet fast nichts. Entscheidend ist der Speicherort, nicht das Hash selbst.
Geben Sie outcome ein Vokabular. Mit fünf Werten (Erfolg, Fehler, Zeitüberschreitung, Ablehnung, Eskalation) wird der Unterschied zwischen einem Tool-Fehler und einer Ablehnung abfragbar und bleibt nicht in einem String verborgen.

Es ist kein neues Framework erforderlich, lediglich etwa zweihundert Zeilen zu dem vorhandenen. Es spiegelt das Muster von stillen Agentenfehlern wider, die von Dashboards übersehen werden, bei denen Abwesenheit wie Funktionsfähigkeit erscheint, weil nichts aufgezeichnet wurde.

Schnelle Antworten

Wie unterscheidet sich ein Agenten-Trace von einem Audit-Log? Traces werden für Ingenieure erstellt, die das Verhalten später erklären möchten, und sie gehen von einem ehrlichen Verfasser aus. Audit-Logs hingegen dienen Parteien in Streitfällen und müssen Identität, Autorität und Integrität nachweisen – also wer gehandelt hat, mit welcher Befugnis und ob der Eintrag seitdem geändert wurde. Im Vergleich weisen die Frameworks jeweils zwischen 6 und 25 Trace-Felder auf, erfüllen aber im Durchschnitt nur 5 Audit-Anforderungen.

Können LangChain-Spuren für Audits bereitgestellt werden? Nur teilweise, und zwar durch Aufbau auf dem Framework anstatt dessen Konfiguration. LangSmiths RunTree stellt 6 von 12 Feldern direkt bereit, darunter session_id und parent_run_id. Noch fehlen Angaben dazu, um welchen Agenten es sich handelt und welche Version ausgeführt wurde, ein fester Satz an Ergebniswerten, ein Vertrauensniveau, ein vor der Ausführung geschriebenes Protokoll sowie eine Hash-Kette, die in einem nur zum Hinzufügen zugänglichen Speicher aufbewahrt wird. Benutzerdefinierte Daten können im extra-Feld gespeichert werden, doch nichts füllt dieses Feld automatisch aus.

Löst OpenTelemetry das Problem? Es deckt den Teil zur Identifizierung ab. Beweise für Manipulationen sowie die Aufzeichnung vor der Ausführung bleiben ungelöst, da sie von dem Zeitpunkt und Ort abhängen, an denen die Protokolle geschrieben werden, und nicht davon, welche Attribute ein Span enthält.

Welches Framework ist heute am auditfreundlichsten? LangChain über LangSmith deckt mit 6 von 12 Aspekten den größten Umfang ab, während CrewAI einzigartig eine echte Vorausführungsprotokoll-Überlieferung sowie einen erstklassigen agent_id anbietet. Keines der beiden Frameworks ist bereits für Audits bereit. Wenn Auditableität unverhandelbar ist, sollte die Beweisschicht separat entwickelt werden und die Spur des Frameworks als Rohdateneingang behandelt werden.

Ist eine Hash-Kette für ein internes Tool übertrieben? In der Regel ja. Der entscheidende Test ist, ob jemand außerhalb des Teams jemals auf das Protokoll angewiesen sein könnte – beispielsweise ein Kunde, ein Geschäftspartner, eine Versicherungsgesellschaft oder bei der Prüfung von Vorfällen mit echten Konsequenzen. Falls nicht, reicht eine gute Spur aus. Falls doch, kostet das Hinzufügen der Kette jetzt weitaus weniger als deren Nachrekonstruktion später.

Die Debatten über die Überwachung von Agenten dauern bereits seit Monaten an. Die Zählung klärt einen Teil der Frage, denn ein Feldname befindet sich entweder in der Klasse oder nicht.