Schreibblinde Audit-Logs für KI-Agenten, die Agenten nicht bearbeiten können

Ein KI-Agent kann eine überzeugende Erklärung seiner Arbeit verfassen, nachdem er eine falsche Entscheidung getroffen hat. Diese Erklärung ist kein Beweis. Wenn der Agent die Aufzeichnungen sehen, auswählen, überarbeiten oder vermeiden kann, anhand derer Prüfer ihn bewerten, wird die Beweiskette zu einer weiteren Ausgabefläche, die der Agent optimieren kann.

Schreibblinde Audit-Logs lösen ein eng umrissenes, aber wichtiges Problem: Der Prozess, der eine externe Aktion anfordert, darf nicht zugleich die Aufzeichnung dieser Aktion kontrollieren. Das Aktionssystem zeichnet auf, was es beobachtet hat, gibt dem Agenten das benötigte Ergebnis zurück und hält den Prüfdatensatz außerhalb seiner Reichweite. Das macht einen Agenten nicht ehrlich. Es erschwert einem unehrlichen, verwirrten oder kompromittierten Agenten jedoch, die Geschichte nachträglich zu gestalten.

Dieser Unterschied ist besonders wichtig, wenn ein Agent Code ausrollen, kostenpflichtige APIs aufrufen, Cloud-Einstellungen ändern, E-Mails versenden oder SSH-Befehle ausführen kann. In solchen Fällen ist ein Chatverlauf ein schwacher Beleg. Ein Verlauf hält Behauptungen und ausgewählte Tool-Ausgaben fest. Ein Datensatz, der an der Durchsetzungsstelle entsteht, kann Anfrage, Autorisierung, Ausführung und Ergebnis aufzeichnen, selbst wenn der Agent lieber schweigen würde.

Der Agent darf nicht zugleich Aktion und Beweis kontrollieren

Ein Agent muss weniger Kontrolle über Belege haben als über die eigentliche Aufgabe. Gibt man ihm eine Datei namens audit.jsonl und weist ihn an, Einträge anzuhängen, entsteht ein Aktivitätstagebuch, aber kein Audit-Log. Der Agent kann eine Zeile vergessen, ein unangenehmes Argument schwärzen, einen Erfolg vor dem Fehlschlag des Aufrufs eintragen oder eine zweite Kopie erzeugen, die ein Prüfer nie zu sehen bekommt.

Das Problem tritt auch bei Agenten auf, die Anweisungen befolgen. Ein Agent entscheidet oft, welche Tools er aufruft, welche Ausnahme er abfängt und welchen Kontext er behält. Eine Prompt-Injection kann ihm sagen, dass er eine Anfrage nicht protokollieren soll. Ein Fehler kann eine Anfrage durch eine nicht instrumentierte Bibliothek schicken. Eine bösartige Abhängigkeit kann direkt ins Netzwerk schreiben. Wenn derselbe Prozess Aktion und Aufzeichnung besitzt, kann jeder dieser Fehler eine ordentliche, aber unvollständige Spur hinterlassen.

Trenne diese Fähigkeiten ausdrücklich:

• Der Agent bittet um eine Aktion und erhält ein begrenztes Ergebnis.
• Der Executor besitzt die Anmeldedaten, sendet die Anfrage und erstellt den Ereignisdatensatz.
• Das Journal nimmt Datensätze über einen Pfad an, den der Agent weder lesen noch ändern kann.
• Ein Prüfer liest und validiert die Datensätze über eine separate Schnittstelle.

Das ist eine Berechtigungsgrenze, kein Versprechen über das Verhalten. Der Agent sollte keinen Dateizugriff auf das Journal, keine Abfrage-API für dessen Einträge, keine Anmeldedaten zum Umschreiben des Journals und keine Möglichkeit haben, den Zeitstempel des Ereignisses festzulegen. Wenn er seine Überlegungen erklären muss, speichere diese Erklärung in einem separaten Laufartefakt und kennzeichne sie als vom Agenten bereitgestelltes Material. Vermische sie nicht mit dem Ausführungsdatensatz.

Teams vermischen häufig Absicht und Beleg. Absicht ist das, was der Agent als seine Absicht beschreibt: «den Staging-Dienst neu starten». Beleg ist das, was eine Ausführungskomponente beobachtet hat: Der Agent forderte zu einem bestimmten Zeitpunkt einen konkreten Befehl an, eine Freigabeentscheidung fiel, der Executor verband sich mit einer benannten Host-Referenz und der Befehl endete mit einem bestimmten Status. Beides ist nützlich. Die Informationen beantworten unterschiedliche Fragen und brauchen unterschiedliche Vertrauensstufen.

