# Verschachtelte MCP-Anfragen: Jede externe Aktion sicher verfolgen Ein Agent kann ein Tool aufrufen, das ein weiteres Tool aufruft. Dieses bittet vielleicht einen Helfer, eine Umgebung aufzulösen, und sendet schließlich eine HTTP-Anfrage oder führt einen SSH-Befehl aus. Wenn deine Aufzeichnungen beim Namen des ersten Tools enden, hast du eine Geschichte über die Absicht. Eine Darstellung dessen, was außerhalb des Prozesses passiert ist, hast du nicht. Verschachtelte MCP-Anfragen brauchen ein Tracing, das die Kausalkette bis zu jeder externen Aktion mit Zugangsdaten verfolgt. Dafür musst du mehr aufzeichnen als ein Agentenprotokoll und mehr als ein herkömmliches Request-Log. Du brauchst einen Graphen, der Fragen beantworten kann: Welcher Lauf hat diesen ausgehenden Aufruf ausgelöst, worauf wurde der Aufruf aufgelöst, wer hat ihn genehmigt und wurde er tatsächlich ausgeführt? Ich habe Teams erlebt, die einen sauberen Tool-Trace als Beweis dafür betrachteten, dass ihre Kontrollen funktionieren. Dann fragt ein Vorfall, welcher Aufruf eine Ressource in der Produktion verändert hat, und im Trace steht nur `release_service`. Verständliche Namen sind für Betreiber gedacht. Audit-Nachweise brauchen die konkrete Operation. ## Die externe Aktion ist der maßgebliche Datensatz Der letzte Aufruf in einer verschachtelten Kette trägt oft die Konsequenz. Deshalb braucht er einen eigenen dauerhaften Datensatz, selbst wenn jeder frühere Aufruf bereits einen Span besitzt. Ein Tool, das einen Branch-Namen prüft, kann harmlos sein. Ein späterer Helfer, der dieses Ergebnis nutzt, um einen Bereitstellungs-Endpunkt aufzurufen, ist nicht dasselbe Ereignis. Trenne drei Dinge, die Teams regelmäßig zu einem einzigen zusammenfassen: - Ein Tool-Aufruf ist eine Anfrage, eine benannte Fähigkeit mit bestimmten Argumenten auszuführen. - Ein Trace-Span beschreibt eine Arbeitseinheit und ihren Platz in einem Kausalgraphen. - Eine externe Aktion ist eine konkrete Operation, die eine Vertrauensgrenze überschreitet, etwa eine HTTP-Anfrage mit injizierten Zugangsdaten oder ein SSH-Befehl auf einem entfernten Host. Wer das falsch macht, erzeugt zwei gegensätzliche Probleme. Manche Teams legen für jeden internen Funktionsaufruf einen Audit-Datensatz an. Ihr Journal füllt sich mit Rauschen, und niemand kann die wenigen Aufrufe erkennen, die tatsächlich etwas verändert haben. Andere Teams protokollieren nur eine abschließende Erfolgsmeldung. Sie verlieren die Kette, die erklärt, welche Entscheidung des Agenten, welche Abfrage und welche Genehmigung den Aufruf ausgelöst haben. Gib einer externen Aktion eine stabile `action_id`. Verknüpfe sie mit dem Span, der sie gestartet hat, aber verwende die Span-ID nicht als Identität der Aktion. Ein Span kann lokale Vorbereitung, einen HTTP-Versuch, eine Weiterleitung und die Verarbeitung der Antwort umfassen. Diese Details sind nützlich. Der Aktionsdatensatz sollte lesbar bleiben, auch wenn jemand die Implementierung ändert. Ein Aktionsdatensatz muss das Ziel nach der Auflösung beschreiben. `environment=production` oder `target=customer-api` reicht nicht aus. Speichere den aufgelösten Host, Port und das Protokoll, die Request-Methode oder den SSH-Befehl sowie die Referenz auf die vom Executor ausgewählten Zugangsdaten. Speichere Referenzen auf Geheimnisse, niemals deren Werte. Diese Unterscheidung verändert auch die Bewertung des Erfolgs. Ein Wrapper-Tool kann `ok` zurückgeben, weil es Arbeit in eine Warteschlange gestellt hat. Eine tiefere Ebene kann anschließend scheitern, bevor sie eine Verbindung öffnet. Zeichne das Ergebnis für den Wrapper-Span und das Ergebnis der externen Aktion getrennt auf. Diese Fakten können voneinander abweichen, ohne dass einer der beiden Datensätze falsch ist. ## MCP liefert nicht deinen gesamten Aufrufgraphen MCP gibt Clients und Servern ein Protokoll zum Entdecken und Aufrufen von Tools. Es zwingt keine Implementierung dazu, einen internen Aufrufgraphen offenzulegen. Ein Host kann mehrere Server koordinieren. Ein Server kann lokale Helfer aufrufen. Ein Tool kann einen Job auslösen, der nach der Antwort weiterläuft. Dein Audit-Design muss diese Formen ausdrücklich berücksichtigen. Die Spezifikation des Model Context Protocol beschreibt `tools/call` als Anfrage des Clients an den Server für ein benanntes Tool und dessen Argumente. Das ist ein Schnittstellenvertrag, kein Tracing-Vertrag. Das Protokoll macht aus einem lokalen Funktionsaufruf kein beobachtbares untergeordnetes Ereignis und definiert kein universelles Parent-Feld, das jeder Vermittler bewahren muss. Das ist wichtig, wenn ein Team sagt, ein Tool habe «ein anderes MCP-Tool aufgerufen». Manchmal bedeutet das einen echten zweiten Protokollaufruf. Manchmal hat ein Server eine Bibliotheksfunktion mit einem ähnlichen Namen aufgerufen. Manchmal hat ein Agenten-Host ein Ergebnis erhalten, darüber nachgedacht und einen neuen Aufruf ausgeführt. Der entstehende Graph kann ähnlich aussehen, seine Vertrauensgrenzen unterscheiden sich jedoch. Behandle diese Kanten in deinen Aufzeichnungen als unterschiedliche Typen: - `protocol_call` verbindet eine MCP-Client-Anfrage mit einem Tool-Aufruf auf dem Server. - `local_call` verbindet Code innerhalb eines vertrauenswürdigen Prozesses. - `delegated_job` verbindet eine Anfrage mit Arbeit, die später von einem anderen Worker ausgeführt wird. - `external_action` verbindet einen Span mit einer HTTP- oder SSH-Operation. Leite den Kantentyp nicht aus dem Tool-Namen ab. Zeichne ihn dort auf, wo die Übergabe stattfindet. Dort weißt du, ob Identität, Zugangsdaten und Regeln für die Abbruchbehandlung in einen anderen Prozess gelangt sind. Ein verzögerter Job braucht besondere Aufmerksamkeit. Wenn ein Tool eine Aufgabe in die Warteschlange stellt und zurückkehrt, müssen Trace-ID und Root-Run-ID mit der Job-Nutzlast weitergegeben werden. Wenn ein Worker später läuft, erstelle für diese Ausführung einen neuen Span und verknüpfe ihn mit dem ursprünglichen Aktionsplan. Tu nicht so, als sei der Worker innerhalb der ursprünglichen Anfrage geblieben. Seine Ausführungszeit, Identität und sein Autorisierungsstatus können sich geändert haben. ## Erzeuge Kennungen an jeder Vertrauensgrenze Ein Trace hilft nur, wenn jeder Beteiligte seine Arbeit mit derselben Kausalkette verknüpfen kann, ohne eine gefälschte Historie als Tatsache zu akzeptieren. Erzeuge eigene Kennungen, wenn eine Anfrage in eine von dir kontrollierte Komponente gelangt. Bewahre den vorgelagerten Kontext als nicht vertrauenswürdige Diagnoseinformation auf, sofern ihn nicht ein authentifizierter Kommunikationspartner geliefert hat. Die W3C-Empfehlung zu Trace Context definiert den Header `traceparent` mit einer Version, einer 32-stelligen hexadezimalen Trace-ID, einer 16-stelligen hexadezimalen Parent-ID und Flags. OpenTelemetry verwendet dieses Format weitverbreitet. Nutze es, wenn HTTP oder ein anderer Transport Header übertragen kann, weil vorhandene Tracing-Tools es verstehen. Verwechsle Kompatibilität nicht mit einem Audit-Modell. Bei MCP über stdio gibt es möglicherweise überhaupt keinen HTTP-Header. Übertrage gleichwertigen Kontext in deiner Anwendungsnachricht oder verwalte ihn in dem Prozess, der den Aufruf verteilt. Der Mechanismus ist weniger wichtig als zwei Eigenschaften: Jede untergeordnete Operation muss ihren direkten Parent kennen, und die empfangende Komponente muss aufzeichnen, wer ihr den Kontext übergeben hat. Eine minimale Ereignisstruktur kann so aussehen: ```json { "event_id": "evt_01J8...", "time": "2025-03-08T14:32:11.214Z", "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736", "span_id": "00f067aa0ba902b7", "parent_span_id": "b7ad6b7169203331", "root_run_id": "run_8d43", "edge_type": "external_action", "actor": { "kind": "agent_process", "identity": "signed-process-identity" }, "action": { "action_id": "act_5f17", "channel": "http", "method": "POST", "host": "deploy.internal.example", "path_template": "/v1/releases/{name}", "credential_ref": "ops-deploy" }, "outcome": { "state": "sent", "http_status": 202 } } ``` Der obige Zeitstempel zeigt nur eine Beispielstruktur, kein empfohlenes Aufbewahrungsformat. Verwende in einem echten System ein Zeitformat, das dein Log-Prüfer zuverlässig und einheitlich verarbeiten kann. Halte vollständige Endpunkte und Argumente aus weit verteilten Telemetrieexporten heraus, wenn sie Mandantennamen, Repository-Pfade oder personenbezogene Daten enthalten. Ein Template plus ein separat geschützter forensischer Datensatz liefert Betreibern oft genügend Kontext, ohne sensible Inhalte in jedes Dashboard zu kopieren. Ein empfangender Dienst sollte `parent_span_id` nicht einfach vertrauen, nur weil ein Agent sie geliefert hat. Erzeuge einen neuen lokalen Span, speichere den empfangenen Wert und füge ein Feld wie `upstream_context_source=authenticated_mcp_client` oder `upstream_context_source=unverified_input` hinzu. Diese kleine Unterscheidung verhindert, dass ein böswilliger Aufrufer seine Aktion nachträglich mit einem harmlosen Lauf verknüpft. ## Protokolliere die Auflösung, nicht nur die Tool-Argumente Die vom Agenten angeforderte Aktion und die vom Executor ausgeführte Aktion können sich nach Templates, Standardwerten, Aliasen, Weiterleitungen, Umgebungsabfragen und der Auswahl von Zugangsdaten unterscheiden. Deine Aufzeichnungen müssen beide Seiten bewahren, denn genau in dieser Differenz versteckt sich oft ein unsicheres Design. Betrachte einen Agentenaufruf mit diesen Argumenten: ```json { "tool": "publish_release", "arguments": { "environment": "prod", "release": "2025.03.08-rc2" } } ``` Ein Tool kann `prod` in eine Basis-URL übersetzen, eine Zugangsdatenreferenz auswählen, die Release-Zeichenfolge in einen Request-Pfad umwandeln und Header ergänzen. Der ursprüngliche Aufruf beweist das Ziel nicht. Eine vollständige Kette sollte eine Abfolge wie diese sichtbar machen: 1. Der Agent ruft `publish_release` im Lauf `run_8d43` auf. 2. Das Tool löst `prod` zu einem bestimmten erlaubten Endpunkt auf und wählt die Zugangsdatenreferenz `ops-deploy`. 3. Der Executor zeichnet `act_5f17` unmittelbar vor dem Senden der Anfrage auf. 4. Der Executor zeichnet die Antwort oder den Transportfehler gegen diese Aktion auf. 5. Der Wrapper gibt ein Ergebnis zurück, das auf `act_5f17` verweist, ohne Zugangsdaten offenzulegen. Diese Abfolge gibt einem Ermittler einen Weg von der Anfrage des Agenten zu einer Netzwerkoperation. Sie liefert auch einer genehmigenden Person etwas Konkretes zur Prüfung, bevor der Executor etwas sendet. Protokolliere keine vollständigen Autorisierungs-Header, Cookies, privaten Befehle oder beliebigen Request-Bodies als Ersatz für ein gutes Datenmodell. Unter Zeitdruck tun Menschen das, weil ein Rohdaten-Dump das heutige Debugging-Problem löst. Er erzeugt das Leck von Zugangsdaten für morgen. Erfasse stattdessen eine Referenz auf die Zugangsdaten, einen Header-Namen, einen Body-Digest, ausgewählte nicht geheime Felder und einen ausdrücklichen Redaktionsstatus. Für SSH gilt dieselbe Disziplin. Ein Datensatz mit `ssh deploy` ist zu vage, wenn der Helfer später einen Host-Alias auflöst, eine Identität auswählt und einen Remote-Befehl erstellt. Protokolliere den aufgelösten Host und Port, den Kontonamen, die Identitätsreferenz, ein Befehls-Template oder einen Befehls-Digest sowie den Exit-Status. Wenn der Befehl sensible Daten enthält, bewahre nur dann eine geschützte forensische Kopie auf, wenn es dafür einen klaren Grund und eine definierte Aufbewahrungsregel gibt. ## Eine Wiederholung ist ein weiterer Versuch, keine Fußnote Wiederholungen und Verzweigungen verwandeln einen einfachen Baum in einen Graphen. Wenn du sie in einen einzigen Span mit einem abschließenden Feld `success` zwingst, löschst du die Informationen, die doppelte Seiteneffekte und teilweise Fehler erklären. Verwende drei IDs, wenn eine Operation wiederholt werden kann: eine Trace-ID für den gesamten Lauf, eine Aktions-ID für die beabsichtigte logische Operation und eine Versuchs-ID für jedes tatsächliche Senden. Jeder Versuch erhält einen eigenen Span. Der Aktionsdatensatz verweist anschließend auf alle Versuche. Angenommen, ein Tool sendet eine Release-Anfrage, läuft ab, nachdem der entfernte Dienst sie akzeptiert hat, und versucht es erneut. Die zweite Anfrage kann dieselbe Release zweimal erzeugen, wenn der entfernte Endpunkt keine Idempotenz unterstützt. Ein abschließendes `200` sagt dir nur wenig. Dein Log sollte zeigen, dass Versuch eins das Netzwerk erreicht hat, lokal mit einem Timeout endete und Versuch zwei eine Antwort erhielt. Verwende ein Idempotenz-Token, wann immer das Ziel dies unterstützt. Leite es aus der logischen Aktions-ID ab, nicht aus einer vorübergehenden Span-ID. So kann der entfernte Dienst ein Duplikat erkennen, selbst wenn dein Executor neu startet oder deine Tracing-Bibliothek neue Spans erzeugt. ```text trace_id=4bf92f... action_id=act_5f17 attempt=1 state=timeout bytes_sent=418 trace_id=4bf92f... action_id=act_5f17 attempt=2 state=completed http_status=200 ``` `bytes_sent` hilft dabei, einen Verbindungsfehler vor der Übertragung der Anfrage von einem Timeout zu unterscheiden, nachdem der Client Daten geschrieben hat. Es beweist jedoch nicht, was der entfernte Dienst übernommen hat. Halte diese Unsicherheit im Datensatz fest. Bezeichne den ersten Versuch nicht als `failed`, wenn das so wirken lässt, als habe die entfernte Seite nichts getan. Parallele Arbeit braucht Geschwister-Spans, kein gemeinsames veränderliches Trace-Feld, das Worker überschreiben. Wenn ein Planungstool vier Umgebungsprüfungen aufruft, erstelle vier untergeordnete Spans und vier getrennte Ergebnisse. Wenn zwei Zweige zu externen Aktionen führen, vergib zwei Aktions-IDs. Ein Betreiber muss einen Zweig widerrufen oder untersuchen können, ohne ihn mit seinem Geschwisterzweig zu verwechseln. ## Die Genehmigung muss an die aufgelöste Operation gebunden sein Eine menschliche Genehmigung ist nur dann nützlich, wenn die prüfende Person die Operation sehen kann, die nach der Auflösung stattfinden wird. Ein allgemeines Label wie `deploy` zu genehmigen, lässt kaum eine sinnvolle Bewertung zu, besonders wenn verschachtelte Tools den tatsächlichen Host und die Zugangsdaten erst später auswählen. Erstelle die Eingaben für die Genehmigung aus dem Datensatz der ausstehenden externen Aktion: Kanal, aufgelöstes Ziel, Form der Operation, Zugangsdatenreferenz, Prozessidentität und eine kurze Beschreibung der Auswirkungen. Bewahre Trace- und Aktions-IDs in der Genehmigungsentscheidung auf. Wenn der Executor die Anfrage sendet, muss er nachweisen, dass er genau die genehmigte Aktion verwendet hat, nicht lediglich eine Genehmigung aus demselben Agentenlauf. Genehmige nicht die gesamte Kette, nur weil ihr erstes Tool harmlos aussah. Eine Kette kann mit `find_release` beginnen und mit einem SSH-Befehl enden, der einen Host verändert. Wenn das Design erlaubt, dass eine spätere Auflösung den Handlungsspielraum der Kette erweitert, fordere an der ausgehenden Grenze eine neue Entscheidung. Das bedeutet nicht, dass ein Mensch jede Zeichenkettenverkettung innerhalb eines Tools bestätigen muss. Die Entscheidung gehört dorthin, wo eine Fähigkeit den vertrauenswürdigen Ausführungspfad verlässt. Diese Grenze gibt Menschen eine verständliche Eingabe und deinem Log eine dauerhafte Verbindung zwischen Zustimmung und Wirkung. Sallyport verfolgt diesen Ansatz für seine unterstützten HTTP- und SSH-Kanäle: Zugangsdaten bleiben im Tresor, Sallyport führt die Aktion selbst aus und kann für jede Verwendung einer ausgewählten Zugangsdatenreferenz eine Genehmigung verlangen. Der nützliche Integrationspunkt ist die daraus entstehende externe Aktion, nicht die Behauptung eines Agenten darüber, was sein verschachtelter Helfer beabsichtigt hat. Auch Genehmigungsdatensätze brauchen Ablauf- und Bindungsregeln. Binde eine Entscheidung an die Aktions-ID, das aufgelöste Ziel, die Zugangsdatenreferenz und den Argument-Digest. Wenn sich zwischen Eingabeaufforderung und Ausführung einer dieser Werte ändert, verwerfe die Entscheidung und frage erneut. Ein wiederverwendbares Genehmigungstoken, das dem Agentenprozess in unabhängige Aufrufe folgt, wird irgendwann etwas autorisieren, das niemand gelesen hat. ## Ein Audit-Journal braucht Reihenfolge und Überprüfbarkeit Herkömmliche Anwendungslogs helfen bei der Diagnose eines Fehlers. Gewöhnliche Logs zeigen jedoch selten, ob jemand die unbequeme Zeile entfernt hat. Bewahre bei Aktionen autonomer Agenten die Ereignisreihenfolge und mache spätere Änderungen erkennbar. Eine einfache Hashkette speichert die kanonisch serialisierten Bytes jedes Ereignisses, den Hash des vorherigen Ereignisses und den neuen Ereignishash. Ein Prüfer beginnt beim ersten erhaltenen Datensatz und berechnet jede Verbindung neu. Wenn ein Angreifer einen Datensatz in der Mitte ändert, einfügt oder entfernt, schlägt die Prüfung an der betroffenen Stelle fehl. Die kanonische Serialisierung ist wichtig. Wenn ein Prozess JSON-Felder sortiert und ein anderer nicht, ergeben identische Datensätze unterschiedliche Hashes. Definiere Feldreihenfolge, Unicode-Normalisierung, Zeitstempelgenauigkeit, den Umgang mit fehlenden Feldern und die Byte-Kodierung. Teste diese Regeln in jeder Sprache, die Ereignisse schreibt. Die meisten beschädigten Audit-Ketten scheitern hier, nicht an der Hashfunktion. Ein Prüfer sollte Ergebnisse liefern, mit denen ein Betreiber arbeiten kann: ```text $ audit verify journal.events records_checked: 1842 first_sequence: 91001 last_sequence: 92842 chain: valid signature: valid ``` Wenn er eine Beschädigung findet, sollte er die erste fehlerhafte Sequenz sowie den erwarteten und den beobachteten Hash des Vorgängers nennen. Er sollte nicht versuchen, die Datei stillschweigend zu reparieren. Eine Reparatur zerstört Belege darüber, was schiefgelaufen ist. Hashketten lösen nicht jede Bedrohung. Wer Signaturmaterial und Speicher kontrolliert, kann eine vollständig alternative Geschichte schreiben. Regelmäßig signierte Checkpoints, die außerhalb der normalen Kontrolle des Schreibers gespeichert werden, verringern dieses Risiko. Das gilt auch für getrennte Zugriffswege zum Schreiben und Lesen. Beschreibe den vorhandenen Schutz präzise, statt jedes Log als unveränderlich zu bezeichnen. Halte das Aktionsereignis nahe am Ausführungspunkt. Ein Hintergrundsammler, der Batches erst später erhält, kann den einzigen Datensatz verlieren, der beweist, dass ein ausgehender Aufruf stattgefunden hat. Der Executor sollte vor der Übertragung einen Datensatz mit dem Status «planned» anhängen und unmittelbar nach Erhalt eines Ergebnisses einen Abschlussdatensatz schreiben. Wenn er dazwischen abstürzt, zeigt das unvollständige Paar, dass die Aktion möglicherweise nach außen gelangt ist. ## Teste den Trace gegen Fehler, die tatsächlich auftreten Ein Trace-Design ist erst glaubwürdig, wenn es fehlerhaften Kontext, verlorene Worker, doppelte Übertragungen und den Widerruf durch Betreiber übersteht. Demos mit dem idealen Ablauf verbergen genau die Grenzen, die wichtig werden, wenn sich ein Agent unerwartet verhält. Führe eine kleine Testsuite gegen einen nicht produktiven Endpunkt oder Host aus. Jeder Test sollte den Audit-Graphen prüfen, nicht nur die Antwort des Tools: - Sende einen verschachtelten Aufruf mit einer gefälschten Parent-ID und bestätige, dass der Empfänger diesen Kontext als nicht verifiziert kennzeichnet. - Erzwinge ein Timeout, nachdem Request-Bytes den Client verlassen haben. Wiederhole den Aufruf und bestätige, dass beide Versuche dieselbe Aktions-ID teilen. - Stelle Arbeit in die Warteschlange, starte den Worker neu und bestätige, dass der fortgesetzte Span mit dem ursprünglichen Lauf verknüpft ist, ohne vorzutäuschen, er sei ununterbrochen weitergelaufen. - Widerrufe die Autorisierung nach der Planung, aber vor der Ausführung, und bestätige, dass kein Datensatz einer externen Aktion den Status `sent` erreicht. - Führe zwei Geschwisteraufrufe parallel aus und bestätige, dass keiner der beiden Zweige den Parent-Span oder das Ergebnis des anderen übernimmt. Der dritte Test deckt eine häufige Lüge in Logs auf. Systeme melden oft eine einzige ununterbrochene Anfrage, obwohl ein Worker Stunden später unter einer anderen Prozessidentität neu gestartet wurde. Das verschleiert, wer die Aktion tatsächlich ausgeführt hat. Zeichne die Identität und die Startzeit des Workers als Fakten des neuen Spans auf. Der vierte Test deckt einen weiteren bekannten Fehler auf. Ein Tool holt die Autorisierung ein, bevor es sein endgültiges Ziel auflöst, und verwendet diese veraltete Entscheidung für den aufgelösten Aufruf. Dein Test sollte das Ziel oder die Zugangsdatenreferenz nach der Genehmigung ändern und erwarten, dass der Executor die Aktion ablehnt. Gib dich nicht mit Screenshots eines Trace-Viewers zufrieden. Exportiere die Rohdatensätze, prüfe ihre Kette und formuliere Assertions für Parent-IDs, Aktions-IDs, Ziele, Autorisierungsbindungen und Ergebnisse. Der Viewer ist eine Hilfe. Der Ereignisstrom ist der Nachweis. ## Baue zuerst die Grenze, dann den Graphen Beginne beim Code, der HTTP- und SSH-Operationen ausführt. Lass ihn expliziten Trace-Kontext akzeptieren, vor dem Senden einen Aktionsdatensatz erzeugen, danach einen Ergebnisdatensatz erstellen und die Ausführung verweigern, wenn die Autorisierung nicht an die aufgelöste Operation gebunden ist. Wenn diese Grenze korrekt arbeitet, instrumentiere die verschachtelten Tool-Aufrufe darüber. Du weißt dann, welche Informationen jeder Parent weitergeben muss, weil der Executor sie einfordern wird. In der umgekehrten Richtung entstehen oft schöne Bäume ohne vertrauenswürdige Blattknoten. Halte Tool-Namen, Planungsnotizen und die Überlegungen des Modells getrennt vom Journal externer Aktionen. Sie können helfen zu verstehen, warum ein Lauf stattgefunden hat. Sie ersetzen jedoch keinen Datensatz darüber, welches entfernte System eine Anfrage erhalten hat, unter welcher Zugangsdatenreferenz, nach welcher Genehmigung und mit welchem Ergebnis. Genau diese Kette brauchst du, wenn die Antwort des Agenten plausibel klingt, das entfernte System aber etwas anderes sagt.