Agentic SRE: Wie KI-Agenten Infrastruktur selbst heilen, bevor der Mensch es merkt

Seit Jahren verspricht die Branche „selbstheilende Infrastruktur", und seit Jahren bedeutete das in der Praxis meist: ein Alarm feuert, ein Dashboard korreliert drei Metriken, und ein Mensch bekommt einen Vorschlag, welches Runbook er ausführen soll. 2026 hat sich daran etwas Grundsätzliches geändert. Agentic SRE beschreibt keinen neuen Alarmierungsmechanismus, sondern eine Verschiebung der Verantwortung: Der Agent übernimmt nicht nur die Diagnose, sondern das Ergebnis. Er beobachtet, er urteilt, er handelt – und er prüft hinterher nach, ob sein Handeln tatsächlich gewirkt hat. Genau diese letzte Prüfschleife ist der Unterschied zwischen einem cleveren Skript und einem Agenten, dem man einen Produktions-Incident anvertraut.

Dieser Beitrag ordnet ein, was an Agentic SRE 2026 tatsächlich neu ist, was es technisch bedeutet, welche Grenzen es hat – und warum ausgerechnet ein Backup-Anbieter mit „Agent Resilience" gerade die nächste Angriffsfläche adressiert: den Agenten selbst.

Was ist Agentic SRE? Definition und Abgrenzung zu klassischem AIOps

Site Reliability Engineering (SRE) ist als Disziplin nicht neu – Google prägte den Begriff vor über zwei Jahrzehnten als ingenieursmäßige Antwort auf die Frage, wie man Verfügbarkeit systematisch statt heroisch sicherstellt. Was 2026 dazukommt, ist die Rolle des Agenten als aktiv handelnde Instanz statt als reines Analysewerkzeug. Fachbeiträge zu Agentic AI im Ops-Kontext beschreiben das konsistent: Agenten übernehmen Verantwortung für das Reliability-Ergebnis, analysieren kontinuierlich den Systemzustand, führen Remediationen aus und verifizieren die Ergebnisse – nicht als einmaliger Vorschlag, sondern als geschlossener, wiederholbarer Regelkreis.

Dieser Regelkreis lässt sich in vier Schritten beschreiben, die im Titelbild dieses Beitrags als Kreislauf um ein zentrales Server-Icon angeordnet sind:

1. Telemetrie lesen. Der Agent zieht kontinuierlich Logs, Metriken und Traces aus dem Observability-Stack – nicht auf Zuruf, sondern als Daueraufgabe im Hintergrund.
2. Kausal-Hypothese aufstellen. Aus Mustern in diesen Daten leitet der Agent eine wahrscheinliche Ursache ab – nicht nur eine Korrelation, sondern eine testbare Annahme darüber, warum ein System vom Soll-Zustand abweicht.
3. Remediation ausführen. Der Agent wählt aus einem vordefinierten Aktions-Katalog die passende Maßnahme und führt sie selbst aus – innerhalb der Grenzen, die ihm zuvor gesetzt wurden.
4. Ergebnis verifizieren. Der Agent prüft, ob die Kennzahl, die den Incident ausgelöst hat, wieder im Soll-Bereich liegt. Erst dieser Schritt schließt die Schleife.

Zur Einordnung hilft die Abgrenzung nach unten und nach oben. Nach unten steht die klassische Runbook-Automatisierung: starre Wenn-Dann-Skripte, die auf einen bekannten Alarmtyp reflexartig reagieren, ohne den Kontext zu bewerten. Sie sind schnell, aber blind – ein Skript, das bei hoher CPU-Last automatisch neu startet, tut das auch dann, wenn der eigentliche Fehler ein Speicherleck in einer ganz anderen Komponente ist. Nach oben steht klassisches AIOps: Es korreliert Alarme, reduziert Rauschen und schlägt Menschen priorisierte Handlungsoptionen vor – bleibt aber bei der Diagnose stehen. Der Mensch drückt den Knopf. Agentic SRE besetzt den Raum dazwischen und darüber hinaus: kontextsensitiver als das Runbook, aber im definierten Rahmen handlungsfähig statt nur beratend wie klassisches AIOps.