Schreibblind bedeutet getrennte Fähigkeiten, nicht verzögertes Lesen

Schreibblindheit bedeutet, dass ein Akteur einen Datensatz entstehen lassen kann, ohne Zugriff auf den gespeicherten Eintrag oder den späteren Prüfkontext zu erhalten. Der Agent erhält also nicht zwangsläufig kein Feedback. Eine SSH-Aufgabe braucht weiterhin stdout, stderr und einen Exit-Status. Eine HTTP-Aufgabe braucht weiterhin einen Antwortstatus und einen Body oder eine begrenzte daraus entnommene Information. Werden Ergebnisse entfernt, wird der Agent unbrauchbar, ohne dass die Beweislage dadurch stärker wird.

Die Grenze hat vier praktische Bestandteile. Erstens verwendet der Agent eine Anfrageschnittstelle, keine Anmeldedaten. Zweitens erstellt der Executor den Datensatz aus seinen eigenen Beobachtungen, statt einer vom Agenten gelieferten JSON-Struktur zu vertrauen. Drittens kann der Agent Datensätze weder auflisten noch abrufen, ändern oder löschen. Viertens kann ein Prüfer den Datensatz später untersuchen, ohne auf das Gedächtnis oder den Chatverlauf des Agenten angewiesen zu sein.

Ein Design mit verzögertem Lesezugriff erfüllt diesen Maßstab nicht. Angenommen, ein Agent schreibt Ereignisse in eine Datenbank und erhält die Zusicherung, dass er die Tabelle bis zum Ende der Sitzung nicht abfragen kann. Er kennt weiterhin das Schema. Er kann Argumentzeichenfolgen anpassen, Auslassungen wählen, Transaktionsfehler provozieren und anhand von Unterschieden bei der Fehlermeldungszeit erkennen, ob ein Datensatz gespeichert wurde. Möglicherweise besitzt er sogar Datenbankanmeldedaten, die ein anderer Codepfad missbrauchen kann.

Schreibblindheit ist stärker, wenn der Ereignispfad keine Antwort liefert, die den Zustand des Journals offenlegt. Der Executor kann die angeforderte Aktion bestätigen, sollte aber keine Ereignis-IDs, Sequenznummern, Anmerkungen von Prüfern, Risikokennzeichnungen oder Bestätigung zurückgeben, dass ein bestimmter Datensatz dauerhaft gespeichert wurde. Solche Details liefern dem Akteur Material, gegen das er optimieren kann.

Dafür muss nicht jeder Agent als feindselig gelten. Ein Agent kann aus vielen alltäglichen Gründen unsicher werden: durch eine eingeschleuste Anweisung, eine Endlosschleife, einen Tool-Fehler, eine veraltete Abhängigkeit oder einen Betreiber, der eine zu weitreichende Aufgabe gewährt. Das Design sollte mehr aushalten als gute Absichten.

Ein nur erweiterbares Log allein löst das Problem nicht

Nur erweiterbarer Speicher erkennt einige Arten von Manipulation. Er beweist nicht, dass der Aufzeichner jede relevante Aktion gesehen hat, und hindert einen Agenten nicht daran, vor der Speicherung irreführende Einträge anzuordnen. Teams kaufen häufig unveränderlichen Speicher und lassen dann direkte Netzwerk-Anmeldedaten in der Umgebung des Agenten. Die zentrale Lücke bleibt dadurch bestehen.

Betrachte zwei Deployment-Wege. Im ersten liest ein Agent ein API-Token aus einer Umgebungsvariablen und ruft den Deployment-Dienst direkt auf. Eine separate Bibliothek versucht, die Anfrage zu protokollieren. Der Agent kann die Bibliothek umgehen, einen anderen Prozess starten oder einen anderen HTTP-Client verwenden. Das Log kann perfekt nur erweiterbar bleiben, während das Deployment nie darin erscheint.

