Grundlagen
ChatGPT und co. können über verschiedene Arten mit anderen System, Daten und APIs verbunden werden. In diesem Artikel bauen wir mit der Open Source Lösung n8n einen kleinen KI-Agenten welcher mit der XDR-Lösung von SentinelOne verbunden wird und so als kleiner Helfer im SOC dienen könnte. Der Agent benötigt im Wesentlichen die drei Komponenten: Chat Model, Memory und eines oder mehrere Tools.
Chat Model
Das Chat-Model ist das Herzstück des AI-Agenten. Hier wird gewählt, mit welchem der bekannten oder weniger bekannten LLM gearbeitet wird. Das können z.B. direkt OpenAI, Mistral, Anthropic oder DeepSeek sein, aber auch gehostete Modelle z.B. auf Azure oder AWS. Zudem können auch selbst gehostete und auch eigene Modelle über Ollama verwendet werden.
Memory
Das Gedächtnis erlaubt dem Chat-Model den Inhalt der Konversation zu speichern und darauf zurückzugreifen. Die einfachste Variante ist die Verwendung des Gerätespeichers selbst. Es empfiehlt sich jedoch die Verwendung einer Datenbank wie Postgres oder Redis.
Tools
Die Tools bilden den Kern des Agenten. Sie ermöglichen den Zugriff auf externe Datenquellen und Anwendungen. Vorgefertigte Tools wie z.B. Google Sheets sind einfach zu bedienen. Es muss ein Credential hinterlegt werden und danach werden die entsprechenden Felder konfiguriert.
Der Agent
Use Case
Der Agent soll in der Lage sein, über die SentinelOne‑API umfassende Agent‑Informationen (z. B. System‑ID, Status, letzte Aktivität) sowie erkannte Bedrohungen (Threat‑Details, Schweregrad, Status) auszulesen. Darüber hinaus muss er die Fähigkeit besitzen, einzelne SentinelOne‑Agents z.B. zum Troubleshooting zu deaktivieren und wieder zu aktivieren. Jede Deaktivierung eines Agents darf jedoch erst nach einer expliziten Freigabe („Approval“) erfolgen.
Aufbau
Als Chat‑Model kommt Mistral zum Einsatz, als Memory‑Layer dient eine PostgreSQL‑Datenbank. Für jeden der benötigten SentinelOne‑HTTP‑Endpoints existiert ein eigenes Tool: „Get Agents“ liest Agent‑Daten aus, „Get Threats“ liefert aktuelle Bedrohungsdetails, „Enable Agent“ reaktiviert deaktivierte Agents und „Restart Endpoint“ führt einen Remote‑Neustart durch. Die Deaktivierung eines Agents wird hingegen über ein separates Tool gesteuert, das den Approval‑Workflow initiiert: Es versendet eine Genehmigungsanfrage und wartet auf Freigabe bevor es den abschliessenden API‑Aufruf ausführt.
Testlauf
Zuerst holen wir Informationen über unseren Testclient ein. Der Agent listet die Informationen leserlich auf, wenn auch nicht immer in der gleichen Formatierung.
Dann geben wir den Befehl zur Deaktivierung. Der Agent informiert, dass nun ein Approval Workflow gestartet wurde, wenn auch nicht gänzlich korrekt. Das Approval könnte auch von jemand anderem eingefordert werden.
Die E-Mail mit der Aufforderung zum Approval kommt an. Das Approval könnte aber auch z.B. über Teams oder Slack eingefordert werden.
Der Agent ist nun in der Management Konsole deaktiviert.
Fazit
Zusammenfassend ist die Handhabung des KI‑Agenten trotz der zugrundeliegenden Komplexität relativ einfach: Über klar definierte Tools und ein intuitives Chat‑Interface steuert das Mistral‑Modell alle Interaktionen mit SentinelOne. Für ein zuverlässiges Fine‑Tuning müssen die einzelnen Tools jedoch sorgfältig dokumentiert werden – inklusive präziser Beschreibungen und eindeutig definierter Platzhalter, die das Modell bei API‑Aufrufen ausfüllt. Gleichzeitig lauern Tücken: So kann das Chat‑Model numerische Variablen wie eine Agent ID fälschlicherweise runden oder sehr grosse API‑Antworten unvollständig zurückliefern, was zu unerwarteten Fehlern führt. Nicht zuletzt stellt sich die Frage der Datenhoheit: Es muss genau geklärt werden, welche Daten zwischen Chat‑Model, Tools und PostgreSQL‑Memory fliessen und ob bzw. wie diese Informationen zur Modell‑Weiterentwicklung (Training) verwendet werden, um Compliance‑ und Datenschutzanforderungen vollständig zu erfüllen.