Wichtig für die Erwartungshaltung: Menschen bleiben in dieser Architektur nicht überflüssig, sie rücken nur eine Ebene höher. Sie definieren die Policy, die Guardrails und die Business-Intent – also was überhaupt als „gesund" gilt und wie weit ein Agent gehen darf. Der Agent führt aus, was innerhalb dieses Rahmens liegt. Diese Arbeitsteilung ist der eigentliche Kern von Agentic SRE, nicht die Automatisierung als solche.

Der Aktions-Katalog: Was ein SRE-Agent tun darf

Der handlungsfähige Teil von Agentic SRE steht und fällt mit der Frage, wie eng oder weit der Aktions-Katalog gefasst ist. In der Praxis hat sich 2026 ein Kern von sieben Aktionstypen als branchentypisch herausgebildet, die sich in ihrer Reichweite deutlich unterscheiden:

Aktion	Typischer Trigger	Blast Radius	Rollback-Pfad
Neustart / Cache-Flush	Speicherleck, veralteter Cache-Eintrag	gering	trivial (Zustand war zustandslos)
Replica-Scale	Lastspitze, Warteschlangenaufbau	gering	Skalierungsfaktor zurücksetzen
Traffic-Shift	Fehlerrate in einer Zone/Version steigt	mittel	Routing-Gewicht zurückdrehen
Rollback (Deployment)	Fehlerrate nach Release steigt	mittel	Vorgängerversion, getestet
Zertifikatserneuerung	TLS-Ablaufwarnung	gering	altes Zertifikat kurzzeitig vorhalten
IAM-Rotation	verdächtige Zugriffsmuster, Schlüsselalter	hoch	Freigabe empfohlen
Konfigurationsänderung Kern-Service	wiederkehrender Timeout-Cluster	hoch	Freigabe erforderlich

Die ersten fünf Zeilen dieser Tabelle sind Kandidaten für vollautonome Ausführung, weil ihr Blast Radius begrenzt und ihr Rollback nahezu verlustfrei ist. Die letzten beiden – IAM-Rotation und Änderungen an Kern-Konfigurationen – gehören für die meisten Betriebe eher in eine Freigabeschleife, zumindest in der Einführungsphase. Genau diese Grenze beschreibt der Begriff, der sich in der Praxis als informelle Fachbezeichnung durchgesetzt hat: die Policy Envelope. Das ist ausdrücklich eine Einordnung aus der Betriebspraxis und keine feststehende Norm oder ein wörtliches Zitat einer bestimmten Quelle – gemeint ist schlicht der Handlungsrahmen, innerhalb dessen ein Agent autonom eingreifen darf, während alles außerhalb dieses Rahmens eine menschliche Freigabe durchläuft.

Der zentrale Sicherheitsmechanismus innerhalb dieser Envelope ist nicht die Auswahl der richtigen Aktion, sondern die Fähigkeit, eine falsche Aktion rückgängig zu machen. Automatisches Rollback ist deshalb kein optionales Feature, sondern die Voraussetzung dafür, dass man einem Agenten überhaupt Handlungsspielraum einräumen kann: Verschlechtert sich die Lage nach einer Remediation, oder bleibt die Zielmetrik außerhalb des Soll-Bereichs, macht der Agent seine eigene Änderung rückgängig, statt auf eigene Faust weiterzueskalieren oder eine zweite, unabgestimmte Maßnahme obendrauf zu setzen. Das ist der entscheidende Unterschied zu einem Skript ohne Rückwärtsgang.

Cohesity Agent Resilience: Wenn die Agenten-Infrastruktur selbst zum Schutzobjekt wird

Am 16. September 2026 kündigte Cohesity auf seiner Catalyst-Konferenz eine Funktion namens „Agent Resilience" an. Das Datum ist an dieser Stelle keine Nebensächlichkeit: Vereinzelt kursiert in der Berichterstattung der 17. September, weil eine Sekundärmeldung an diesem Tag erschien – die offizielle Cohesity-Pressemitteilung und die Berichterstattung von SiliconANGLE datieren die Ankündigung selbst jedoch übereinstimmend auf den 16. September, den ersten Konferenztag.