Im zweiten Weg kann der Agent einen Executor um das Deployment bitten, erhält aber niemals das Token. Der Executor kontrolliert den einzigen Weg, auf dem die Anmeldedaten angefügt werden können. Er zeichnet die Anfrage vor der Übertragung auf und aktualisiert das Ereignis nach der Antwort. Das Journal kann nur Aktionen beschreiben, die den Executor passiert haben. Der Agent hat jedoch keinen autorisierten Weg daran vorbei.

RFC 6962, die Spezifikation für Certificate Transparency, beschreibt einen Merkle-Hashbaum, der effiziente Nachweise ermöglicht, dass ein Blatt zu einem Baum gehört und ein neuerer Baum einen älteren erweitert. Das ist ein nützliches Integritätsmuster. Es behauptet nicht, dass ein Baum die vollständige Erfassung realer Ereignisse beweist. Eine Deployment-Anfrage, die nie in den Baum gelangt ist, kann in keinem Inklusionsnachweis erscheinen.

Dieselbe Einschränkung gilt für eine lineare Hashkette. Ein Datensatz kann den Digest seines Vorgängers enthalten. Wenn jemand gespeicherte Datensätze ändert, entfernt oder umordnet, schlägt die Validierung an der betroffenen Stelle fehl. Eine intakte Kette kann aber trotzdem nur eine sorgfältig ausgewählte Teilmenge der Aktionen abdecken. Setze den Aufzeichner in den Aktionspfad, bevor du die Kette feierst.

Es gibt eine zweite Einschränkung: Auch Administratoren können die Spur gefährden. Wenn ein Betreiber die Log-Datenbank ändern und die Wurzel der Kette ohne externen Zeugen zurücksetzen kann, schützt das Design hauptsächlich vor beiläufigen Änderungen. Offline-Validierung, geschützte Prüfpunkte und getrennte Zugriffsrechte geben Prüfern eine bessere Vertrauensgrundlage. Keine dieser Maßnahmen macht ein Log zu einer vollständigen Darstellung von allem, was auf einer Maschine geschehen ist.

Den Aufzeichner in den Ausführungspfad setzen

Der Aufzeichner muss die Aktion dort beobachten, wo die Anmeldedaten angefügt werden und die externe Anfrage das kontrollierte System verlässt. Logging auf der Ebene des Agent-Frameworks ist zu früh. Logging erst bei einem entfernten Dienst ist oft zu spät und kann den Autorisierungskontext auslassen. Das Ausführungs-Gateway sieht sowohl die angenommene Anfrage als auch das erhaltene Ergebnis.

Für HTTP sollte dieses Gateway eine eingeschränkte Anfrage annehmen, eine gespeicherte Anmeldeinformation auswählen, sie selbst anfügen, die Anfrage senden und einen erlaubten Teil der Antwort zurückgeben. Der Agent sollte keine rohen Authorization-Header übermitteln. Stattdessen sollte er auf eine interne Anmeldedatenbezeichnung verweisen, die das Gateway auflöst.

Eine Anfrageform kann klein genug sein, um sie zu prüfen und aufzuzeichnen:

{
  "action": "http.request",
  "credential_ref": "deploy-api",
  "method": "POST",
  "url": "https://deploy.example.internal/releases",
  "headers": {"content-type": "application/json"},
  "body": {"revision": "a18f3c"}
}

Der Executor sollte vom Aufrufer gelieferte Anmeldedaten-Header für diesen Weg ablehnen. So kann ein Agent kein anderes Token in die Anfrage schmuggeln, während im Journal eine irreführende credential_ref steht. Außerdem sollte er die URL normalisieren, bevor er sie aufzeichnet, da eine rohe URL Benutzerinformationen, Tricks mit kodierten Pfaden oder versehentlich ein Geheimnis in einem Query-Parameter enthalten kann.

Für SSH gilt dieselbe Regel. Der Agent bittet darum, einen Befehl gegen eine Host-Referenz auszuführen. Der Executor wählt die konfigurierte Identität, das Verhalten bei der Host-Prüfung und die Verbindungsmethode. Wenn der Agent einen privaten Schlüssel lesen und seinen eigenen SSH-Client aufrufen kann, kann das Auditsystem nicht mehr behaupten, seine Remote-Aktionen abzudecken.

Verwechsle ein Gateway nicht mit einem universellen Proxy. Ein Proxy versucht, breiten Datenverkehr zu beobachten. Ein Aktions-Gateway bietet eine festgelegte Gruppe von Aktionen an und besitzt die Befugnis, sie auszuführen. Diese engere Form macht es leichter, die Bedeutung des Datensatzes zu beschreiben: Dieser Executor nahm diese Aktion unter dieser Autorisierung an und erhielt dieses Ergebnis.

