# Temporäre Dateien von Agent-Tools: geheime Spuren finden und bereinigen

Temporäre Dateien von Agent-Tools verdienen dieselbe Aufmerksamkeit wie ein Quellcode-Repository. Ein Coding-Agent kann einen Request-Body erstellen, einen Befehl ausführen, ihn mit ausführlichem Logging wiederholen, die Ausgabe in einen Cache kopieren und das ursprüngliche Arbeitsverzeichnis sauber hinterlassen. Die sensiblen Daten befinden sich trotzdem noch auf dem Rechner, oft an Orten, die niemand in die Prüfung einbezogen hat.

Die falsche Annahme lautet, dass ein Geheimnis nur dann nach außen gelangt, wenn ein Agent es in einem Chatverlauf ausgibt. In der Praxis ist der gewöhnlichere Weg eine Anfrage mit Zugangsdaten, die in eine temporäre Datei kopiert wird, damit ein Helfer sie senden kann, oder ein fehlgeschlagener Befehl, der in einem Log landet, weil jemand letzte Woche den Debug-Modus aktiviert hat. Aufräumen ist wichtig, aber Vermeidung ist wichtiger: Übergib einem Agenten keine ungeschützten Zugangsdaten, wenn ein anderer Prozess die Aktion ausführen kann.

## Agent-Tools erstellen Kopien außerhalb des Arbeitsbaums

Ein Agent-Lauf kann Daten auf mehreren Ebenen hinterlassen, selbst wenn im Projektverzeichnis keine offensichtliche Spur zu finden ist. Der Arbeitsbaum ist nur ein möglicher Speicherort, doch Entwickler prüfen ihn oft, weil er ihnen vertraut ist. Agent, Laufzeitumgebung, Shell, Paketmanager, Editor, Terminal und Betriebssystem haben jeweils eigene Orte, an denen sie schreiben.

Unterscheide zunächst drei Arten von Material. Payload-Dateien enthalten das, was der Agent senden wollte, etwa JSON-Request-Bodies, SQL-Batches, exportierte Prompts, Patch-Dateien oder SSH-Konfigurationen. Ausgabedateien enthalten die Antwort des entfernten Systems, etwa API-Antworten, Befehlsausgaben, Datenbankexporte und Fehlerseiten. Diagnosematerial enthält die begleitenden Hinweise: Befehlsargumente, Umgebungsdetails, Stacktraces, Wiederholungen und Traces.

Alle drei Arten können sensible Daten enthalten. Ein Payload kann ein Token enthalten, weil ein Skript es vor dem Versand eingefügt hat. Eine Ausgabe kann einen Kundendatensatz oder ein Deployment-Geheimnis enthalten. Diagnosematerial kann beides in derselben Zeile erfassen. Deshalb richtet ein Debug-Log oft mehr Schaden an als der fehlgeschlagene Befehl selbst.

Eine nützliche Bestandsaufnahme umfasst diese Orte:

- Das temporäre Verzeichnis des Prozesses und `/private/tmp` unter macOS.
- Anwendungsunterstützungs-, Cache- und Log-Verzeichnisse unter `~/Library`.
- Shell-Verlauf, Exporte des Terminal-Scrollbacks und Befehls-Wrapper.
- Projektnahe Ordner wie `.cache`, `tmp`, `logs`, `.agent` und Verzeichnisse für Test-Fixtures.
- Beschreibbare Container-Layer, Bind-Mounts, CI-Arbeitsbereiche und hochgeladene Build-Artefakte.

Gehe nicht davon aus, dass ein Agent immer dasselbe vorhersehbare Verzeichnis verwendet. Unterschiedliche Versionen, Plugins, Sprachlaufzeiten und Fehlerpfade treffen unterschiedliche Entscheidungen. Ein Tool kann das durch `TMPDIR` angegebene Verzeichnis verwenden, ein von diesem Tool gestarteter Helfer dagegen `/tmp`; eine Bibliothek kann einen Cache im aktuellen Projekt ablegen. Die einzige belastbare Antwort erhältst du, wenn du deinen eigenen Lauf beobachtest.

