Audit-Logs für KI-Agenten-Sandboxen: Was Sicherheitsteams benötigen

Audit-Logs für KI-Agenten-Sandboxen müssen die Ausführung von Befehlen und Prozessen, Dateilesen und -schreiben, ausgehende Netzwerkaufrufe und Egress-Ziele, Paketinstallationsereignisse, Tool-Aufrufe, Zusammenfassungen von Modelleingaben und -ausgaben auf Sitzungsebene, Treffer von Ressourcengrenzen und Sitzungslebenszyklusereignisse erfassen. Ohne diese Abdeckung kann ein Sicherheitsteam nicht rekonstruieren, was ein Agent getan hat, eine Kompromittierung zurückverfolgen oder eine Überprüfung nach einem Vorfall durchführen. Lücken in einer dieser Kategorien hinterlassen tote Winkel, die im Nachhinein nur schwer oder gar nicht zu schließen sind.

Warum KI-Agenten-Sandboxen ein anderes Audit-Logging benötigen

Traditionelle Server-Audit-Logs gehen davon aus, dass jede Aktion von einem Menschen oder einem deterministischen Anwendungsprozess ausgelöst wurde. KI-Agenten brechen mit dieser Annahme. Ein einzelner Prompt kann dazu führen, dass eine Sitzung Pakete installiert, Dateien schreibt, Shell-Befehle ausführt, externe APIs aufruft und Subprozesse startet – alles innerhalb von Sekunden, ohne menschliche Genehmigung für einzelne Schritte.

Dadurch ändert sich, welche Fragen ein Audit-Log beantworten muss. Bei einem traditionellen Server lautet die Frage meist: „Hat ein autorisierter Benutzer diese Datei geändert?“ Bei einer Agenten-Sandbox lauten die Fragen:

• Was hat das Modell ausgeführt, und in welcher Reihenfolge?
• Welche Shell-Befehle wurden ausgeführt und als welcher Prozess?
• Hat der Agent auf Dateien zugegriffen, die er nicht hätte berühren sollen?
• Was hat die Sandbox über das Netzwerk verlassen, und wohin ist es gegangen?
• Hat eine Paketinstallation unerwarteten Code eingeführt?
• Was tat der Agent, als er eine Ressourcengrenze erreichte oder beendet wurde?

Ein Logsystem, das diese Fragen beantworten kann, gibt Sicherheitsteams die Fähigkeit zur Rekonstruktion. Ein Logsystem, das dies nicht kann, lässt die Incident-Response im Ungewissen.

Logs zur Befehls- und Prozessausführung

Die Prozessausführung ist die Kategorie mit der höchsten Priorität. Jeder Befehl, den der Agent ausführt – direkt oder über einen Shell-Subprozess – sollte einen Logeintrag erzeugen, der Folgendes enthält: den Prozessnamen und die vollständige Argumentliste, den Elternprozess und die PID, den Benutzer und die effektive UID, das Arbeitsverzeichnis, den Zeitstempel mit Subsekundengenauigkeit und den Exit-Code.

Ohne die Argumentliste sind Befehle wie python, curl oder bash bei einer Post-Incident-Aufklärung nahezu bedeutungslos. Ohne die UID lässt sich nicht feststellen, ob der Agent mit erhöhten Rechten ausgeführt wurde. Ohne die Eltern-PID-Kette können Sie keine verschachtelten Subprozesse rekonstruieren oder nachvollziehen, wie ein Befehl aufgerufen wurde.

Linux-Audit-Subsysteme wie auditd mit entsprechenden Syscall-Regeln (execve, execveat) können dies auf Kernel-Ebene innerhalb einer MicroVM-Gastinstanz erfassen. Container-basierte Sandboxen können alternativ eBPF-basiertes Tracing oder Seccomp-Logging verwenden, wobei jeder Ansatz unterschiedliche Abdeckungs- und Leistungskompromisse mit sich bringt. Aus Sicht des Sicherheitsteams ist die wichtigste Anforderung, dass das Log unterhalb der Anwendungsschicht erzeugt wird – ein Agentenprozess, der sein eigenes Logging kontrolliert, kann nicht zuverlässig sein eigenes Verhalten melden.

Dateisystemzugriffsereignisse

