KI-Agenten sind keine Chatfenster mehr, die auf eine Frage warten. Sie lesen Tickets, legen Dateien an, rufen Schnittstellen auf, starten Builds und arbeiten dabei oft über mehrere Systeme hinweg. Genau diese Selbstständigkeit macht sie nützlich – und genau sie wirft die Frage auf, wie ein Unternehmen einen solchen Prozess im Zweifel wieder anhält.

Der Sicherheitsanbieter Crowdstrike hat dazu ein Werkzeug angekündigt, das als Not-Aus für KI-Agenten im Firmennetz gedacht ist. Administratoren sollen damit laufende Agenten stoppen und verhindern können, dass diese sich einfach wieder starten. Technisch ist das ein kleiner Baustein, inhaltlich ein deutliches Signal: Autonomie braucht eine Gegenkraft.

Warum ein Stopp-Knopf schwieriger ist, als er klingt

Bei einer klassischen Anwendung ist die Sache einfach: Prozess beenden, Dienst deaktivieren, fertig. Bei Agenten liegt der Fall anders. Ein Agent ist in der Regel kein einzelner Prozess, sondern ein Zusammenspiel aus einem Sprachmodell, einer Ablaufsteuerung, Zugangsdaten und einer Reihe von Werkzeugen – also Schnittstellen, über die der Agent in anderen Systemen tatsächlich etwas verändert.

Daraus ergeben sich mehrere praktische Probleme. Erstens läuft ein Agent häufig nicht dort, wo er wirkt: Die Steuerung kann in einer Cloud-Umgebung liegen, die Auswirkungen treffen interne Systeme. Zweitens sind viele Agenten so gebaut, dass sie sich bei Abbruch neu anstoßen – über Scheduler, Watchdogs oder Warteschlangen. Ein beendeter Lauf ist dann kein gestoppter Agent, sondern ein kurz unterbrochener. Genau an diesem Punkt setzt die Idee an, den Neustart aktiv zu blockieren.

Drittens hinterlässt ein abgebrochener Agent einen halbfertigen Zustand: ein angelegter Datensatz ohne Gegenbuchung, ein geöffneter Pull Request ohne Beschreibung, eine begonnene Migration. Ein Not-Aus beendet die Aktivität, er macht sie nicht rückgängig.

Vier Ebenen der Kontrolle

Sinnvoll ist es, Kontrolle nicht als einen einzelnen Schalter zu denken, sondern als gestufte Kette. In Projekten lassen sich vier Ebenen unterscheiden:

  • Identität: Jeder Agent braucht eine eigene technische Identität, nicht den Zugang eines Mitarbeiters oder einen geteilten Sammelaccount. Nur so lässt sich sein Handeln überhaupt einzeln nachvollziehen und entziehen.
  • Berechtigung: Rechte werden auf das zugeschnitten, was der konkrete Anwendungsfall braucht. Ein Agent, der Rechnungen vorerfasst, braucht keinen Schreibzugriff auf das Benutzerverzeichnis.
  • Beobachtbarkeit: Jeder Werkzeugaufruf wird protokolliert – wer, wann, mit welchen Parametern, mit welchem Ergebnis. Ohne diese Spur ist weder eine Fehlersuche noch eine saubere Nachbereitung möglich.
  • Abschaltung: Ein definierter Weg, den Agenten zu stoppen, und ein zweiter, ihn am Wiederanlauf zu hindern. Beides muss auch dann funktionieren, wenn die Person, die den Agenten eingerichtet hat, gerade nicht erreichbar ist.

Die ersten drei Ebenen sind klassische Themen der IT-Sicherheit. Neu ist vor allem, dass sie jetzt auf Akteure angewandt werden müssen, die eigenständig Entscheidungen treffen und deren Verhalten nicht vollständig vorhersehbar ist.

Wer darf den Stecker ziehen?

Ein Not-Aus ist nur so gut wie die Organisation dahinter. In der Praxis stellen sich drei Fragen, die vor dem ersten produktiven Agenten geklärt sein sollten.

Wer entscheidet? Es braucht benannte Personen, die einen Agenten ohne Rückfrage abschalten dürfen – und die wissen, dass sie das dürfen. Wenn die Abschaltung erst eine Freigabekette durchlaufen muss, ist sie in einem echten Zwischenfall wertlos.

Woran erkennt man den Fall? Ein Agent, der Unsinn produziert, fällt oft nicht sofort auf. Hilfreich sind einfache Schwellen: ungewöhnlich viele Schreibzugriffe in kurzer Zeit, Zugriffe auf Systeme außerhalb des üblichen Musters, auffällig lange Laufzeiten. Solche Signale gehören ins Monitoring, nicht in die Erinnerung einzelner Mitarbeiter.

Was passiert danach? Nach dem Stopp beginnt die eigentliche Arbeit: angefangene Vorgänge identifizieren, fehlerhafte Änderungen zurückrollen, betroffene Fachbereiche informieren. Wer diesen Ablauf einmal durchgespielt hat, merkt schnell, welche Protokolle fehlen.

Konsequenzen für die Architektur

Dass ein Abschaltmechanismus nötig ist, hat Rückwirkungen auf den Entwurf von Agentensystemen. Ein Agent, der jede Änderung sofort und endgültig schreibt, ist schwer zu stoppen. Ein Agent, der Entwürfe erzeugt, die ein Mensch oder ein zweiter Prüfschritt freigibt, lässt sich jederzeit anhalten, ohne dass ein inkonsistenter Zustand zurückbleibt.

Ähnliches gilt für die Fehlertoleranz. Automatische Wiederanläufe sind bei klassischen Batch-Jobs sinnvoll, bei Agenten können sie zum Problem werden – nämlich dann, wenn sie einen bewussten Stopp wieder aushebeln. Die Wiederanlauflogik sollte deshalb eine zentrale Sperre respektieren, statt blind neu zu starten.

Und schließlich: Agenten gehören inventarisiert. Viele Unternehmen wissen heute nicht genau, wie viele automatisierte Helfer in Entwicklungsumgebungen, CMS-Instanzen oder Backoffice-Prozessen bereits mitlaufen. Was nicht erfasst ist, lässt sich auch nicht abschalten.

Einordnung

Für Web- und Softwareprojekte verschiebt sich damit ein Stück Verantwortung nach vorn: Die Frage, wie ein Agent gestoppt und sein Zustand bereinigt wird, gehört in die Konzeptphase, nicht in den Betrieb. Konkret heißt das, Agenten mit eigener Identität, eng geschnittenen Rechten und vollständiger Protokollierung aufzusetzen und Abläufe so zu entwerfen, dass ein Abbruch verkraftbar bleibt. Wer diese Grundlagen schafft, kann Automatisierung schrittweise ausweiten, ohne bei jedem neuen Anwendungsfall das Risiko neu verhandeln zu müssen.

Quellen