Ein Ereignis aufzeichnen, bevor die Außenwelt antworten kann

Ein vertrauenswürdiger Datensatz braucht ein Start-Ereignis, bevor der Executor die Aktion sendet, und ein Abschluss-Ereignis, nachdem er ein Ergebnis erhalten hat. Schreibst du erst nach einem Erfolg einen Datensatz, können ein Timeout, ein Absturz, das Beenden des Prozesses oder ein Netzwerkabbruch eine ernsthafte Anfrage aus der Geschichte verschwinden lassen.

Verwende eine Aktionskennung, die vom Executor und nicht vom Agenten erzeugt wird. Der Startdatensatz sollte die Sitzungskennung, die Identität des aufrufenden Prozesses, den Aktionstyp, das normalisierte Ziel, den sicheren Anfrage-Digest, die Autorisierungsentscheidung und einen vom Aufzeichner erzeugten Zeitstempel enthalten. Sein Status lautet started.

Nachdem der Executor eine Antwort oder einen Fehler erhalten hat, schreibt er einen Abschlussdatensatz, der auf dieselbe Aktionskennung verweist. Dieser sollte eine Ergebniskategorie wie succeeded, rejected, timed_out, transport_error oder executor_error sowie einen Antwort-Digest und begrenzte Metadaten enthalten. So kann ein Prüfer zwischen «Das Gateway hat die Anfrage abgelehnt» und «Das entfernte System hat sie möglicherweise erhalten, aber es kam keine Antwort zurück» unterscheiden.

Diese Unterscheidung hat praktische Folgen. Stell dir vor, ein Agent sendet POST /releases und verliert die Verbindung, nachdem der entfernte Dienst die Anfrage angenommen hat. Blindes Wiederholen kann zwei Releases erzeugen. Den ersten Versuch als fehlgeschlagen zu bezeichnen, weil der Client keine Antwort sah, wäre falsch. Das Journal sollte zeigen, dass der Executor den Aufruf versucht hat, dass der Transport nach Beginn der Übertragung ausfiel und dass der endgültige Zustand beim entfernten System unbekannt bleibt, bis eine andere Quelle ihn bestätigt.

Ein minimales Paar von Datensätzen könnte so aussehen:

{"seq":481,"action_id":"01HV...","state":"started","session":"run-72","type":"http.request","target":"deploy.example.internal/releases","request_sha256":"...","authorized":true,"previous_sha256":"..."}
{"seq":482,"action_id":"01HV...","state":"completed","result":"transport_error","sent":true,"response_sha256":null,"previous_sha256":"..."}

Die oben gezeigten Felder veranschaulichen eine Struktur, kein universelles Schema. Sequenzwert und Digest müssen unter der Kontrolle des Aufzeichners bleiben. Der Agent kann eine Aufgabenbezeichnung liefern, aber sie muss als nicht vertrauenswürdige Eingabe gekennzeichnet und in ihrer Länge begrenzt werden. Andernfalls kann ein Agent Geheimnisse, Anweisungen an Prüfer oder irreführende Formulierungen in ein Feld schreiben, das offiziell aussieht.

Ein Absturz zwischen den beiden Datensätzen hinterlässt eine nicht abgeschlossene Aktion. Bewahre sie auf. Ein unvollständiger Datensatz ist ein untersuchungsbedürftiger Beleg und kein aufzuräumender Ballast. Beim Neustart kann das System ihn als ungeklärt markieren, wenn es dafür eine zuverlässige Methode gibt. Es darf die Geschichte jedoch nicht nachträglich in einen ordentlichen Erfolg oder Fehlschlag umschreiben.

Das Schema muss Absicht und Ergebnis bewahren

Ein Journal, das nur «Befehl ausgeführt» speichert, beantwortet während eines Vorfalls fast keine Fragen. Ein Journal, das jedes Byte jeder Anfrage und Antwort speichert, wird zu einem sensiblen Datenablage. Der sinnvolle Mittelweg zeichnet genug strukturierten Kontext auf, um die Aktion zu identifizieren und die Autorisierung zu bewerten, und minimiert gleichzeitig Geheimnisse und unkontrollierte Inhalte.