Inhaltlich ist die Idee hinter „Agent Resilience" ein logischer, aber bisher übersehener nächster Schritt. Backup- und Recovery-Anbieter haben jahrzehntelange Erfahrung darin, Daten vor Verlust, Korruption und Manipulation zu schützen. Was in der aktuellen Agenten-Welle fehlte, war der gleiche Schutz für den Zustand des Agenten selbst – sein Gedächtnis, seine Konfiguration, seine Berechtigungen. Genau das adressiert die neue Funktion:

• Snapshot-Architektur für Agenten-Gedächtnis und -Konfiguration – derselbe Mechanismus, der bislang Datenbanken und virtuelle Maschinen sichert, wird auf den internen Zustand von KI-Agenten angewendet.
• Unveränderliche Backups, die verhindern, dass ein kompromittierter oder fehlkonfigurierter Agent seine eigene Sicherungshistorie überschreibt.
• Clean-Room-Recovery zur isolierten Wiederherstellung, ohne den möglicherweise noch aktiven Fehlerzustand erneut zu importieren.
• Point-in-Time-Recovery für drei konkrete Schadensbilder: Speicher- bzw. Memory-Korruption, Fehlkonfiguration und Missbrauch (etwa durch kompromittierte Zugangsdaten oder Prompt-Injection-Angriffe auf den Agenten).

Der Rollout ist bewusst konservativ angelegt: Cohesity startet mit Unterstützung für Amazon Bedrock, allgemeine Verfügbarkeit ist erst für Ende 2026 geplant, aktuell ist die Funktion ausgewählten Kunden vorbehalten. Microsoft- und Google-Integrationen stehen auf der Roadmap, sind aber noch nicht verfügbar.

Merkmal	Stand September 2026
Ankündigungsdatum	16. September 2026, Cohesity-Catalyst-Konferenz
Geschützt wird	Agenten-Gedächtnis und -Konfiguration, nicht primär die Server, die der Agent verwaltet
Schadensbilder	Memory-Korruption, Fehlkonfiguration, Missbrauch
Plattform-Support beim Start	Amazon Bedrock
Verfügbarkeit	ausgewählte Kunden jetzt, GA für Ende 2026 geplant; Microsoft/Google auf Roadmap

Die Einordnung, die für Betreiber zählt, ist unabhängig vom konkreten Anbieter: Sobald ein Agent Schreibrechte auf produktive Systeme hat, wird sein eigener Zustand zu einer neuen Angriffs- und Ausfallfläche. Ein manipuliertes Agenten-Gedächtnis kann dazu führen, dass ein an sich korrekt gebauter Aktions-Katalog plötzlich falsch angewendet wird – nicht weil die Policy Envelope fehlerhaft ist, sondern weil die Instanz, die sie auswertet, kompromittiert wurde. Wer mehrere Agenten im Verbund betreibt, vervielfacht dieses Risiko: Ein korrumpierter Agent kann über Agent-Orchestrierung Fehlentscheidungen an andere Agenten weiterreichen, bevor ein Mensch eingreift.

Architektur: Wie Agenten Telemetrie lesen und Kausalität ableiten

Technisch stützt sich Agentic SRE auf denselben Observability-Stack, den Betriebsteams seit Jahren aufbauen: strukturierte Logs, Zeitreihenmetriken und verteilte Traces. Neu ist nicht die Datenquelle, sondern wie ein sprachmodellgestützter Agent diese Daten interpretiert. Statt fester Schwellenwerte und starrer Korrelationsregeln bildet der Agent eine Hypothese in natürlicher Sprache über die zugrunde liegende Ursache – etwa: „Die Latenzspitze im Checkout-Service korreliert zeitlich mit einem Deployment vor neun Minuten und einem Anstieg der Datenbank-Verbindungswartezeit; wahrscheinlichste Ursache ist ein neuer, ungeprüfter Datenbank-Query in der aktuellen Version."