Dasselbe gilt für Befehlsausgaben. Eine Shell-Umleitung wie `command > result.txt` ist offensichtlich. Weniger auffällig sind Logs von Terminal-Multiplexern, Debug-Archive von Paketmanagern, Trace-Dateien von HTTP-Clients und Wiederherstellungsdateien von Editoren, die nach Änderungen des Agenten geschrieben werden. Wenn ein Agent mehrere Tools aufrufen kann, solltest du davon ausgehen, dass jedes Tool eigene Aufbewahrungsgewohnheiten hat, bis du sie geprüft hast.

## Tatsächliche Schreiborte ermitteln, bevor du Dateien bereinigst

Einen falsch geratenen Pfad kannst du nicht zuverlässig bereinigen. Führe einen Agenten mit einem harmlosen, eindeutigen Marker aus und suche anschließend an allen Orten, an denen der Lauf schreiben könnte, nach diesem Marker. Verwende Testdaten, die echt genug aussehen, um dieselben Codepfade zu durchlaufen. Nutze für diesen Test niemals ein Produktiv-Token.

Beginne unter macOS damit, das vom Shell-Prozess geerbte temporäre Verzeichnis aufzuzeichnen, der den Agenten startet:

```sh
echo "TMPDIR=$TMPDIR"
ls -ld "$TMPDIR" /private/tmp /tmp
```

macOS weist jedem Benutzer häufig ein Verzeichnis unter `/var/folders` zu, und `/tmp` verweist auf `/private/tmp`. Der genaue generierte Pfad ist keine Sicherheitsgrenze und kann sich ändern. Zeichne den Wert auf, statt in einem Bereinigungsskript einen Pfad fest zu hinterlegen.

Erstelle einen leicht auffindbaren Marker und lasse den Agenten anschließend eine typische Aktion ausführen, die ihn durch einen Request-Body, ein Befehlsargument und eine Befehlsausgabe führt. Dieses Beispiel verwendet absichtlich eine Zeichenfolge ohne Geheimnischarakter:

```sh
export AGENT_TRACE_MARKER='TEMP-PAYLOAD-CANARY-9f2a7c'
printf '%s\n' "$AGENT_TRACE_MARKER" > /tmp/agent-canary.txt
```

Suche nach dem Lauf in den wahrscheinlichen benutzerspezifischen Verzeichnissen. `grep` kann auf Binärdateien und fehlende Berechtigungen stoßen. Verwende es daher als Werkzeug zum Entdecken, nicht als Beweis, dass nichts existiert.

```sh
grep -RIl --exclude='*.sqlite*' \
  'TEMP-PAYLOAD-CANARY-9f2a7c' \
  "$TMPDIR" /private/tmp \
  "$HOME/Library/Caches" \
  "$HOME/Library/Logs" \
  "$HOME/Library/Application Support" 2>/dev/null
```

Die Ausgabe sollte aus einer Liste von Dateipfaden bestehen. Beantworte für jeden Pfad vier Fragen: Welcher Prozess hat ihn geschrieben? Welche Inhaltskategorie enthält er? Wer kann ihn lesen? Wann verschwindet er? Wenn du eine Datei keinem Prozess zuordnen kannst, prüfe ihre Änderungszeit und wiederhole den Test mit einem neuen Marker. Lösche unbekannte Dateien nicht als Erstes. Du könntest den Hinweis entfernen, der zeigt, welche Komponente neu konfiguriert werden muss.

Verwende `fs_usage`, wenn eine Datei nur kurz erscheint. Damit lässt sich die Dateisystemaktivität eines Prozesses während des Agent-Laufs beobachten:

```sh
sudo fs_usage -w -f filesystem | grep -iE 'agent|tmp|cache|log'
```

