Was Agentic SOC für uns bedeutet
Unsere Agenten
im Detail
Wer über Agenten im SOC oder über Agentic SOC spricht, sollte auch benennen können, was genau in "agentic" steckt. Deshalb gehen wir mit gutem Beispiel voran und geben Einblicke, welche Agenten bei uns arbeiten und wo für jeden die Grenze verläuft. Die Agenten übernehmen bei uns verschiedene Aufgaben in den Bereichen Trage & Reaktion, Detection Engineering, Log-Onboarding und Automatisierungsprozessen. Sie bereiten vor, kontrollieren, prüfen und bringen Geprüftes in den Betrieb. Ein Prinzip gilt für alle drei Rollen: Entschieden wird von einem Menschen. suresecure ist immer on- bzw- in-the-loop.
Entscheidend ist die Freigabekette
Warum wir jeden Agenten
beim Namen nennen können
Weil jeder eine Rolle, eine Grenze und eine Instanz hat, die ihn anhalten kann. Wer baut, darf nicht ausliefern. Wer prüft, darf nicht bauen. Wer ausliefert, wartet auf einen Menschen. Am Ende jeder Kette steht dokumentiertes Review, namentliche Freigabe und versionierte Ablage — auf Anforderung belegbar.
Das ist kein Marketingversprechen, sondern die Bedingung dafür, dass wir agentisch arbeiten dürfen. Der EU AI Act verlangt seit August 2026 wirksame menschliche Aufsicht über KI in kritischen Abläufen. Wer sie nachträglich um eine fertige Automatisierung herumbaut, bekommt sie nicht mehr sauber hin.
01: Agentenbasierte Triage & Reaktion
Der Alarm ist schon bewertet,
wenn der Analyst ihn öffnet
Im Bereich Triage & Reaktion reichern unsere Agenten an, korrelieren und bewerten vor und das rund um die Uhr. Dadurch kommt ein möglicher Vorfall bzw. kritischer Alert bereit entscheidungsreif beim Analysten an. Genau deshalb können wir Reaktionszeiten zusagen statt anstreben: 60 Minuten bei Critical, 120 bei High. Hier ein paar Beispiele für Agenten, wie wir sie einsetzen.
Der Researcher
Sucht Lücken in der Automatisierung und liefert fertige Bauaufträge.
Der Architekt
Prüft vor dem Bau auf Dubletten, bekannte Fehlermuster und Zuschnitt. Entscheiden darf er nicht.
Der Playbook-Builder
Schreibt den Reaktionsablauf: Schritte, Verzweigungen, Aktionen. Diese sind dann theoretisch sofort importfertig.
Der Playbook-Reviewer
Prüft den fertigen Ablauf gegen unseren Konventionskatalog. Dieser ist dann entweder bestanden oder nicht bestanden. Bei letzterem wird nachgebessert.
Der Flow-Analyst
Schaut mit Analystenaugen drauf: Hat jede eingreifende Aktion ein manuelles Tor? Sind Massenaktionen sicher?
Der Doc-Writer
Schreibt die Dokumentation zu jedem Ablauf. Kein undokumentierter Automatismus und damit vollständige Nachvollziehbarkeit über Einzelpersonen hinweg.
02: Agentenbasiertes Detection Engineering
Neue Angriffsvektoren.
Neue Detections.
In der heutigen Zeit gibt es täglich neue Angriffsvektoren und Schwachstellen. Zudem sind digitale Infrastrukturen sehr heterogen und brauchen angepasstes Detection Engineering. Von der neuen Angriffstechnik bis zu produktiven Erkennungsregel dürfen deshalb keine Wochen mehr vergehen. Wir rechnen nur noch in Minuten und Stunden, weil unsere Agents täglich recherchieren und fertige Vorschläge erarbeiten. Jede Regel wurde vor der Erstellung darauf geprüft, ob sie Fehlalarme auslösen würde und das von einem Agenten, der nichts anderes tut als das. Hier ein Auszug unserer Agenten aus dem Bereich Detection Engineering.
Der Threat-Researcher
Wertet Bedrohungsquellen aus, verifiziert Indikatoren live und sortiert vor, was eine Regel wert ist. Und das rund um die Uhr.
Der Detection-Architect
Prüft vor dem Bau, ob die Erkennung schon existiert und ob die Felder zu den echten Logs passen. Eine Regel auf dem falschen Feld läuft sauber durch und feuert nie.
Der Rule-Reviewer
Technische Qualitätsprüfung jeder Regel gegen einen festen Katalog. Klares Urteil, kein „sieht gut aus“.
Der GitLab-Ops
Übernimmt die Auslieferung mit Vorgang, Branch und Review, aber erst nach ausdrücklicher Bestätigung. Bei jedem Fehler: Stopp und Rückfrage.
Der Playbook-Publisher
Veröffentlicht die Dokumentation revisionssicher, ohne Reviewer-Stände zu überschreiben. Auch hier: Erst nach Freigabe durch einen Securian.
Der FP-Analyst
Prüft ausschließlich: Würde diese Regel Fehlalarme produzieren? Läuft immer parallel zum Reviewer, nie danach.
04: Agentenbasierte Betriebsautomatisierung
Automatisierung, die selbst
durch eine Prüfung muss
Hier sitzt der Agent, der prüft, welche Daten an welches Modell gehen dürfen mit Blick auf Speicherdauer, Anbieter und Rechtsordnung. Die Frage, die im Markt fast niemand beantwortet, hat bei uns eine eigene Instanz. Denn Datenschutz und Mitbestimmung sind unter Berücksichtigung des EU AI-Acts keine optionalen Bausteine, sondern sind verpflichtend einzuhalten. Hier drei Beispiele für Agenten im Bereich Automatisierung.
Der Solution-Architect
Bewertet skeptisch, welche Automatisierung sich lohnt und sagt ausdrücklich, was nicht gebaut werden sollte. Jeder Vorschlag muss sich gegen Datenschutz und Mitbestimmung rechtfertigen.
Der Workflow-Auditor
Sicherheitsprüfung vor jedem Ausrollen: unfertige Platzhalter, hartkodierte Zugangsdaten, fehlende Fehlerbehandlung.
Der Runtime-Risk-Analyst
Führt den Ablauf mit Testdaten tatsächlich aus, statt ihn nur zu lesen. Sucht Doppelversand und umgangene Sicherheitstore. Läuft parallel zum Auditor.
Agentic SOC POV Daten & Fakten
Agentic SOC
Proof of Value
- Onboarding in wenigen Stunden
- 24x7 Monitoring der angebundenen Quellen
- Ganzes SOC-Team + Agenten sofort für euch im Einsatz
- Integriertes Incident Response
Agentic SOC
Agentic SOC POV Factsheet