Die Dateisystem-Überwachung sollte Lese-, Schreib-, Lösch-, Umbenennungs- und Mount-Operationen protokollieren. Für jedes Ereignis sollte das Log enthalten: den Operationstyp, den vollständigen Pfad, den verantwortlichen Prozess und die PID, die UID und den Zeitstempel.

In der Praxis kann die Protokollierung jedes Dateizugriffs in einer stark ausgelasteten Sandbox ein hohes Datenvolumen erzeugen. Sicherheitsteams beschränken dies oft auf sensible Pfade – zum Beispiel alle Pfade unter /etc, /root, das Arbeitsverzeichnis des Agenten, Berechtigungsdateien und eingebundene Secrets. Schreib- und Löschvorgänge haben für die meisten Bedrohungsmodelle eine höhere Priorität als Lesevorgänge, aber das Lesen von Berechtigungs- oder Konfigurationsdateien sollte in jedem Fall erfasst werden.

Dateisystemereignisse sind besonders nützlich, um Datenexfiltrationsversuche (große Lesevorgänge gefolgt von ausgehenden Netzwerkaufrufen), unerwartete Konfigurationsänderungen (Schreibvorgänge in Dateien, die der Agent nicht berühren sollte) und Aufräumverhalten (am Ende einer Sitzung ausgeführte Löschvorgänge, die auf einen Versuch hinweisen können, Aktivitäten zu verbergen) zu identifizieren.

Ausgehende Netzwerkaufrufe und Egress-Logging

Egress-Logging ist einer der am häufigsten unterschätzten Bereiche bei der Bereitstellung von Agenten-Sandboxen. Viele Sandboxen protokollieren, dass ein Netzwerkverbindungsversuch stattfand; weitaus weniger protokollieren, wohin die Verbindung ging, welches Protokoll verwendet wurde und ob sie erfolgreich war.

Vollständige Egress-Logeinträge sollten enthalten: die Ziel-IP-Adresse und den Port, den aufgelösten Domainnamen (DNS-Anfrage und -Antwort), das Protokoll (TCP, UDP, HTTP usw.), die übertragenen Bytes in jede Richtung, den Prozess, der die Verbindung geöffnet hat, die UID und den Zeitstempel.

Die DNS-Abfrageprotokollierung ist separat wichtig. Ein Agent, der eine unerwartete Domain abfragt – selbst wenn die Verbindung später blockiert wird – ist ein Signal, das es wert ist, erfasst zu werden. DNS over HTTPS kann die Abfrageprotokollierung umgehen, es sei denn, die Sandbox setzt Netzwerkrichtlinien auf einer Ebene durch, die solche Anfragen abfängt.

Sandboxen, die eine Whitelist-basierte Egress-Kontrolle bieten, sollten sowohl erlaubte als auch blockierte Verbindungsversuche protokollieren. Eine hohe Anzahl blockierter Versuche zu unerwarteten Zielen ist an sich ein aussagekräftiges Sicherheitssignal.

Paketinstallationsereignisse

Paketinstallationen sind ein besonders wertvolles Audit-Ziel, da sie die Laufzeitumgebung auf eine Weise verändern, die für die Dauer der Sitzung bestehen bleibt und möglicherweise nachgelagerte Operationen beeinflusst. Jedes Installationsereignis sollte erfassen: den verwendeten Paketmanager (pip, npm, apt, cargo usw.), den Paketnamen, die angeforderte Version, die aufgelöste Version, die Quell-URL oder Registry, den Paket-Hash oder die Prüfsumme, den Prozess und die UID sowie den Zeitstempel.

Die Quell-URL ist wichtig. Ein Paket, das von einer privaten Registry, einer direkten URL oder einem ungewöhnlichen Mirror installiert wird, hat ein anderes Risikoprofil als eines, das von der öffentlichen Standard-Registry installiert wird. Der Hash ist für die Überprüfung nach einem Vorfall wichtig – wenn ein Paket später als bösartig eingestuft wird, möchten Sie wissen, ob genau diese Version in einer bestimmten Sitzung installiert wurde.