Dieser Befehl erzeugt viele Ausgaben. Führe ihn nur für einen kurzen Test aus, speichere die beobachteten Pfade außerhalb eines gemeinsam genutzten Projektverzeichnisses und beende ihn anschließend. Ein Prozess, der eine Datei innerhalb einer Sekunde schreibt und wieder löscht, erscheint später nicht mehr in einer Verzeichnisliste. Ihr Inhalt kann aber bereits ein Backup, einen Watcher oder einen anderen Log-Sammler erreicht haben.

## Bei der Request-Erstellung gelangen Zugangsdaten meist nach außen

Die gefährlichste temporäre Datei entsteht oft noch vor dem Netzwerkaufruf. Viele Skripte erstellen einen Request in einer Datei, weil korrektes JSON-Quoting in der Shell umständlich ist. Die Datei beginnt harmlos. Später ergänzt jemand ein `Authorization`-Feld, ein Cookie oder eine vollständige Verbindungszeichenfolge, damit der Request funktioniert. So wird sie versehentlich zu einem dauerhaften Container für Geheimnisse.

Vermeide dieses Muster:

```sh
cat > /tmp/request.json <<'EOF'
{"endpoint":"https://api.example.invalid/export","token":"$PRODUCTION_TOKEN"}
EOF
```

Das oben verwendete Heredoc mit einfachen Anführungszeichen expandiert die Variable nicht, was zunächst sicher wirken kann. Eine spätere Änderung am Begrenzer oder eine andere Konstruktion kann das jedoch ändern. Wichtiger ist, dass dieses Design dazu verleitet, Zugangsdaten in einem Request-Artefakt abzulegen. Ein Dump des fertigen Requests im Debug-Modus würde sie offenlegen.

Lege Zugangsdaten, wenn das Protokoll es erlaubt, in die Transportschicht und stelle sicher, dass der Transport keine Header protokolliert. HTTP-Autorisierungs-Header sind besser als ein Token in einer Query-Zeichenfolge, aber auch sie sind nicht automatisch sicher. Ausführliche Clients, Proxy-Einstellungen, Exception-Handler und eigener Wiederholungscode können sie trotzdem aufzeichnen.

Die HTTP-Semantics-Spezifikation RFC 9110 besagt, dass User-Agents keine URI mit sensiblen Informationen in einem Referer-Header senden sollten. Diese Warnung verweist auf eine allgemeine Tatsache: URLs gelangen weiter, als viele erwarten. Sie landen in Zugriffslogs, Browserverläufen, kopierten Terminalbefehlen, Support-Tickets und Analysesystemen. Lege keine Bearer-Tokens, signierten URLs mit weitreichenden Berechtigungen, Passwörter oder Datenbank-Verbindungszeichenfolgen in eine URL, außer das Protokoll lässt keine Alternative und die Zugangsdaten sind nur sehr kurz gültig.

Für Shell-Argumente gilt dieselbe Vorsicht. Auf Unix-ähnlichen Systemen kann ein anderer lokaler Prozess Argumente abhängig von Berechtigungen und Plattformeinstellungen möglicherweise beobachten. Argumente landen außerdem im Shell-Verlauf, wenn ein Mensch sie kopiert, im Log eines Task-Runners und im Tool-Transkript eines Agenten. Umgebungsvariablen vermeiden einige dieser Wege, schaffen aber andere, etwa geerbte Kindprozesse und Diagnoseberichte. Keine der beiden Möglichkeiten ist ein sicherer Tresor.

Die bessere Grenze ist einfach: Der Agent fordert eine Aktion an, indem er das Ziel und die nicht sensiblen Eingaben benennt. Ein separater Besitzer der Zugangsdaten fügt die Authentifizierung unmittelbar vor dem Aufruf hinzu. Der Agent erhält die Antwort oder einen bereinigten Fehler, nicht die Zugangsdaten, mit denen die Antwort abgerufen wurde.