Zeichne die Identität des aufrufenden Prozesses in einer Form auf, die das Betriebssystem feststellen kann. Unter macOS bietet die Codesignaturbehörde einen besseren Sitzungsanker als ein selbst gemeldeter Agentenname. Prozess-IDs werden wiederverwendet. Ein Anzeigename kann lügen. Zeichne genug Sitzungskontext auf, damit ein Prüfer erkennen kann, ob ein neuer Prozess den Lauf gestartet hat und ob die Freigabe für diesen Prozess galt.

Für eine HTTP-Aktion sollten Methode, normalisierte Autorität und Pfad, ausgewählte Anmeldedatenreferenz, erlaubte Anfrage-Header, Digest des Anfrage-Bodys, Entscheidungsergebnis und, sofern verfügbar, Antwortstatus erhalten bleiben. Für eine SSH-Aktion sollten Host-Referenz, gegebenenfalls Referenz auf das entfernte Konto, Befehl oder je nach Sensibilität ein Befehls-Digest, Referenz auf die ausgewählte Identität, Ergebnis der Host-Prüfung, Exit-Status und Ausgabe-Digest erhalten bleiben.

Speichere keine rohen Anmeldedaten. Lass kein Bearer-Token in eine URL, einen benutzerdefinierten Header, Befehlsargumente oder aufgezeichnete Ausgabe gelangen. Nachträgliches Schwärzen ist schwächer als das Verhindern der Erfassung, weil das Geheimnis bereits in Backups, Replikaten oder Exporten für Prüfer gelandet ist.

Bei Digests ist Sorgfalt nötig. Ein Digest beweist Gleichheit nur gegenüber Material, das der Prüfer bereits besitzt. Er sagt einem Menschen nicht, was geschehen ist. Für eine Deployment-Nutzlast kann ein gespeicherter Digest zusammen mit einer Repository-Revision gut funktionieren. Bei einem destruktiven Datenbankbefehl kann eine normalisierte Befehlsdarstellung nötig sein, weil genau die Anweisung der Beleg ist, den Prüfer brauchen.

Halte ein separates Feld für die Richtlinien- oder Freigabeentscheidung vor, die die Aktion erlaubt hat. Ein späterer Prüfer sollte beantworten können: Hat der Executor die Aktion erlaubt, weil die Sitzung freigegeben war, weil der Betreiber diese einzelne Verwendung genehmigt hatte oder weil der Tresor geöffnet war? Fasse diese Gründe nicht zu einem vagen allowed: true zusammen, wenn das menschliche Kontrollmodell von dieser Unterscheidung abhängt.

Prüfung braucht getrennten Zugriff und unabhängige Validierung

Prüfer brauchen mehr als eine durchsuchbare Tabelle. Sie müssen feststellen können, ob die Datensatzfolge intern konsistent ist und ob das System seine Grenzen bewahrt hat. Die Person, die einen Lauf untersucht, sollte nicht erst den Agenten um eine Zusammenfassung seines eigenen Verhaltens bitten müssen.

Eine Hashverkettung bietet eine konkrete Prüfung. Jeder Datensatz enthält einen Digest des vorherigen gespeicherten Datensatzes, und der Aufzeichner berechnet einen Digest des aktuellen kanonischen Datensatzes. Ein Prüfer liest die Sequenz in der richtigen Reihenfolge, berechnet jeden Digest neu und prüft, ob jede Vorgängerreferenz übereinstimmt. Das Ändern eines alten Ziels, das Entfernen eines peinlichen Fehlers oder das Vertauschen zweier Datensätze unterbricht die spätere Kette.

Kanonisierung ist wichtig. Wenn eine Komponente JSON-Text hasht, während eine andere ihn parst und neu serialisiert, können harmlose Leerzeichen oder eine andere Feldreihenfolge zu einem Validierungsfehler führen. Definiere die genaue Feldreihenfolge, Zeichenkodierung, Behandlung von Nullwerten, Zeitstempelgenauigkeit und den Digest-Algorithmus. Versioniere anschließend das Datensatzformat. Ein Prüfer sollte wissen, ob er eine bestimmte Version validieren kann, statt raten zu müssen.

Die Validierung sollte unabhängig von dem Prozess funktionieren, der die Datensätze erstellt hat. Wenn die Integritätsprüfung denselben laufenden Dienst benötigt, kann ein kompromittierter Dienst über eine beschädigte Kette lügen. Kopiere den verschlüsselten Datenstrom auf einen Prüfcomputer oder in ein geschütztes Archiv und führe die Validierung gegen diese Kopie aus.

