# So funktioniert die Prüfung von KI-Agent-Aktionen, ohne Prompts zu speichern Prüfaufzeichnungen für autonome Agenten sollten eine externe Aktion erklären, ohne zu einer zweiten, schlecht geschützten Kopie des gesamten Arbeitsgedächtnisses des Agenten zu werden. Dazu gehört festzuhalten, wer den Agenten gestartet hat, welche Berechtigung den Lauf erlaubt hat, welche Grenze die Aktion überschritten hat und was anschließend geschah. Es bedeutet nicht, jeden Prompt, jede Tool-Nachricht, jeden Notizblock und jedes API-Paket für immer aufzubewahren. Teams beginnen oft mit Gesprächstranskripten, weil sie leicht zu erfassen sind und vollständig wirken. Dann kommt ein Vorfall, und das Transkript enthält Kundendaten, Quellcode, eingefügte Token, spekulative Anweisungen und seitenweise Material, das mit der geprüften Aktion nichts zu tun hat. Gleichzeitig kann der Prüfer die grundlegende Frage weiterhin nicht beantworten: Welche ausführbare Datei hat unter welcher Autorisierung mit welchem Berechtigungsumfang eine Anfrage an welchen Dienst gesendet und mit welchem Ergebnis? Eine Prüfaufzeichnung sollte der Aktion folgen, nicht dem Gespräch. Das verringert die Angriffsfläche und erzeugt Belege, die ein Betreiber tatsächlich verwenden kann. ## Eine Aktionsaufzeichnung beantwortet eine andere Frage als ein Transkript Eine Aktionsaufzeichnung beantwortet, ob ein bestimmter Prozess eine Grenze überschritten hat und was das externe System daraufhin getan hat. Ein Transkript beantwortet, welcher Text durch den Kontext eines Agenten gelaufen ist. Das sind unterschiedliche Artefakte mit unterschiedlichen Zugriffsanforderungen, Aufbewahrungsfristen und Fehlerbildern. Angenommen, ein Agent liest einen langen Vorgang, untersucht ein Repository, erstellt einen Veröffentlichungshinweis und ruft eine API auf, um ein Deployment anzulegen. Ein Gesprächsexport kann Tausende Zeilen enthalten. Die aussagekräftige Prüfaufzeichnung kann deutlich kleiner sein: - Prozessidentität und Sitzungskennung. - Autorisierungsentscheidung, die die Aktion abgedeckt hat. - Ziel, Methode, Ressourcen-Kategorie und Referenz auf Zugangsdaten. - Ergebnis einschließlich Status und sicherer Zusammenfassung. - Zeitstempel und Integritätsdaten. Damit kann ein Entwickler das operative Ereignis rekonstruieren: Ein signierter Prozess wurde zu einem bestimmten Zeitpunkt gestartet, erhielt eine Freigabe für eine Sitzung, sendete `POST` an einen benannten API-Host und einen Deployment-Endpunkt, verwendete die Deployment-Zugangsdaten und erhielt einen Erfolgsstatus mit einer Deployment-Kennung. Falls der Vorgang es rechtfertigt, kann der Prüfer beim Betreiber des Zielsystems zusätzliche Belege anfordern. Das Transkript kann erklären, *warum* der Agent glaubte, ein Deployment ausführen zu sollen. Es beweist nur selten, dass es tatsächlich ausgeführt wurde. Text im Agent-Kontext kann hypothetisch, veraltet oder vom Modell erfunden sein oder nie verwendet worden sein. Die externe Aktion hat eine engere und besser vertretbare Beweiskette. Bewahre Gesprächsmaterial nur dann in der Entwicklungsumgebung auf, wenn es dafür einen klaren Grund gibt, etwa zur Qualitätsbewertung oder für einen konkreten Vorfall. Schiebe es nicht unter dem Etikett der Verantwortlichkeit in ein Auditsystem. ## Vollständige Prompts schaffen einen Datenspeicher, den niemand schützen wollte Die vollständige Prompt-Erfassung verwandelt ein Aktionsprotokoll in ein Hochrisikoarchiv für Inhalte. Das Risiko ist weder theoretisch noch auf offensichtliche Geheimnisse beschränkt. Prompts enthalten oft Teile von Quellcode, Kunden-Tickets, Datenbankausgaben, interne URLs, Designentscheidungen, Shell-Historien und kopierte Fehlermeldungen. Ein Modell kann früheren Kontext in ein Tool-Argument oder eine Fehlererklärung übernehmen. Eine API kann einen gesendeten Header oder Anfrageinhalt in einer Fehlerantwort zurückgeben. Wenn der Logger alle Zeichenfolgen als harmlose Diagnose behandelt, wird er irgendwann Informationen speichern, die das Team nie erfassen wollte. Die übliche Antwort lautet: „Wir werden Geheimnisse schwärzen.“ Das funktioniert nur, wenn der Protokollpfad jedes Geheimnisformat vor der Speicherung erkennt und jedes Protokoll versteht. Kurzlebige signierte URLs, Sitzungscookies, proprietäre Tokenformate, in JSON-Zeichenfolgen eingebettete Geheimnisse und Zugangsdaten, die ein Dienst in einem Fehler zurückgibt, werden übersehen. Eine Schwärzung kann die Privatsphäre außerdem nicht wiederherstellen, wenn bereits eine große Gruppe das Original gelesen hat. OWASP unterscheidet in seinem Logging Cheat Sheet sinnvoll: Protokolle sollen Überwachung und Untersuchungen unterstützen, aber Zugriffstoken, Passwörter, Verbindungszeichenfolgen, Verschlüsselungsschlüssel und Daten, deren Erfassung unnötige Datenschutzrisiken schafft, sollten nicht protokolliert werden. Übertrage diesen Rat mit mehr, nicht mit weniger Disziplin auf Agent-Prüfungen. Der Agent-Kontext ist ungewöhnlich breit und enthält deshalb mehr zufälliges Material als ein herkömmliches Anfrageprotokoll. Wende Datenminimierung bereits bei der Erfassung an. Speichere einen Anfrage-Fingerabdruck oder freigegebene Metadaten, nicht den Roh-Prompt, der die Anfrage erzeugt hat. Wenn eine Untersuchung später Kontext benötigt, rufe ihn unter den für das Ursprungssystem passenden Kontrollen dort ab. Mache ein Audit-Journal nicht zum einfachsten Ort, um jede sensible Unterhaltung zu durchsuchen. Eine enge Ausnahme ist möglich: Für die Diagnose einer fehlerhaften Integration kann ein Team vorübergehend und stark begrenzt Inhalte erfassen müssen. Mache daraus einen ausdrücklich aktivierten Diagnosemodus mit festgelegtem Verantwortlichen, Ablaufzeit, Zugriffsbeschränkung und Löschdatum. Wenn die Diagnoseerfassung dauerhaft wird, weil niemand sie abschaltet, war es keine Diagnoseerfassung. ## Die Prozessidentität muss einen freundlichen Prozessnamen überleben Ein Prozessname identifiziert keinen Agenten. `agent`, `node`, `python` und `shell` sagen einem Prüfer fast nichts, und ein bösartiges oder unachtsames Programm kann jeden dieser Namen verwenden. Erfasse genügend Identitätsdaten, um das Programm zu unterscheiden, das die Sitzung gestartet hat: - Pfad der ausführbaren Datei und eine stabile Code-Identität, etwa eine Signaturinstanz, sofern das Betriebssystem eine solche bereitstellt. - Prozess-ID, ID des übergeordneten Prozesses, Startzeit und Sitzungskennung. - Benutzerkonto und lokale Hostkennung. - Version oder Build-Kennung des Agent-Clients, sofern der Client sie bereitstellt. - Transportweg zum Aktions-Gateway, etwa eine lokale stdio-MCP-Verbindung. Der übergeordnete Prozess ist relevant. Ein signierter Editor, der einen freigegebenen Coding-Agenten startet, erzählt eine andere Prüfgeschichte als ein unbekannter Shell-Prozess, der eine kopierte Binärdatei mit demselben Befehlsnamen startet. Die Identität des übergeordneten Prozesses beweist keine gute Absicht, liefert Ermittlern aber einen Ausgangspunkt und macht einfache Täuschungen leichter erkennbar. Verwechsle Prozessidentität nicht mit menschlicher Identität. Ein Entwickler kann einen Agenten starten, doch die Aktionsaufzeichnung sollte beide Tatsachen getrennt nennen: welches lokale Konto den Prozess gestartet hat und welche ausführbare Datei die Sitzung hielt. Gemeinsame Arbeitsstationen, Remote-Shells, Dienstkonten und Übergaben zwischen Tools machen diese Trennung notwendig. Die Signaturinstanz verdient besondere Beachtung, sofern sie verfügbar ist, weil ein Betriebssystem sie beim Start prüfen kann. Sie ist trotzdem kein moralisches Urteil über den Herausgeber. Eine vertrauenswürdige Signaturinstanz kann ein fehlerhaftes Update ausliefern, und ein nicht signiertes internes Tool kann legitim sein. Die Aufzeichnung braucht diese Tatsache, damit ein Prüfer sie mit der Autorisierungsentscheidung und dem erwarteten Bereitstellungspfad vergleichen kann. ## Autorisierung braucht Umfang, Zeit und eine freigebende Person Eine Freigabe ohne Gültigkeitsbereich ist eine vage Erinnerung, kein Prüfbeleg. Die Aufzeichnung muss nennen, was freigegeben wurde, wann die Freigabe begann und wann sie nicht mehr galt. Eine Sitzungsautorisierung ist oft die passende Standardeinstellung für einen von einem Entwickler gesteuerten Agent-Lauf. Eine Person genehmigt einen bekannten Agent-Prozess einmal, danach kann der Prozess Aktionen ausführen, bis er beendet wird. Das Prüfjournal sollte diese Entscheidung an die Prozesssitzung binden, statt so zu tun, als hätte jeder spätere Aufruf eine eigene menschliche Entscheidung erhalten. Für Zugangsdaten mit höherem Risiko sollte eine separate Entscheidung pro Aufruf erfasst werden. Eine solche Aufzeichnung braucht die Identität der freigebenden Person, Zeitpunkt, Referenz auf die Zugangsdaten, Aktionskategorie, Ziel und die genaue Kennung des freigegebenen Aufrufs. Eine allgemeine Notiz wie „Benutzer hat genehmigt“ lässt nach einer problematischen Aktion zu viel Raum für Streit. Ein praktikables Autorisierungsobjekt sieht so aus: ```json { "authorization_id": "auth_7f3c", "kind": "session", "decision": "approved", "approved_at": "2025-03-08T14:22:31Z", "approver": "local-account:maya", "process_session": "sess_31a9", "process_identity": { "executable": "/Applications/Agent.app/Contents/agent", "signing_authority": "Example Development Team" }, "scope": { "credential_refs": ["deploy-production"], "expires_when": "process exits" } } ``` Die Namen und Kennungen sind Beispiele, die Struktur ist aber wichtig. Die freigebende Identität ist ein lokales Konto, nicht die Behauptung, eine bestimmte Person habe jede Ausgabezeile beobachtet. Die Referenz auf Zugangsdaten ist ein Label oder eine interne ID, niemals die Zugangsdaten selbst. Der Gültigkeitsbereich sagt, ob die Entscheidung für eine Sitzung oder einen einzelnen Aufruf galt. Löse dieses Problem nicht mit einer ausufernden Richtliniensprache, sofern deine Umgebung sie nicht wirklich benötigt. Teams erstellen oft Regeln, die während eines Vorfalls niemand lesen kann, und nennen allein das Vorhandensein von Regeln eine Kontrolle. Wenige klar erkennbare Autorisierungsentscheidungen können leichter zu prüfen und schwieriger falsch zu konfigurieren sein. ## Anfrage-Metadaten sollten die überschrittene Grenze beschreiben Ein Prüfer braucht genügend Anfrage-Metadaten, um den Umfang der Operation zu verstehen, aber keine Rohkopie der Operation. Erfasse bei HTTP den Service-Host, falls relevant den Port, die Methode, eine normalisierte Routenvorlage, die Referenz auf Zugangsdaten, die Anfragegröße, eine Korrelations-ID und den Digest einer kanonischen sicheren Darstellung. Eine normalisierte Routenvorlage bedeutet, `/v1/projects/{project_id}/deployments` zu speichern, statt eine konkrete URL mit einer Kundenkennung oder einem undurchsichtigen, geheimnisähnlichen Wert. Die konkrete Route kann beim Zielsystem verbleiben, das diese Daten bereits besitzt und über eigene Zugriffskontrollen verfügt. Bei SSH gehören dazu Zielhost, verifizierte Host-Identität, Remote-Konto, angeforderter Befehl oder eine Befehlsklassifizierung, die Referenz auf Zugangsdaten und das Ergebnis. Vermeide uneingeschränkte Befehlsausgaben. Ein Befehl kann Umgebungsvariablen, Inhalte privater Repositories oder Zugangsdaten aus einem falsch konfigurierten Skript ausgeben. HTTP Semantics, RFC 9110, unterscheidet die Semantik von Anfragemethoden wie sicher, idempotent und unsicher. Nutze diese Unterscheidung als Signal für die Prüfung, nicht als Abkürzung für die Autorisierung. Ein `GET` kann sensible Daten offenlegen. Ein `PUT` kann idempotent sein und trotzdem eine Produktionskonfiguration ersetzen. Ein `POST` kann eine nicht rückgängig zu machende externe Wirkung erzeugen. Die Methode hilft beim Einordnen, aber Ziel und Route bestimmen das tatsächliche Risiko. Verwende ein Schema für erlaubte Metadaten. Beginne nicht mit dem vollständigen Anfrageobjekt, um später Felder zu entfernen. Der sichere Weg besteht darin, die Felder zu definieren, die eine Aktionsaufzeichnung enthalten darf, und alles andere abzulehnen oder umzuwandeln. ```json { "call_id": "call_c24e", "session_id": "sess_31a9", "channel": "https", "destination": "api.example.internal", "method": "POST", "route_template": "/v1/projects/{project_id}/deployments", "credential_ref": "deploy-production", "request_bytes": 842, "request_digest": "sha256:6d1d...", "started_at": "2025-03-08T14:24:09Z" } ``` Ein Digest erkennt eine veränderte kanonische Aufzeichnung, wenn der Prüfer die ursprünglich freigegebene Darstellung besitzt. Er macht den ursprünglichen Inhalt nicht sicher zur Veröffentlichung. Behandle auch Hashes von Geheimnissen mit geringer Entropie vorsichtig, da ein Angreifer sie erraten und vergleichen kann. Hashte kein kurzes Token und nenne es Schwärzung. ## Ergebnisse brauchen operative Belege, keine Antwort-Dumps Eine Ergebnisaufzeichnung sollte festhalten, was das Zielsystem gemeldet hat und ob das Gateway die angeforderte Operation abgeschlossen hat. Sie sollte nicht standardmäßig den vollständigen Antworttext speichern. Bei einer HTTP-Aktion sollten Transportabschluss, HTTP-Status, Antwortgröße, verstrichene Zeit, eine sichere Service-Anfrage-ID und ein bewusst ausgewähltes Ergebnisfeld erfasst werden. Eine Deployment-API kann zum Beispiel eine unkritische Deployment-ID zurückgeben, während ihre vollständige JSON-Antwort Umgebungsvariablen und eine Commit-Nachricht aus einem privaten Repository enthält. Bei einer SSH-Aktion sollten Exit-Code, Dauer, Ergebnis der Host-Identitätsprüfung und eine vom Befehlsadapter ausgewählte Zusammenfassung erhalten bleiben. Wenn ein Befehl einen Erfolgsnachweis benötigt, sollte er ein begrenztes maschinenlesbares Ergebnis wie `{\"release\":\"r42\",\"status\":\"published\"}` ausgeben. Akzeptiere kein beliebiges Terminal-Transkript als Auditergebnis. Diese Unterscheidung ist bei Fehlern wichtig. Angenommen, ein Deployment-Aufruf liefert HTTP 403 und enthält ein Diagnoseobjekt, das den Autorisierungs-Header des Aufrufers wiederholt. Der Agent sieht den Fehler, versucht es zweimal erneut und jeder Versuch erzeugt einen eigenen Protokolleintrag. Ein unachtsames Prüfsystem enthält nun drei Kopien der offengelegten Zugangsdaten, alle unter einem Vorfall, den noch mehr Menschen öffnen werden. Baue den Fehlerpfad vor dem Erfolgspfad. Das Aktions-Gateway sollte einen Fehler klassifizieren, unsichere Felder entfernen und eine begrenzte Zusammenfassung speichern. Sinnvolle Kategorien sind Netzwerkfehler, Autorisierung verweigert, Ziel hat die Anfrage abgelehnt, Zeitüberschreitung beim Ziel und lokaler Ausführungsfehler. Kombiniere die Kategorie mit sicheren Fakten wie Status- oder Exit-Code, nicht mit einem freien Textblock eines entfernten Dienstes. Wiederholungen brauchen eigene Felder. Erfasse `attempt`, `max_attempts` und eine kausale Verknüpfung mit dem ursprünglichen Aufruf. Sonst sieht ein Prüfer drei destruktive Anfragen und kann nicht erkennen, ob der Agent sie absichtlich wiederholt hat oder ein Transport-Retry Duplikate erzeugte. Bei unsicheren Operationen kann eine Wiederholung eine neue Autorisierung oder einen Idempotenzmechanismus beim Ziel erfordern. Protokollierung kann eine doppelt angewendete Aktion nicht reparieren. ## Ein Prüfungsschema sollte verbotene Felder unübersehbar machen Eine Schem Prüfung entdeckt Protokollierungsfehler, bevor sich Produktionsaufzeichnungen ansammeln. Behandle das Schema als Sicherheitsgrenze mit ausdrücklich erlaubten Feldern und einer ausdrücklichen Ablehnung freier Prompt- und Payload-Felder. Das folgende Beispiel verbindet Identität, Autorisierung, Aktionsmetadaten, Ergebnis und Integritätsinformationen. Die Felder `prompt`, `messages`, `headers`, `request_body`, `response_body` und `stderr` fehlen absichtlich. ```json { "event_type": "external_action", "event_id": "evt_91bd", "occurred_at": "2025-03-08T14:24:10Z", "actor": { "local_account": "maya", "process_session": "sess_31a9", "pid": 4812, "parent_pid": 4601, "executable_digest": "sha256:2a84...", "signing_authority": "Example Development Team" }, "authorization": { "authorization_id": "auth_7f3c", "mode": "session", "decision": "approved" }, "action": { "channel": "https", "destination": "api.example.internal", "operation": "POST /v1/projects/{project_id}/deployments", "credential_ref": "deploy-production", "request_digest": "sha256:6d1d..." }, "result": { "category": "completed", "status_code": 201, "destination_request_id": "req_18c7", "duration_ms": 614 }, "integrity": { "previous_event_digest": "sha256:8f50...", "event_digest": "sha256:bd7e..." } } ``` Füge neben Feldern, die einmal geheime Inhalte enthalten könnten, keine Kommentare wie „geschwärzt“ ein. Lass das Feld weg. Ein vorhandenes, aber leeres `request_body` lädt einen späteren Entwickler dazu ein, es beim Debugging zu füllen. Die Schemavalidierung sollte unbekannte Felder auf oberster Ebene ablehnen und verschachtelte Datenblöcke zurückweisen, sofern nicht ein geprüfter Adapter ihr Format kontrolliert. Prüfer brauchen außerdem eine lesbare Darstellung des Ereignisses. Erzeuge sie aus der kanonischen Aufzeichnung, statt eine separate, handgeschriebene Erzählung zu pflegen. Ein Eintrag für Menschen könnte lauten: „Die freigegebene Prozesssitzung verwendete deploy-production, um bei api.example.internal ein Deployment anzulegen. Der Dienst antwortete in 614 ms mit 201.“ Das Journal behält die für die Untersuchung erforderlichen Kennungen, ohne in der Standardansicht Material offenzulegen. ## Integrität beweist Veränderung, nicht Vollständigkeit Manipulationssichere Aufzeichnungen helfen nur, wenn das Team ihre Grenzen kennt. Eine Hash-Kette kann zeigen, dass jemand ein Ereignis nach seiner Aufnahme in die Kette geändert, gelöscht oder verschoben hat, sofern die Prüfer die erforderlichen Kettendaten zur Verifikation aufbewahren. Sie kann nicht beweisen, dass ein kompromittierter Logger die Aktion überhaupt aufgezeichnet hat. NIST SP 800-92, Guide to Computer Security Log Management, empfiehlt, die Integrität von Protokollen zu schützen, festzulegen, welche Ereignisse protokolliert werden müssen, und Protokolle mit klarer operativer Verantwortung zu prüfen. Nützlich ist die Kombination. Integrität ohne definierte Ereignisgrenze liefert vertrauenswürdige Aufzeichnungen einer unvollständigen Geschichte. Eine lange Ereignisliste ohne Integrität erzählt eine Geschichte, die jemand unbemerkt bearbeiten kann. Verwende das Aktions-Gateway als Beobachtungspunkt, weil es die Nutzung der Zugangsdaten und den externen Aufruf sieht. Wenn ein Agent das Gateway umgehen und mit kopierten Zugangsdaten direkte Aufrufe ausführen kann, deckt die Prüfspur nur den kooperativen Weg ab. Löse das Problem der Verteilung von Zugangsdaten, statt zu behaupten, das Journal sehe alles. Halte die Verifikation vom normalen Lesen der Protokolle getrennt. Ein Prüfwerkzeug sollte mit gespeicherten verschlüsselten Aufzeichnungen arbeiten und melden, ob die Kette intakt ist. Sallyport stellt diese Prüfung über `sp audit verify` bereit. Damit lässt sich das verschlüsselte, hashverkettete Audit-Protokoll ohne Tresorschlüssel prüfen. Das ist wichtig, weil ein Ermittler die Kontinuität der Aufzeichnungen testen können sollte, ohne Zugriff auf Zugangsdaten zu erhalten. Verifikationsergebnisse brauchen einen operativen Umgang. Wenn eine Kettenprüfung fehlschlägt, bewahre den betroffenen Speicher auf, behandle das Journal nicht länger als vollständigen Beleg, ermittle den ersten fehlerhaften Sequenzpunkt und vergleiche die Aufzeichnungen des Zielsystems für diesen Zeitraum. Erzeuge nicht einfach eine neue saubere Kette und mache weiter. Damit würdest du einen erkennbaren Integritätsfehler in eine nicht beantwortbare Lücke verwandeln. ## Zugriff und Aufbewahrung entscheiden, ob das Journal selbst zum Einfallstor wird Auch eine minimale Aufzeichnung kann schaden, wenn zu viele Menschen sie dauerhaft durchsuchen können. Der Autorisierungsverlauf kann Mitarbeiteraktivitäten offenlegen. Zielnamen können Infrastruktur verraten. Projektkennungen können geschäftliche Arbeit sichtbar machen. Beschränke den Zugriff nach Untersuchungsrolle, nicht aus allgemeiner Neugier. Trenne operative von forensischen Ansichten. Die meisten Entwickler brauchen für die Diagnose eines fehlgeschlagenen Laufs eine aktuelle Liste von Aktionen, Status, Zielen und Sitzungsidentitäten. Eine kleinere Gruppe benötigt bei einem Vorfall vielleicht Ereignis-Digests, Signaturinformationen, Freigabedetails und Zugriff auf rohe verschlüsselte Aufzeichnungen. Wer einen Agenten betreibt, braucht nicht automatisch dauerhaften Zugriff auf die gesamte Historie anderer Entwickler. Lege die Aufbewahrung fest, indem du zwei Fragen beantwortest: Wie lange kann das Team eine strittige Aktion realistisch untersuchen, und wie lange bewahrt das Zielsystem seine eigene maßgebliche Aufzeichnung auf? Wenn das Ziel die Deployment-Historie nur kurz speichert, bewahre die Aktionsmetadaten lange genug auf, um sie damit abzugleichen. Ändert eine gesetzliche oder vertragliche Vorgabe diesen Zeitraum, dokumentiere die Vorgabe und ihre verantwortliche Person. „Alles aufbewahren“ bedeutet meist, dass keine Entscheidung getroffen wurde. Auch Löschung braucht einen Nachweis. Speichere die Version der Aufbewahrungsrichtlinie und die Tatsache, dass eine geplante Löschung oder Aggregation stattgefunden hat. Bewahre die gelöschten Inhalte nicht nur zum Beweis der Löschung auf. Für langfristige Trendanalysen kannst du nach Ablauf der detaillierten Aufzeichnungen Zählungen nach Operationskategorie und Ergebnis aggregieren. ## Baue die Aufzeichnung am Gateway und teste anschließend die schlechten Pfade Am sichersten werden Prüfungsdaten dort erfasst, wo die Aktion mit Zugangsdaten stattfindet. Ein Agent sollte eine Aktion über eine begrenzte Schnittstelle anfordern, das Gateway sollte den lokalen Prozess authentifizieren und die Autorisierung anwenden, und das Gateway sollte die HTTP- oder SSH-Operation ausführen. Der Agent erhält das Ergebnis, während die Prüfaufzeichnung die Fakten der Aktion erfasst. Sallyport verwendet dieses Muster für MCP-fähige Agenten: Der lokale `sp mcp`-Shim leitet HTTP- und SSH-Aktionen über die App, deren verschlüsselter Tresor API- und SSH-Zugangsdaten aus dem Agent-Kontext heraushält. Sitzungs- und Aktivitätsjournal werden aus demselben schreibgeschützten, verschlüsselten Audit-Protokoll erzeugt. Dadurch bleiben Sitzungsfreigaben und einzelne Aufrufe verbunden, ohne dass der Agent ein Geheimnis halten muss. Teste das Design mit Fehlern, die gewöhnliche Erfolgsszenarien vermeiden: 1. Sende eine Anfrage, bei der das Ziel einen gefälschten Autorisierungs-Header zurückgibt. Stelle sicher, dass die Aufzeichnung eine Fehlerkategorie und den Status speichert, nicht den Header oder Antworttext. 2. Starte zwei Prozesse mit demselben Anzeigenamen, aber unterschiedlichen ausführbaren Identitäten. Stelle sicher, dass die Prüfansicht ihre Sitzungen trennt. 3. Genehmige eine Sitzung, beende sie und starte anschließend einen neuen Prozess. Stelle sicher, dass die alte Freigabe nicht für den neuen Lauf gilt. 4. Erzwinge eine Zeitüberschreitung und wiederhole den Aufruf. Stelle sicher, dass die Aufzeichnungen die Versuche mit einem Aufruf verbinden und festhalten, dass das Ergebnis ungewiss ist. 5. Verändere ein gespeichertes Testereignis und führe die Integritätsprüfung aus. Stelle sicher, dass die Prüfung den Fehler meldet und das Team ein schriftliches Vorgehen besitzt. Tue dies, bevor du Dashboards, Zusammenfassungen oder vom Modell erzeugte Erklärungen hinzufügst. Ein ansprechender Aktivitäts-Feed kann keine Aufzeichnung ausgleichen, die ein Token offenlegt oder ausführbare Dateien nicht voneinander unterscheiden kann. Prüfaufzeichnungen verdienen Vertrauen, wenn sie eng genug gefasst sind, um sie zu schützen, konkret genug, um Untersuchungen zu ermöglichen, und an dem Ort verankert sind, an dem eine externe Aktion tatsächlich stattfindet. Wenn eine Aufzeichnung nicht sagen kann, wer gehandelt hat, welche Berechtigung die Aktion abdeckte, welche Grenze sie überschritt und welches Ergebnis zurückkam, braucht sie bessere Felder. Wenn sie das vollständige Gespräch enthält, enthält sie zu viel.