Sallyport folgt dieser Grenze bei HTTP- und SSH-Aktionen: Die Zugangsdaten bleiben in seinem verschlüsselten Tresor, und der Agent bittet die lokale App, die Aktion auszuführen. Dadurch verschwindet das ungeschützte Geheimnis aus dem Agent-Kontext. Antwortinhalte und vom Agenten erzeugte Debug-Dateien werden dadurch jedoch nicht automatisch harmlos. Du musst weiterhin kontrollieren, was die Aktion zurückgibt und wo der Agent es schreibt.

## Der Debug-Modus macht gewöhnliche Fehler zu Aufzeichnungen von Geheimnissen

Debug-Logging ist bei der Diagnose einer defekten Integration hilfreich. Es wurde aber gerade dafür entwickelt, die Belege zu bewahren, die normales Logging auslässt. Dazu gehören häufig Header, vollständige Request- und Antwortinhalte, Befehlszeilen, aus der Umgebung abgeleitete Einstellungen, Wiederholungsstatus und Stacktraces.

Der Fehler besteht darin, ein umfassendes Debug-Flag aktiviert zu lassen, weil ein Problem einmal aufgetreten ist. Wochen später gilt es dann für einen unabhängigen Job, bei dem jemand einen Export oder ein Deployment mit echten Berechtigungen ausführt. Die resultierende Datei kann in einem Cache-Verzeichnis liegen, von dem niemand weiß, dass es zum Tool gehört.

Behandle Diagnosematerial als eigene Datenklasse mit einer kurzen, ausdrücklich festgelegten Lebensdauer. Überlege vor dem Aktivieren eines Traces, welche Frage er beantworten soll. Geht es um die DNS-Auflösung, genügt die Resolver-Ausgabe. Geht es darum, ob der Server ein JSON-Feld ablehnt, protokolliere Statuscode und einen bereinigten Ausschnitt der Antwort. Vollständiges Wire-Logging sollte die Ausnahme bleiben, weil es Daten aufzeichnet, die zur Lösung des Problems nicht nötig waren.

Baue die Bereinigung beim Schreiben ein, nicht nachträglich. Ein Bereinigungsjob, der in Logs nach `Authorization:` sucht, übersieht benutzerdefinierte Header, JSON-Felder, URL-Parameter, mehrzeilige Werte, Base64-Blöcke und Antwortinhalte mit Geheimnissen. Sobald ein Log-Sammler oder ein Backup-Dienst die unbereinigte Datei kopiert hat, bringt das spätere Säubern des Originals wenig.

Ein sicherer Diagnose-Wrapper verwendet eine Positivliste der Felder, die er schreiben darf. Halte zum Beispiel HTTP-Methode, Host, Pfad ohne Query-Parameter, Statuscode, Dauer, Anzahl der Antwort-Bytes und eine Request-ID fest. Protokolliere nicht jeden Header mit dem Vorsatz, die problematischen später zu maskieren. Die Formate von Zugangsdaten ändern sich schneller als Bereinigungsskripte.

Diese Unterscheidung ist bei Tools wichtig, die einen Befehl vor seiner Ausführung anzeigen. Die Anzeige eines Befehls ist nicht dasselbe wie das Protokollieren seiner tatsächlichen Umgebung, und beides ist nicht dasselbe wie ein Paket-Trace. Prüfe, welche Darstellung das Tool speichert. Es kann die Konsolenausgabe bereinigen und trotzdem ein unverändertes ausführliches Log hinterlassen.

Prüfe Fehlerpfade gezielt. Brich einen Request halbwegs ab. Sende ungültiges JSON. Löse mit einem künstlichen Zugangsdatenwert einen Authentifizierungsfehler aus. Erzwinge einen Timeout, damit Wiederholungen stattfinden. Solche Pfade erzeugen temporäre Request-Dateien und Exceptions, die bei erfolgreichen Aufrufen möglicherweise nicht entstehen. Genau diese Pfade kann auch ein Angreifer provozieren, um mehr Informationen als im normalen Betrieb offenzulegen.

## Löschen unter macOS erfordert Begrenzung, kein magisches Schreddern