Sandboxen, die Paketinstallationen vollständig blockieren, eliminieren diese Risikokategorie, schränken aber auch die Möglichkeiten von Agenten erheblich ein. Die meisten Produktionsumgebungen benötigen einen Mittelweg: alles protokollieren, Installationen von einer genehmigten Quellenliste erlauben und Installationen von unbekannten Quellen kennzeichnen oder blockieren.

Tool-Aufrufe und Ergebnisse

KI-Agenten arbeiten typischerweise über einen Tool-Call-Mechanismus, bei dem das Modell eine benannte Aktion anfordert – Code ausführen, Datei lesen, API aufrufen, Websuche – und die Orchestrierungsschicht diese ausführt. Diese Tool-Aufrufe liegen oberhalb der Betriebssystemebene und sind Anwendungsschicht-Ereignisse, aber sie sind wichtig zu protokollieren, da sie die Absicht des Modells und nicht nur die systemseitige Konsequenz darstellen.

Tool-Aufruf-Logs sollten erfassen: den Tool-Namen, eine Zusammenfassung der Eingabeparameter (nicht den vollständigen Inhalt, wenn dieser Secrets oder personenbezogene Daten enthalten würde), eine Zusammenfassung des Ergebnisses (Erfolg, Fehler, Timeout), die Sitzungs-ID und den Zeitstempel.

Die vollständige Eingabe und Ausgabe jedes Tool-Aufrufs zu protokollieren, ist für das Debugging nützlich, birgt jedoch Risiken für Datenschutz und Geheimnisweitergabe. Ein praktischer Ansatz ist, Tool-Namen und Status bedingungslos zu protokollieren, Zusammenfassungen von Eingabe/Ausgabe auf einem konfigurierbaren Detailgrad zu erfassen und eine Möglichkeit bereitzustellen, bei Bedarf für bestimmte Sitzungen während einer Untersuchung mit entsprechenden Zugriffskontrollen die vollständigen Details abzurufen.

Das Ziel ist genügend Signal, um die Aktionssequenz des Agenten zu rekonstruieren, ohne einen Log-Speicher zu schaffen, der selbst ein hochwertiges Angriffsziel darstellt.

Sitzungslebenszyklus-Ereignisse

Sitzungslebenszyklus-Ereignisse verankern alle anderen Logeinträge. Eine Sitzungs-ID, die in jedem Ereignistyp erscheint, ermöglicht es, Logs kategorieübergreifend zu verknüpfen und die Frage zu beantworten: „Was ist in diesem spezifischen Durchlauf passiert?“

Zu protokollierende Lebenszyklus-Ereignisse:

Ereignis	Wichtige Felder
Sitzung erstellen	Sitzungs-ID, Benutzer-/Mandanten-ID, Vorlagen- oder Imagename, Ressourcenkonfiguration, Zeitstempel
Sitzung starten	Sitzungs-ID, Host-Identifikator, zugewiesene Ressourcengrenzen, Zeitstempel
Sitzung pausieren	Sitzungs-ID, Grund (API-Aufruf, Timeout, Auto-Pause), Zeitstempel
Sitzung fortsetzen	Sitzungs-ID, fortsetzender Akteur, Zeitstempel
Sitzung beenden	Sitzungs-ID, Beendigungsgrund (normal, Timeout, OOM, API-Aufruf, Richtlinienverstoß), Exit-Status, Zeitstempel
Sitzung bereinigen	Sitzungs-ID, Dateisystemzustand bei Bereinigung (erhalten, gelöscht, Snapshot gespeichert), Zeitstempel

Der Beendigungsgrund ist besonders nützlich bei der Nachbearbeitung. Eine Sitzung, die aufgrund eines Richtlinienverstoßes, eines OOM-Kills oder eines unerwarteten Signals anstatt einer sauberen Beendigung terminiert wurde, sollte genauer untersucht werden. Sitzungen, die pausiert und fortgesetzt wurden, sollten auf Zustandskontinuität überprüft werden – hat sich zwischen Pause und Fortsetzung etwas in der Umgebung geändert?

Ressourcengrenzen-Ereignisse