Der entscheidende Unterschied zur reinen Korrelation liegt darin, dass eine Kausal-Hypothese testbar ist. Der Agent kann gezielt nachprüfen: Existiert der vermutete Query? Zeigt ein Rollback des Deployments die erwartete Wirkung? Diese Testbarkeit ist zugleich die wichtigste Fehlerquelle, denn Sprachmodelle sind grundsätzlich anfällig dafür, plausibel klingende, aber falsche Kausalzusammenhänge zu konstruieren – ein Halluzinationsrisiko, das bei reiner Textgenerierung ärgerlich, bei automatisierten Eingriffen in Produktionssysteme aber teuer werden kann.

Zwei Bausteine reduzieren dieses Risiko in der Praxis. Erstens: Anomalieerkennung als vorgelagerter, statistisch abgesicherter Filter, der dem Agenten überhaupt erst signalisiert, dass eine Abweichung vom Normalzustand vorliegt, bevor er eine Hypothese formuliert. Zweitens: historische Incident-Daten als Kontext, häufig über einen Retrieval-Mechanismus oder einen Wissensgraphen eingebunden, der frühere, bereits verifizierte Ursache-Wirkungs-Ketten für ähnliche Symptommuster bereitstellt. Ein Agent, der auf zweihundert dokumentierte Vorfälle der letzten zwei Jahre zugreifen kann, muss seine Hypothese nicht aus dem Nichts konstruieren, sondern kann sie gegen bekannte Muster abgleichen.

Trotzdem bleibt der Verifikationsschritt unverzichtbar, gerade weil die Hypothesenbildung fehleranfällig ist. Ein Agent, der handelt, ohne hinterher zu prüfen, ob die Zielmetrik tatsächlich wieder im Soll-Bereich liegt, hat aus einer plausiblen Vermutung eine unbestätigte Tatsachenbehauptung gemacht – mit einem produktiven System als Testfeld.

Risiken und Grenzen: Kaskadeneffekte, Fehlalarme, Vertrauen

Die kritische Frage, die jede Einführung von Agentic SRE beantworten muss, lautet nicht „Was, wenn der Agent nichts findet?", sondern „Was, wenn seine Kausal-Hypothese falsch ist und er trotzdem handelt?". Genau hier entstehen die Fälle, die in der Branche als abschreckende Beispiele kursieren: ein Agent interpretiert eine kurzfristige, harmlose Lastspitze als Anzeichen eines Speicherlecks, skaliert aggressiv, verschiebt dadurch Datenbankverbindungen in einen Engpass und löst damit den eigentlichen Vorfall erst aus. Die Fehlremediation kaskadiert, weil die erste automatisierte Reaktion neue Symptome erzeugt, die der Agent wiederum als eigenständiges Problem interpretiert.

Dieses Beispiel zeigt, warum ein enger Aktions-Katalog, eine strikte Policy Envelope und lückenlose Audit-Logs keine bürokratische Pflichtübung sind, sondern das Sicherheitsnetz, das eine falsche Kausal-Hypothese von einem folgenlosen Fehlversuch zu einem kaskadierenden Ausfall unterscheidet. Ohne Rollback-Fähigkeit wäre im zweiten Fall wahrscheinlich eine dritte, noch aggressivere Aktion gefolgt – mit entsprechend größerem Blast Radius.

Ein zweites, subtileres Risiko betrifft das Vertrauen der Betriebsteams selbst. Ein Agent, der in den ersten Wochen zu oft falsch liegt, wird von den Menschen, die eigentlich entlastet werden sollen, schnell wieder deaktiviert oder umgangen – und ein Agent, der zu selten eingreift, weil die Policy Envelope zu eng gefasst wurde, bringt keinen messbaren Nutzen. Die richtige Kalibrierung zwischen beiden Polen ist ein iterativer Prozess, kein einmaliges Setup.

Warum Agentic SRE On-Premise und Data Residency neu bewertet

Agentic SRE verarbeitet naturgemäß hochsensible Betriebsdaten: Systemarchitektur, interne Hostnamen, Zugriffsmuster, teils auch Ausschnitte aus Anwendungsdaten in Logs. Wird die Analyse über eine Cloud-AIOps-SaaS-Lösung durchgeführt, verlassen diese Daten die eigene Infrastruktur – mit allen Fragen, die das für Auftragsverarbeitung, Subunternehmer-Ketten und Datenübermittlung in Drittländer aufwirft. Bei On-Premise- oder air-gapped betriebenen SRE-Agenten stellt sich diese Frage nicht in derselben Schärfe: Telemetrie- und Betriebsdaten bleiben in der eigenen Infrastruktur, und die Nachvollziehbarkeit jeder einzelnen Agenten-Aktion lässt sich lückenlos im eigenen Haus dokumentieren.