Bei modernen macOS-Speichern bedeutet sichere Löschung nicht, einen Dateinamen wiederholt zu überschreiben. Wear-Leveling bei SSDs, Copy-on-Write, Snapshots, Cloud-Synchronisierung und Backups führen dazu, dass Software nicht zuverlässig versprechen kann, jedes physische Überbleibsel überschrieben zu haben. Die alte Gewohnheit, ein Shredder-Programm auszuführen, vermittelt ein Gefühl des Abschlusses, ohne die relevanten Kopien zu berücksichtigen.

Nutze das Löschen, um vorhandene, zugängliche Dateien zu entfernen. Begrenze, wo sensible Daten überhaupt entstehen dürfen. Wenn du eine Offenlegung vermutest, verschlüssele und ersetze die betroffenen Zugangsdaten.

Erstelle für ein agentenspezifisches temporäres Verzeichnis vor dem Lauf restriktive Berechtigungen und entferne es danach:

```sh
run_dir="$(mktemp -d "${TMPDIR%/}/agent-run.XXXXXX")" || exit 1
chmod 700 "$run_dir"
trap 'rm -rf "$run_dir"' EXIT HUP INT TERM
export TMPDIR="$run_dir"

# launch the agent from this same shell
# agent-command
```

Damit erhält der Lauf einen bekannten Arbeitsbereich, und normale Beendigungswege entfernen ihn. Das zwingt nicht jede Abhängigkeit, `TMPDIR` zu beachten, und entfernt auch keine Inhalte, die in ein anderes Verzeichnis kopiert wurden. Deshalb steht die Untersuchung der tatsächlichen Speicherorte am Anfang.

Vermeide `rm -rf /tmp/*` und ähnlich umfassende Bereinigungsbefehle. Sie können andere Prozesse stören, für die Untersuchung benötigte Daten löschen und den falschen Eindruck erwecken, `/tmp` sei der einzige zu prüfende Ort. Lösche nur Verzeichnisse, die dein Launcher erstellt hat, und Namen, deren Besitz dein Bereinigungscode nachweisen kann.

Wenn ein Geheimnis nach außen gelangt sein könnte, ersetze oder widerrufe es, bevor du eine lange Bereinigung startest. Ein in ein unbekanntes Log kopiertes aktives API-Token ist ein aktueller Zugangsweg. Sein Dateiname ist weniger dringend als die Berechtigung, die es verleiht. Suche danach in Backups, gemeinsam genutzten Laufwerken, CI-Artefakten, Log-Aggregation und Endpunktsuchsystemen nach weiteren Kopien. Das Löschen des Originals ohne Berücksichtigung dieser Kopien lässt die Offenlegung bestehen.

Verschlüsselter lokaler Speicher verringert das Risiko bei einem verlorenen Gerät, schützt aber nicht vor einem anderen Prozess unter demselben entsperrten Benutzerkonto. Dateiberechtigungen bleiben wichtig. Ein Verzeichnismodus von `700` bedeutet, dass andere lokale Konten es nicht durchsuchen sollen. Er stoppt keinen Agent-Prozess, der bereits unter deinem Konto läuft, und auch keinen Synchronisierungsclient, dem du den Zugriff auf dein Home-Verzeichnis erlaubt hast.

## Eine Grenze für Zugangsdaten entfernt die gefährlichsten Payloads

Bereinigung hat Grenzen. Wenn ein Agent ein Produktiv-Token in einem Prompt, einer Umgebungsvariablen, einer Konfigurationsdatei oder einer Befehlsausgabe erhält, kann er es in jede Datei schreiben, die er beschreiben darf. Du kannst die Folgen begrenzen, aber diese Architektur nicht durch sorgfältiges Aufräumen sicher machen.