Ressourcengrenzen-Ereignisse erfassen Momente, in denen eine Sitzung eine konfigurierte Obergrenze erreicht hat und das System Maßnahmen ergriffen hat. Diese Ereignisse signalisieren entweder normales Hochlastverhalten oder etwas Besorgniserregenderes – einen außer Kontrolle geratenen Prozess, eine unerwartete Berechnungsspitze oder einen absichtlichen Versuch, Ressourcen zu erschöpfen.

Logeinträge für Ressourcengrenzen-Ereignisse sollten enthalten: den Grenztyp (CPU-Drosselung, Speicher-OOM, Festplattenkontingent, Netzwerkdatenrate, Timeout), den gemessenen Wert zum Zeitpunkt des Ereignisses, die konfigurierte Grenze, die ergriffene Maßnahme (drosseln, beenden, warnen), den betroffenen Prozess oder die Sitzung und den Zeitstempel.

OOM-Kills sind besonders untersuchungswürdig, da sie darauf hindeuten können, dass ein Agent eine große, nicht erwartete Berechnung versucht hat, ein Paket unerwartet große Daten geladen hat oder ein Speicherleck vorliegt. CPU-Drosselungsereignisse in einer Sitzung, die nur leichte LLM-Aufrufe durchführen sollte, können darauf hindeuten, dass innerhalb der Sandbox etwas anderes läuft.

Strukturierte vs. unstrukturierte Logformate

Unstrukturierte Logs – Freitextzeilen wie 2026-06-29 10:04:00 INFO: process python started – sind lesbar, aber schwer zu durchsuchen, zu aggregieren oder in eine SIEM- oder Alarmierungspipeline zu integrieren. Für Audit-Zwecke erfordern sie ein Parsing, das bei Formatänderungen bricht.

Strukturierte Logs – typischerweise JSON oder ein gemeinsames Schemaformat wie CEF oder OCSF – erlauben, jedes Feld direkt zu indizieren, zu durchsuchen und zu alarmieren. Ein strukturiertes execve-Ereignis, das {"ts": "2026-06-29T10:04:00.123Z", "event": "process.exec", "session_id": "...", "pid": 1234, "ppid": 1, "uid": 0, "cmd": "curl", "args": ["-s", "https://..."], "exit_code": 0} enthält, ist sofort nach jedem seiner Felder durchsuchbar.

Für Sicherheitsteams, die einen Sandbox-Anbieter evaluieren, sind die Schlüsselfragen:

• Sind die Logs strukturiert oder unstrukturiert?
• Welches Schema oder Format wird verwendet, und ist es dokumentiert?
• Können Logs in Echtzeit an ein externes SIEM oder Log-Aggregationssystem gestreamt werden?
• Wie hoch ist die Latenz zwischen einem Ereignis und seiner Verfügbarkeit im Log-Stream?

Echtzeit- oder nahezu Echtzeit-Streaming ist wichtig für Erkennungsanwendungsfälle. Ein Log, das erst Stunden nach dem Ende einer Sitzung verfügbar ist, ist für die Incident-Rekonstruktion nützlich, aber nicht für Live-Alarmierungen.

Log-Integrität und Nachweissicherheit gegen Manipulation

Ein Audit-Log, das der Agent ändern kann, ist kein Audit-Log. Dies ist die Anforderung der Nachweissicherheit gegen Manipulation: Das Log muss so erzeugt und gespeichert werden, dass der Agentenprozess seine eigenen Einträge nicht ändern, löschen oder unterdrücken kann.

Auf Implementierungsebene bedeutet dies in der Regel:

• Kernel-Level-Loggenerierung (Audit-Subsystem, eBPF) anstelle von Anwendungsschicht-Logging innerhalb der Sandbox
• Log-Export an ein externes Ziel, das der Sandbox-Prozess nicht erreichen kann
• Write-Once- oder Append-Only-Logspeicher ohne eine vom Sandbox-Netzwerk aus zugängliche Lösch-API
• Logeinträge, die bei der Generierung signiert oder mit einer Prüfsumme versehen werden, sodass Manipulation oder Verkürzung nachträglich erkennbar ist

Bei verwalteten Sandbox-Anbietern ist die relevante Frage, ob der Agentenprozess einen Weg hat, die Log-Zustellung zu beeinflussen. Wenn Logs in eine Datei innerhalb der Sandbox geschrieben und dann versendet werden, könnte ein ausreichend privilegierter Agentenprozess in den Versand eingreifen. Wenn Logs auf Hypervisor- oder Hostebene erzeugt und out-of-band versendet werden, hat der Agent keinen Zugriff.