Sallyport erstellt seine Sitzungs- und Aktivitätsjournale aus einem einzigen verschlüsselten, hashverketteten Audit-Log. Mit sp audit verify lässt sich diese Kette offline über dem Chiffretext prüfen, ohne einen Tresorschlüssel zu benötigen. Diese Trennung geht in die richtige Richtung: Die Prüfung der Belege sollte nicht voraussetzen, dass die Geheimnisse offengelegt werden, die die Aktion ermöglicht haben.

Eine Integritätsprüfung beantwortet eine begrenzte Frage: Bilden diese Datensätze die Sequenz, die der Prüfer erwartet? Sie stellt nicht fest, dass jede Serverantwort wahr war, dass das Zielsystem keinen anderen Zugriffsweg hatte oder dass ein Administrator nicht das gesamte Journal durch eine ältere gültige Kopie ersetzt hat. Wenn Rollbacks in deiner Umgebung relevant sind, bewahre geschützte Prüfpunkte auf oder sende signierte Wurzeln an ein unabhängiges Aufbewahrungssystem.

Fehlermuster, die die Spur unbemerkt zerstören

Die schädlichsten Designs sehen in einer Demo meist vernünftig aus. Sie scheitern bei Wiederholungen, Ausfällen oder einem Agenten, der dieselbe Berechtigung auf unerwartete Weise nutzt.

Der erste Fehler ist das Logging aus dem Agent-SDK. Es ist beliebt, weil es nur wenige Codezeilen benötigt und Entwicklern eine vertraute Trace-Ansicht bietet. Es kann keinen Ausführungsdatensatz liefern, wenn der Agent Anmeldedaten erhält, ein anderes Programm startet oder ein Ziel aufruft, das das SDK nicht umschließt. Behandle SDK-Traces als Debugging-Daten.

Der zweite Fehler ist ein einzelner Erfolgsdatensatz. Ein Eintrag, der nur nach einer sauberen Antwort geschrieben wird, beseitigt Mehrdeutigkeiten. Netzwerkoperationen haben unklare Ergebnisse, und Remote-Befehle können den Zustand ändern, bevor eine Verbindung geschlossen wird. Zeichne Start und Abschluss getrennt auf und bewahre unvollständige Starts auf.

Der dritte Fehler besteht darin, Geheimnisse in die Audit-Nutzlast zu schreiben. Teams rechtfertigen das manchmal damit, dass Prüfer eine vollständige Wiederholung benötigen. Prüfer brauchen selten ein Bearer-Token, um eine Aktion zu verstehen, und kopierte Geheimnisse machen das Journal zu einem lohnenden Ziel. Speichere stattdessen Referenzen auf Anmeldedaten und Anfrage-Digests.

Der vierte Fehler ist, Prüfern einen veränderbaren Suchindex zu geben und ihn als Quelle der Wahrheit zu behandeln. Suchindizes verlieren Felder, lassen Dokumente ablaufen und erlauben Korrekturen. Bewahre einen dauerhaften Ereignisstrom als maßgeblichen Datensatz auf. Erzeuge daraus eine Suchansicht und lass den Prüfer bei verdächtigen Ergebnissen zum ursprünglichen Datensatz zurückkehren.

Der fünfte Fehler ist eine weitreichende Ausweichmöglichkeit. Ein Befehl wie «beliebige Shell mit der Produktionsumgebung ausführen» macht sorgfältige Verwaltung von Anmeldedaten und Ereignismodellierung zunichte. Manchmal braucht ein Betreiber einen privilegierten Ausnahmezugriff. Mache daraus eine separat genehmigte Aktion mit einem ausdrücklichen Datensatz, statt sie im normalen Agentenweg zu verstecken.

Menschliche Freigabe und Schreibblindheit lösen unterschiedliche Risiken

Eine Freigabe kann eine unsichere Aktion verhindern, bevor sie stattfindet. Schreibblindheit bewahrt Belege, nachdem eine Aktion angefordert wurde. Wenn ein Agent mit folgenreichen Anmeldedaten arbeitet, braucht ein Team beides.