Halte den Besitz der Geheimnisse außerhalb des Agent-Prozesses. Der Agent sollte eine Absicht formulieren, etwa «Sende diese Deployment-Anfrage an diesen freigegebenen Endpunkt» oder «Führe diesen SSH-Befehl über diese benannte Verbindung aus». Ein lokaler Besitzer der Zugangsdaten sollte entscheiden, ob die Aktion erlaubt ist, die Zugangsdaten einfügen, die Aktion ausführen und das Ergebnis aufzeichnen. Ein Platzhalter-Token ist unnötig, wenn der Agent das Token selbst nicht benötigt.

Dadurch wird auch die Prüfung temporärer Dateien konkreter. Du kannst Agent-Arbeitsverzeichnisse auf Benutzereingaben, erzeugten Code und zurückgegebene Daten untersuchen. Du musst nicht annehmen, dass jede Datei jedes dem Agenten zugängliche Produktionsgeheimnis enthalten kann.

Ein festes Freigabemodell hat gegenüber vielen individuellen Regeln einen praktischen Vorteil: Menschen können es während eines Vorfalls erklären. Sallyport hält seinen Tresor gesperrt, bis eine lokale Authentifizierung ihn öffnet, fordert eine Autorisierung an, wenn ein neuer Agent-Prozess erstmals handelt, und kann für ausgewählte Zugangsdaten jede Nutzung einzeln freigeben lassen. Das kontrolliert Berechtigungen klar, statt zu raten, ob ein bestimmter generierter Befehl verdächtig aussieht.

Verwechsle die Autorisierung einer Aktion nicht mit Datenminimierung. Ein freigegebener Aufruf kann einen sensiblen Antwortinhalt zurückgeben, und der Agent kann diese Antwort in eine Projektdatei, einen Cache oder ein Transkript schreiben. Gestalte Antworten so klein wie möglich. Wenn eine Aufgabe nur eine Deployment-ID und einen Status benötigt, gib nicht das gesamte Konfigurationsdokument zurück. Unterstützt eine API serverseitige Filterung, solltest du sie verwenden.

SSH verdient besondere Aufmerksamkeit, weil die Ausgabe entfernter Befehle nicht begrenzt ist. Ein Befehl, der eine Konfigurationsdatei liest, nach einem Fehler Umgebungsvariablen ausgibt oder ein ausführliches Deployment-Tool startet, kann Geheimnisse an den Agenten zurücksenden. Behandle SSH-Ausgabe als Daten, für die ein Ziel, eine Aufbewahrungsdauer und eine Prüfregel nötig sind. Die Zugangsdaten können geschützt sein, während die zurückgegebene Ausgabe weiterhin gefährlich ist.

## Jeder Lauf braucht einen Besitzer, ein Verzeichnis und einen Ablaufzeitpunkt

Eine Bereinigungsrichtlinie funktioniert, wenn sie Dateien einem bestimmten Lauf zuordnet. Ein allgemeines nächtliches Skript kann nicht erkennen, ob ein temporäres Verzeichnis zu einem aktiven Prozess, einem untersuchungswürdigen fehlgeschlagenen Job oder einer unabhängigen Anwendung gehört. Ein Agent-Launcher kann das.

Verwende die Lauf-ID im Namen des Arbeitsverzeichnisses, zeichne die Startzeit auf und bewahre außerhalb des Arbeitsverzeichnisses ein kleines Manifest mit ausschließlich nicht sensiblen Metadaten auf. Das Manifest sollte angeben, welches Verzeichnis der Launcher erstellt hat, welcher Prozess dafür zuständig ist, wann es ablaufen soll und ob der Lauf abgeschlossen wurde. Schreibe keine Befehlsargumente, Request-Bodies oder Umgebungswerte in dieses Manifest.

Ein praktikabler Lebenszyklus umfasst vier Schritte:

1. Erstelle ein privates Arbeitsverzeichnis, bevor der Agent startet.
2. Setze temporäre Pfadvariablen für den Agenten und die von dir kontrollierten Helfer.
3. Entferne das Verzeichnis bei normalem Ende und markiere das Manifest als abgeschlossen.
4. Lass einen geplanten Job verwaiste Verzeichnisse markieren, die länger als eine festgelegte Frist bestehen, damit ein Mensch sie prüft.