Die Nachweiskette für Logdaten – besonders wichtig für Compliance oder rechtliche Überprüfungen – erfordert, dass der Log-Erfassungspfad, die Zugriffskontrollen für den Speicher und alle auf die Rohdaten angewendeten Transformationen dokumentiert und selbst prüfbar sind.

Aufbewahrungsrichtlinien für Audit-Logs von KI-Agenten-Sandboxen

Die Aufbewahrungsanforderungen für Audit-Logs von KI-Agenten-Sandboxen hängen vom regulatorischen Umfeld, dem Risikoprofil der Workloads und dem Incident-Response-Zeitplan ab, den das Sicherheitsteam unterstützen muss.

Praktische Ausgangspunkte für Sicherheitsteams zur Bewertung:

Anwendungsfall	Empfohlene Mindestaufbewahrungsdauer
Aktive Incident-Untersuchung	Heiß/durchsuchbar für mindestens 90 Tage
Forensik nach einem Vorfall	Verfügbar in Kühlspeicher für 12–24 Monate
Compliance-Überprüfung (SOC 2, ISO 27001)	Gemäß den Anforderungen des jeweiligen Frameworks
Rechtliche Verfügung (Legal Hold)	Bis zur ausdrücklichen Freigabe

Für KI-Agenten-Workloads ist eine Heißspeicherung von 90 Tagen eine sinnvolle Basislinie, da Kompromittierungsmuster bei autonomen Agenten möglicherweise nicht sofort entdeckt werden – ein Agent, der vor drei Wochen während einer Sitzung Daten exfiltriert hat, wird möglicherweise erst dann identifiziert, wenn eine nachgelagerte Anomalie bemerkt wird.

Das Volumen ist ein realer Kostenfaktor. Eine Sandbox, die Tausende von Sitzungen pro Tag mit vollständigem execve- und Netzwerk-Logging ausführt, kann erhebliche Datenmengen erzeugen. Gestaffelter Speicher – heiß für aktuelle Daten, warm für mittelfristige, kalt für die Archivierung – ist ein üblicher Ansatz. Komprimierung und feldspezifische Filterung (nur hochpriorisierte Ereignistypen in voller Detailtreue protokollieren) sind ebenfalls überlegenswert, wobei der Kompromiss darin besteht, dass gefilterte Logs möglicherweise unerwartete Ereignistypen übersehen.

Logs für die Incident-Response bereitstellen

Logs zu sammeln ist notwendig, aber nicht ausreichend. Logs, die in einem Bucket liegen, den niemand abfragt, bieten keinen Schutz. Für Sicherheitsteams besteht die betriebliche Anforderung darin, bestimmte Fragen schnell beantworten zu können:

• Was hat Sitzung X zwischen den Zeitpunkten T1 und T2 getan?
• Welche Sitzungen haben auf Pfad P zugegriffen?
• Welche Sitzungen haben ausgehende Verbindungen zu Domain D hergestellt?
• Welche Sitzungen haben Paket V installiert?
• Welche Sitzungen wurden mit dem Grund R beendet?

Dies erfordert eine Abfrageschnittstelle – entweder eine SIEM-Integration, eine Log-Analytikplattform oder eine vom Anbieter bereitgestellte API – bei der Sitzungs-ID, Ereignistyp, Zeitstempelbereich, Pfad, Domäne und andere wichtige Felder indiziert und durchsuchbar sind.

Die Alarmierung auf bestimmte Muster ist die zweite Ebene. Hochprioritäre Signale für KI-Agenten-Sandboxes sind: Ausführung bekanntermaßen gefährlicher Befehle (curl | bash, wget -O - | sh, base64 -d | sh), ausgehende Verbindungen zu unerwarteten oder neu registrierten Domänen, Paketinstallationen von Nicht-Registry-URLs, Schreibvorgänge in Berechtigungsdateipfade, Sitzungen, die mit Richtlinienverstoß oder OOM-Kill beendet werden, und jedes Ereignis, das unter UID 0 auftritt, wenn der Agent nicht als root ausgeführt werden sollte.