Für sicherheitskritische Systeme – etwa in der Fertigung, im Gesundheitswesen oder überall dort, wo Betriebsgeheimnisse in der Infrastruktur-Topologie selbst stecken – ist das kein Nice-to-have, sondern ein Ausschlusskriterium für bestimmte Cloud-Angebote. Hinzu kommt der regulatorische Aspekt: Für Compliance-Anforderungen wie den EU AI Act oder die DSGVO ist es strukturell einfacher, Nachvollziehbarkeit und Datenverbleib zu belegen, wenn die gesamte Verarbeitungskette im eigenen Rechenzentrum liegt, statt sie über mehrere Cloud-Dienstleister und deren jeweilige Subunternehmer zu rekonstruieren.

Auch die Berechtigungsarchitektur profitiert von einer On-Premise-Betrachtung nach Zero-Trust-Prinzipien: Ein SRE-Agent, der IAM-Zugangsdaten rotieren oder Zertifikate erneuern darf, braucht selbst ein eng geschnittenes, kurzlebiges Berechtigungsprofil statt eines dauerhaften Administrator-Zugangs. Jede der im Aktions-Katalog beschriebenen Fähigkeiten sollte an ein eigenes, minimal berechtigtes Service-Konto gebunden sein – nicht an einen einzigen, allmächtigen Agenten-Account, der im Kompromittierungsfall die gesamte Policy Envelope aushebelt.

Praxis-Fahrplan für den Mittelstand: Einstieg in Agentic SRE

Der verbreitetste Fehler bei der Einführung ist die Erwartung, gleich am ersten Tag einen „Vollautomaten" zu bekommen, der Nachtschichten überflüssig macht. Realistischer und tragfähiger ist ein Einstieg in vier Stufen:

1. Engen Aktions-Katalog definieren. Beginnen Sie mit drei bis fünf Aktionen aus der oberen Hälfte der Tabelle weiter oben – Neustart, Cache-Flush, Replica-Scale –, deren Blast Radius gering und deren Rollback nahezu risikofrei ist. Ein Agent, der ausschließlich diese Aktionen ausführen darf, kann schon in der ersten Woche produktiven Nutzen liefern, ohne existenzielle Risiken einzugehen.
2. Human-in-the-loop für alles außerhalb der Policy Envelope. Jede Aktion, die nicht im engen Katalog steht, generiert einen priorisierten Vorschlag statt einer automatischen Ausführung. Das ist im Kern der klassische AIOps-Modus als Fallback – bewusst gewählt, nicht als Notlösung, sondern als Sicherheitsstufe.
3. Guardrails und Audit-Log von Anfang an mitbauen. Jede Aktion, jede Hypothese und jedes Verifikationsergebnis gehört lückenlos protokolliert, bevor der erste produktive Einsatz stattfindet – nicht nachträglich draufgesetzt. Guardrails definieren dabei nicht nur, was technisch möglich ist, sondern was organisatorisch erlaubt ist.
4. Autonomie schrittweise ausweiten, nach belegtem Vertrauen. Erst wenn über einen definierten Zeitraum – etwa acht bis zwölf Wochen – die Trefferquote der Hypothesen und die Wirksamkeit der Remediation dokumentiert und stabil sind, wird der Aktions-Katalog um die nächste Stufe erweitert.

Diese Reihenfolge ist bewusst konservativ, weil sie Vertrauen als knappe Ressource behandelt, nicht als Standardannahme. Ein Unternehmen, das nach drei Monaten fünf statt zwei Aktionstypen autonom laufen lässt, hat mehr erreicht als eines, das am ersten Tag zwanzig Aktionen freigeschaltet und nach dem ersten Fehlgriff das gesamte Projekt gestoppt hat.