Der geplante Job sollte Verzeichnisse aus unvollständigen Läufen markieren und nicht automatisch löschen. Ein Prozess könnte noch schreiben. Ein fehlgeschlagenes Deployment kann Belege benötigen. Nachdem ein Mensch bestätigt hat, dass das Verzeichnis verwaist und für einen Vorfall nicht erforderlich ist, kann es nach derselben Besitzregel entfernt werden.

Lege das Arbeitsverzeichnis nicht in ein Repository. Projektsuche, Versionskontrollbefehle, IDE-Indizierung, Datei-Watcher und Backup-Clients beachten Repositorys besonders. Ein benachbartes Verzeichnis an einem vom Benutzer kontrollierten temporären Ort lässt sich meist leichter von Entwicklungswerkzeugen ausschließen und als Einheit löschen.

Sei vorsichtig mit automatischer Bereinigung, die der Agent selbst startet. Ein Agent, der beliebige Bereinigungspfade wählen kann, könnte Quelldateien oder Belege löschen. Der Launcher sollte den Pfad erstellen, ihn in seinem eigenen Zustand speichern und nur Pfade löschen, die nach einer Kanonisierung seinem erzeugten Namensmuster entsprechen. Shell-Interpolation in Bereinigungscode verursacht schon ohne autonome Texterzeugung genug Unfälle.

Das Ziel ist nicht, gar nichts aufzubewahren. Du brauchst genügend Betriebsnachweise, um festzustellen, welcher Lauf einen Request erstellt hat und ob er erfolgreich war. Bewahre diese Informationen getrennt von rohen Payloads und vollständigen Ausgaben auf und halte ihre Felder bewusst unspektakulär.

## Für Logs und Backups muss eine Aufbewahrungsentscheidung gelten

Eine temporäre Datei wird in dem Moment zu einem aufbewahrten Datensatz, in dem ein anderes System sie kopiert. Backup-Software, Cloud-Synchronisierung, Endpoint-Schutz, Absturzberichte, CI-Artefakt-Uploads und zentrale Logs können ihre Lebensdauer verlängern. Der ursprüngliche Pfad kann verschwinden, während die nützliche Kopie an einem anderen Ort bestehen bleibt.

Liste jeden Prozess auf, der die von Agent-Läufen verwendeten Verzeichnisse lesen kann. Auf einem Entwicklungsrechner gehören dazu häufig ein Backup-Client, ein Editor-Indexer, eine Versionskontrolloberfläche, ein Terminal-Rekorder und ein Malware-Scanner. Einige Kopien sind erwünscht. Entscheidend ist, sie bewusst auszuwählen und ihre Aufbewahrung festzulegen, statt erst nach dem Auftauchen eines Tokens in einem Wiederherstellungsarchiv davon zu erfahren.

Halte rohe Diagnoseausgaben aus Verzeichnissen heraus, die automatisch synchronisiert werden. Dazu gehören Desktop-Ordner, gemeinsam genutzte Projektordner und Arbeitsbereiche, die ein CI-Client als Artefakt verpackt. Wenn ein Tool für die Prüfung eine große Antwort erzeugen muss, speichere sie in einem privaten Verzeichnis mit eingeschränkten Berechtigungen, lege einen Ablaufzeitpunkt fest und schließe sie, sofern die Werkzeuge das unterstützen, von der regulären Synchronisierung aus.

Ein hashverketteter Audit-Eintrag ist etwas anderes als ein Debug-Dump. Ein Audit-Eintrag sollte festhalten, wer eine Aktion angefordert hat, wann sie ausgeführt wurde und in welche Ergebniskategorie sie fiel, ohne Geheimnisse zu duplizieren. Sallyport erzeugt seine Journale für Sessions und Aktivitäten aus einem verschlüsselten Audit-Log. Mit `sp audit verify` lässt sich die Hashkette offline ohne Tresorschlüssel prüfen. So können Nachweise über Agent-Aktivitäten aufbewahrt werden, ohne jeden rohen Payload zum Bestandteil des Audit-Verlaufs zu machen.