Vorgefertigte Erkennungsregeln, die auf Verhaltensmuster von Agenten-Sandboxen kalibriert sind, verkürzen die Zeit bis zur ersten Warnung bei neuartigen Aktivitäten. Sicherheitsteams, die Sandbox-Anbieter evaluieren, sollten fragen, ob der Anbieter Erkennungsregeln, Log-Schema-Dokumentation und Beispiel-SIEM-Integrationen bereitstellt oder ob diese Ebene vollständig vom Kunden aufgebaut werden muss.

Was Sie Ihren Sandbox-Anbieter fragen sollten

Bei der Evaluierung einer KI-Agenten-Sandbox hinsichtlich der Audit-Log-Abdeckung sind dies die konkreten Fragen, die Sie einem Anbieter stellen sollten:

1. Welche Ereigniskategorien werden standardmäßig protokolliert und welche erfordern eine Konfiguration?
2. Werden die Logs auf Kernel-/Hypervisor-Ebene oder innerhalb des Sandbox-Prozesses erzeugt?
3. Welches strukturierte Logformat wird verwendet und ist das Schema öffentlich dokumentiert?
4. Können Logs in Echtzeit an ein externes Ziel gestreamt werden?
5. Wie lautet die Datenaufbewahrungsrichtlinie und kann sie verlängert werden?
6. Hat der Sandbox-Prozess einen Weg, seine eigenen Logeinträge zu ändern oder zu unterdrücken?
7. Sind die Logeinträge signiert oder anderweitig manipulationssicher?
8. Gibt es eine Abfrage-API oder eine SIEM-Integration?
9. Gibt es vorgefertigte Erkennungsregeln oder Alarmierungsvorlagen für häufige Sandbox-Bedrohungsmuster?

Keine Sandbox-Bereitstellung ist standardmäßig in Bezug auf das Logging vollständig. Lücken zwischen dem, was ein Anbieter sammelt, und dem, was ein Sicherheitsteam zur Rekonstruktion eines Vorfalls benötigt, sind häufig. Diese Lücken vor der Bereitstellung zu identifizieren, anstatt nach einem Vorfall, ist der praktische Nutzen dieser Art von Evaluierung.

Novita Agent Sandbox bietet Sitzungslebenszyklus-Ereignisse, Ausführungsprotokolle und Ressourcenmetriken, die über die API zugänglich sind. Sicherheitsteams, die Novita Agent Sandbox evaluieren, sollten die aktuelle Log-Abdeckung, Exportoptionen und Aufbewahrungskonfiguration in der Produktdokumentation überprüfen, bevor sie Architekturentscheidungen treffen.

Fazit

Audit-Logging für KI-Agenten-Sandboxen ist keine Funktion, die Sie nach einem Vorfall nachrüsten können. Die relevanten Ereigniskategorien – Prozessausführung, Dateisystemzugriff, ausgehender Datenverkehr, Paketinstallationen, Tool-Aufrufe, Sitzungslebenszyklus und Ressourcengrenzen – müssen vor der Produktionsaufnahme eines Workloads festgelegt werden, und der Log-Erfassungspfad muss außerhalb der Reichweite des Agenten liegen.

Die praktische Checkliste für Sicherheitsteams ist einfach: Identifizieren Sie, welche Ereigniskategorien Ihr Sandbox-Anbieter standardmäßig erfasst, bestätigen Sie, dass die Logs auf Kernel- oder Hypervisor-Ebene und nicht innerhalb des Agentenprozesses erzeugt werden, vergewissern Sie sich, dass eine strukturierte Ausgabe für die SIEM-Integration verfügbar ist, und legen Sie Aufbewahrungsrichtlinien fest, bevor Sie sie für eine Untersuchung benötigen.

Lücken in einem dieser Bereiche sind Lücken in Ihrer Fähigkeit, die Frage „Was hat dieser Agent getan?“ zu beantworten – und bei autonomen Agenten, die im großen Maßstab operieren, wird diese Frage irgendwann eine Antwort erfordern.

FAQ

Welche Ereignisse sollten Audit-Logs von KI-Agenten-Sandboxen erfassen?