Ausblick: Hardware, Kostenkurve und wirtschaftliche Reife

Ein Faktor, der bislang unterschätzt wird, ist die Hardware-Ökonomie hinter reasoning-intensiven Agenten. Jede Kausal-Hypothese, die ein SRE-Agent bildet, erfordert mehrstufiges Schlussfolgern über mehrere Telemetriequellen hinweg – deutlich rechenintensiver als eine einfache Klassifikationsaufgabe. Laut Einschätzung von Unite.AI machen Hardware-Durchbrüche wie NVIDIAs kommende Rubin-Architektur genau diese Klasse von Agenten erst im großen, unternehmensweiten Maßstab wirtschaftlich rentabel: mehr Tokens pro Watt und niedrigere Kosten pro Token gegenüber der aktuellen Blackwell-Generation, jeweils nach Angaben von NVIDIA selbst.

Diese Einordnung sollte allerdings nicht überzeichnet werden: Hardware-Fortschritt ist ein Enabler, kein alleiniger Treiber. Die eigentliche Flaschenhalsgröße bleibt, wie das vorangegangene Kapitel zu den Risiken gezeigt hat, die Reife der Policy-Definitionen und das Vertrauen, das Betriebsteams einem Agenten schrittweise entgegenbringen. Günstigere, schnellere Inferenz macht mehr Agenten-Läufe pro Incident möglich – etwa mehrere parallel geprüfte Hypothesen statt einer einzigen –, ersetzt aber nicht die organisatorische Arbeit, einen sauberen Aktions-Katalog und belastbare Verifikationskriterien zu definieren. Wer 2027 auf günstigere Reasoning-Hardware wartet, um Agentic SRE einzuführen, verschiebt damit nicht die technische, sondern die organisatorische Hausaufgabe.

Fazit: Was Unternehmen jetzt konkret tun sollten

Agentic SRE ist 2026 kein Forschungsthema mehr, sondern eine Betriebsentscheidung mit klaren Leitplanken: Ein Agent liest Telemetrie, bildet eine testbare Kausal-Hypothese, handelt innerhalb einer eng definierten Policy Envelope und verifiziert das Ergebnis – mit automatischem Rollback als Rückgrat der gesamten Konstruktion. Cohesitys „Agent Resilience" zeigt zugleich, dass mit wachsender Handlungsmacht der Agenten auch deren eigener Zustand zu einem schützenswerten Gut wird, nicht nur die Systeme, die sie reparieren.

Für die konkrete Umsetzung im eigenen Haus lassen sich daraus fünf Handlungsempfehlungen ableiten:

• Definieren Sie zuerst die Policy Envelope, nicht die Technik. Welche drei bis fünf Aktionen darf ein Agent autonom ausführen, und wer legt das fest?
• Testen Sie die Rollback-Fähigkeit systematisch, bevor der erste produktive Einsatz stattfindet – nicht erst, wenn sie im Ernstfall gebraucht wird.
• Sichern Sie die Agenten-Infrastruktur selbst ab, mit Snapshot- und Recovery-Mechanismen für Gedächtnis, Konfiguration und Berechtigungen des Agenten, nicht nur für die von ihm verwalteten Systeme.
• Prüfen Sie On-Premise als Compliance-Hebel, insbesondere wenn Betriebsdaten und Infrastruktur-Topologie sensibel sind oder regulatorische Nachvollziehbarkeit gefordert ist.
• Bauen Sie Vertrauen stufenweise auf, mit dokumentierter Trefferquote und Wirksamkeit, statt Autonomie am ersten Tag zu maximieren.

Wer diese fünf Punkte im eigenen Betrieb durchdenkt, hat den wesentlichen Teil der Arbeit bereits geleistet – die Technik dahinter ist inzwischen verfügbar, ausgereift und, wie die Rubin-Prognose zeigt, absehbar auch wirtschaftlicher. Wie ein solcher Aktions-Katalog, eine Policy Envelope und die passende Guardrail-Architektur für Ihre konkrete Infrastruktur aussehen sollten, klären wir gerne in einem unverbindlichen Gespräch.

Quellen & Primärbelege

Alle Zahlen, Daten und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primärquellen geprüft.