Die Aufbewahrung muss Ausnahmen berücksichtigen. Lass während eines Vorfalls nicht zu, dass der normale Bereinigungstimer die für die Untersuchung erforderlichen Belege zerstört. Beschränke den Zugriff, bewahre die relevanten Dateien gezielt auf und dokumentiere ihren Ort. Ersetze anschließend die betroffenen Zugangsdaten und entferne das aufbewahrte Material, sobald der Vorfallsprozess es nicht mehr benötigt. Die Aufbewahrung während eines Vorfalls ist kein Grund, sämtliche gewöhnlichen Agent-Ausgaben dauerhaft zu speichern.

Prüfe Backups auch nach einer Änderung der Richtlinie. Ein neu ausgeschlossenes Arbeitsverzeichnis wirkt nur auf künftige Backup-Läufe. Bestehende Snapshots können altes Material noch enthalten, bis die Aufbewahrungsfrist des jeweiligen Anbieters abläuft. Halte diese Tatsache in der Reaktion auf die Offenlegung fest, statt so zu tun, als hätte ein `rm`-Befehl die Vergangenheit umgeschrieben.

## Teste die Bereinigung wie ein neugieriger lokaler Angreifer

Eine Bereinigungsrichtlinie, die noch nie einem Suchtest standhalten musste, ist ein Versprechen und keine Kontrolle. Teste sie mit einem künstlichen Canary, der den Zeichenfolgen ähnelt, deren Verlust du befürchtest. Untersuche den Rechner anschließend so, als wolle ein anderer lokaler Prozess ihn finden.

Führe den Test zunächst unter normalen Bedingungen aus. Platziere den Canary in einer Eingabedatei, einem Request-Feld und einer simulierten Befehlsausgabe. Lass den Agenten vollständig laufen, warte auf seinen Bereinigungshook und suche anschließend im Arbeitsverzeichnis, in Caches, Logs, Projektordnern, Shell-Verlauf und wahrscheinlichen Support-Verzeichnissen. Zeichne jeden Treffer auf und erkläre ihn.

Prüfe danach die schwierigen Fälle. Erzwinge den Absturz eines Prozesses. Brich ihn während eines Netzwerk-Requests ab. Aktiviere die ausführlichste vom Tool unterstützte Protokollierung. Starte den Agenten aus einer IDE statt aus einem Terminal. Verwende einen Container mit einem Bind-Mount zum Host. Jede Variante kann die Ausgabe an einen anderen Ort leiten.

Suche nach dem Marker und nicht nach dem Dateinamen. Ein kopierter Payload kann einen zufälligen Dateinamen erhalten, in eine SQLite-Datenbank gelangen oder in ein Archiv komprimiert werden. Wenn eine Binärdatei oder Datenbank den Canary enthält, ermittle den Schreiber und entscheide, ob Konfiguration, Ausschluss, Bereinigung oder eine andere Ausführungsgrenze erforderlich ist.

Führe ein kleines Testprotokoll mit Agent-Version, Betriebssystemversion, aktivierten Plugins, ausgeführten Befehlen, gefundenen Pfaden und Bereinigungsergebnis. Aktualisiere es, wenn du ein Tool hinzufügst, das Befehle ausführen oder Requests senden kann. Diese Arbeit ist unspektakulär, entdeckt aber Regressionen, die eine Sicherheitsprüfung des Quellcodes übersehen kann.

Führe den ersten Test noch heute mit einem harmlosen Marker durch. Wenn er an einem unerwarteten Ort auftaucht, korrigiere den Schreiber, bevor du ein umfangreicheres Löschskript baust. Die sauberste temporäre Datei ist die, die von Anfang an kein Zugangsdatenmaterial und keine sensible Antwort enthielt.