Mindestens: Befehls- und Prozessausführung (mit vollständigen Argumentlisten), Dateisystem-Lese-/Schreib-/Löschvorgänge, ausgehende Netzwerkverbindungen und DNS-Abfragen, Paketinstallationsereignisse mit Quell-URLs und Hashes, Tool-Aufrufe und Ergebnisstatus, Sitzungslebenszyklus-Ereignisse (Erstellen, Pausieren, Fortsetzen, Beenden, Bereinigen) und Ressourcengrenzen-Ereignisse (CPU-Drosselung, OOM-Kill, Timeout). Das Fehlen einer dieser Kategorien hinterlässt tote Winkel, die nachträglich nicht mehr rekonstruiert werden können.

Warum kann ich mich nicht auf Anwendungsschicht-Logging innerhalb der Sandbox verlassen?

Ein Agentenprozess, der sein eigenes Logging kontrolliert, kann Einträge über sein eigenes Verhalten unterdrücken oder ändern – absichtlich oder aufgrund eines Fehlers. Die Erfassung auf Kernel-Ebene (über auditd, eBPF oder Hypervisor-Instrumentierung) erzeugt Logeinträge unterhalb der Anwendungsschicht, auf die der Agent keinen Schreibzugriff hat. Dies ist die Anforderung der Manipulationssicherheit: Das Log muss an einem Ort erzeugt werden, den der Agent nicht erreichen kann.

Wie lange sollten Audit-Logs von KI-Agenten-Sandboxen aufbewahrt werden?

Eine praktische Basislinie: 90 Tage in heißem, durchsuchbarem Speicher für aktive Untersuchungen, 12–24 Monate in kaltem Speicher für forensische Analysen nach Vorfällen. Compliance-Frameworks wie SOC 2 und ISO 27001 haben eigene Anforderungen, die diese Basislinien überschreiben können. Bei rechtlichen Verfügungen sollte die Aufbewahrung fortgesetzt werden, bis sie von der Rechtsabteilung ausdrücklich freigegeben wird.

Was ist der Unterschied zwischen strukturierten und unstrukturierten Audit-Logs?

Unstrukturierte Logs sind Freitextzeilen, die zum Abfragen geparst werden müssen. Strukturierte Logs verwenden ein konsistentes Schema (JSON, CEF, OCSF), bei dem jedes Feld direkt indiziert und durchsuchbar ist. Für den Sicherheitsbetrieb sind strukturierte Logs wesentlich einfacher in SIEM-Plattformen zu integrieren, Erkennungsregeln zu erstellen und während der Incident-Response abzufragen.

Kann ein KI-Agent seine eigenen Audit-Logs manipulieren?

Das hängt davon ab, wo die Logs erzeugt und gespeichert werden. Wenn Logs in eine Datei innerhalb der Sandbox geschrieben und extern versendet werden, kann ein privilegierter Agentenprozess in die Versandpipeline eingreifen. Wenn Logs auf Hypervisor- oder Hostebene erzeugt und direkt an ein externes Ziel geschrieben werden, das das Sandbox-Netzwerk nicht erreichen kann, hat der Agent keine Möglichkeit, sie zu ändern. Überprüfen Sie immer die Log-Erfassungsarchitektur, nicht nur das Log-Format.

Worauf sollte ich in der Audit-Log-Dokumentation eines Sandbox-Anbieters achten?

Bestätigen Sie: welche Ereigniskategorien standardmäßig protokolliert werden und welche eine Konfiguration erfordern; ob die Logs auf Kernel-/Hypervisor-Ebene oder innerhalb des Sandbox-Prozesses erzeugt werden; welches strukturierte Format und Schema verwendet wird; ob Echtzeit-Streaming an externe Systeme unterstützt wird; wie die Standard-Aufbewahrungsrichtlinie lautet und ob sie verlängert werden kann; und ob vorgefertigte Erkennungsregeln oder SIEM-Integrationen verfügbar sind.

Empfohlene Artikel

• Firecracker für KI-Agenten-Sandboxen: Vorteile, Grenzen und Evaluierungsfragen
• KI-generierte Code-Sandbox: Anforderungen für Produktions-Apps
• Erstellen eines Coding-Agenten mit Novitas Agent Sandbox