1. Unite.AI: Agentic SRE 2026 Existiert und passt inhaltlich zur Definition (Reliability-Outcomes, Rubin-Hardware-Aussage). Verwendbar wie angegeben.
2. Cohesity Newsroom: Agent Resilience Pressemitteilung Primärquelle für das korrekte Ankündigungsdatum (16.9.2026) und alle Produktdetails (Bedrock-Support, GA Ende 2026, Snapshot/Clean-Room-Recovery).
3. SiliconANGLE: Cohesity Agent Resilience (16.9.2026) Untermauert das korrekte Datum 16. September 2026.
4. Security MEA: Cohesity Agent Resilience Inhaltlich konsistent zur Produktbeschreibung; das Veröffentlichungsdatum (17.9.) ist Sekundärberichterstattung, nicht das Ankündigungsdatum.
5. eCanarys: Agentic AI in IT Operations Existiert, inhaltlich passend zu Selbstheilungs- und Remediation-Konzepten.
6. NovaAIOps: Self-Healing Infrastructure Unterscheidet nützlich zwischen Runbooks, Basis-Automatisierung und Agentic Remediation.

Häufig gestellte Fragen zu Agentic SRE

Was bedeutet "Agentic SRE" genau – reicht das nicht schon Standard-AIOps?

Klassisches AIOps korreliert Alarme und schlägt Menschen Runbooks vor. Bei Agentic SRE übernimmt der Agent selbst Verantwortung für das Reliability-Ergebnis: Er liest Telemetrie (Logs, Metriken, Traces), bildet eine Kausal-Hypothese für die Störungsursache, führt die passende Remediation aus (z. B. Neustart, Cache-Flush, Traffic-Shift) und verifiziert anschließend, ob das System tatsächlich wieder im Soll-Zustand ist. Der Unterschied ist die geschlossene Schleife inklusive Handlung und Verifikation, nicht nur die Diagnose.

Was ist eine "Policy Envelope" und warum braucht jeder Agent automatisches Rollback?

Die Policy Envelope ist der eng definierte Handlungsrahmen, innerhalb dessen ein Agent autonom eingreifen darf – etwa Rollback, Neustart, IAM-Rotation, Zertifikatserneuerung, Cache-Flush, Replica-Scale oder Traffic-Shift. Jede Aktion außerhalb dieses Rahmens erfordert menschliche Freigabe. Automatisches Rollback ist der zentrale Sicherheitsmechanismus: Schlägt eine Remediation fehl oder verschlechtert sie die Lage, macht der Agent seine eigene Änderung rückgängig, statt weiterzueskalieren.

Warum schützt Cohesity jetzt plötzlich die Agenten-Infrastruktur selbst?

Cohesity hat am 16. September 2026 auf der Catalyst-Konferenz "Agent Resilience" vorgestellt: eine Funktion, die Agenten-Gedächtnis und -Konfiguration mit derselben Snapshot-Architektur, unveränderlichen Backups und Clean-Room-Recovery schützt, die bislang für Daten-Workloads galt. Der Gedanke dahinter: Wenn Agenten selbst Server reparieren dürfen, wird ihr eigener Zustand – Speicher, Konfiguration, Berechtigungen – zu einem neuen Angriffs- und Ausfallpunkt, der genauso wiederherstellbar sein muss wie die Systeme, die sie warten. Der Start erfolgt mit Unterstützung für Amazon Bedrock, allgemeine Verfügbarkeit ist für Ende 2026 geplant.

Können mittelständische Unternehmen Agentic SRE schon on-premise einsetzen?

Ja, allerdings schrittweise: Der sinnvolle Einstieg ist ein enger Aktions-Katalog mit Human-in-the-loop-Freigabe für alles außerhalb einer engen Policy Envelope, kombiniert mit Guardrails und lückenlosem Audit-Log. On-Premise- bzw. Air-Gapped-Betrieb ist hier besonders relevant, weil Telemetrie- und Betriebsdaten die eigene Infrastruktur nicht verlassen müssen und die Nachvollziehbarkeit jeder Agenten-Aktion für Compliance-Zwecke (z. B. EU AI Act) leichter sichergestellt werden kann.