Eine Sitzungsfreigabe eignet sich, wenn ein Mensch einem bestimmten Agent-Prozess für einen begrenzten Arbeitszeitraum vertraut. Eine Freigabe pro Aktion eignet sich für eine Anmeldeinformation oder Operation, die jedes Mal menschliche Aufmerksamkeit verdient. Keine der beiden Freigabearten ersetzt einen Ausführungsdatensatz. Eine freigegebene Sitzung kann weiterhin versehentlich einen Aufruf durchführen, und ein Agent kann weiterhin falsch beschreiben, was er getan hat.

Der Freigabebildschirm sollte den aufrufenden Prozess in einer Form identifizieren, die ein Mensch beurteilen kann. Eine selbst gewählte Bezeichnung wie «Release-Assistent» ist schwach. Eine etablierte Codesignaturbehörde gibt einem Betreiber ein verlässlicheres Signal darüber, welches Programm die Berechtigung angefordert hat. Die Freigabeentscheidung sollte Teil des Ereigniskontexts werden. Der Agent darf jedoch nicht kontrollieren, wie das System diese Identität beschreibt.

Halte die Tresorfreigabe von der Genehmigung getrennt. Ein gesperrter Tresor muss Aktionen ablehnen, auch wenn zuvor eine Sitzungsfreigabe erteilt wurde. So entsteht ein einfaches Not-Aus: Wird die Berechtigung gesperrt, verwendet der Executor keine gespeicherten Anmeldedaten mehr. Das Journal sollte auch Ablehnungen aufzeichnen. Eine Folge abgelehnter Anfragen kann zeigen, dass ein Agent in einer Schleife läuft, sondiert oder nach dem Entzug des Zugriffs weitermacht.

Verwandle das nicht in eine riesige Regelsprache, wenn du sie nicht wirklich brauchst. Regeln, die während eines Vorfalls niemand prüfen kann, erzeugen falsche Sicherheit. Eine kleine Zahl klarer Kontrollen, eine eingeschränkte Aktionsschnittstelle und Datensätze, die der Agent nicht gestalten kann, sind oft besser als ein Haufen bedingter Ausnahmen.

Die Grenze um die Aktion bauen, die Schaden anrichten kann

Beginne mit der externen Aktion, deren Missbrauch eine unangenehme Untersuchung auslösen würde. Das kann ein SSH-Befehl in der Produktion, ein Aufruf der Release-API, eine Kontoänderung oder eine kostenpflichtige Anfrage sein. Entferne die Anmeldedaten aus der Umgebung des Agenten, zwinge diese Aktion durch einen Executor und teste die Fehlerpfade, bevor du weitere Tools anschließt.

Führe diesen kurzen Test gegen das Design aus:

1. Fordere eine Aktion an und beende anschließend den Agent-Prozess, während die Anfrage läuft. Bestätige, dass das Journal ein Start-Ereignis behält.
2. Lass das entfernte Ziel einen Fehler zurückgeben und bestätige, dass der Abschlussdatensatz Ablehnung, entfernten Fehler und Transportfehler unterscheidet.
3. Versuche dieselbe Aktion mit einem vom Aufrufer gelieferten Anmeldedaten-Header oder privaten Schlüssel. Bestätige, dass der Executor dies ablehnt.
4. Gib dem Agenten seine normalen Schnittstellen und versuche, Audit-Datensätze aufzulisten, zu ändern oder zu löschen. Bestätige, dass er dafür keinen Weg besitzt.
5. Kopiere das gespeicherte Journal an einen anderen Ort und validiere seine Kette, ohne auf den Live-Status des Executors angewiesen zu sein.

Diese Tests finden Designlücken, die eine Demo mit erfolgreichem Verlauf verbirgt. Sie erzwingen außerdem eine präzise Antwort auf eine unangenehme Frage: Welche Aktionen kann der Agent weiterhin außerhalb des aufgezeichneten Gateways ausführen? Wenn dazu Produktionsberechtigungen gehören, ist der Datensatz absichtlich unvollständig. Benenne das offen, schließe den Weg oder schränke die Aussagen über die Audit-Spur ein.

Ein nützlicher Audit-Datensatz beginnt, bevor die Anfrage das System verlässt, endet mit dem besten beobachteten Ergebnis und bleibt außerhalb der Kontrolle des Agenten. Baue diese Grenze, bevor der erste Vorfall dich auffordert, der Version der Ereignisse zu vertrauen, die ein Agent erzählt.