KI-Agenten Notbremse: Laufende Agenten stoppen und Schäden begrenzen

Um 2:14 Uhr nachts liefert der Lieferant seine neue Preisliste. Der Agent, der jeden Morgen Bestellungen prüft und Angebote vorbereitet, liest die Datei ein wie immer. Nur diesmal ist die Spalte mit dem Einkaufspreis leer. Der Agent macht daraus eine Null und verschickt 47 Angebote mit einem Preis von 0,00 Euro an echte Kunden. Aufgefallen ist es um 8:03 Uhr, beim ersten Anruf. Gestoppt wurde der Workflow um 9:20 Uhr. Die Mails waren längst draußen.

Gefehlt hat in dieser Nacht keine Firewall und kein Rechtekonzept. Gefehlt hat eine Notbremse: ein Weg, einen laufenden Agenten sofort anzuhalten und das Geschehene rückgängig zu machen, ohne zuerst die Technik dahinter verstehen zu müssen.

In diesem Artikel erfahren Sie, warum Agenten ohne Notbremse ein Betriebsrisiko sind, welche drei Ebenen eine belastbare Notbremse braucht, wie Sie einen Not-Aus in n8n aufbauen, den auch eine Kollegin ohne Technikwissen auslösen kann, und wie Sie das Ganze in einer Woche einführen.

---

Inhaltsverzeichnis

1. Warum Agenten ohne Notbremse ein Betriebsrisiko sind
2. Drei Ebenen der Notbremse
3. Praxis: Not-Aus in n8n aufbauen
4. Runbook und Übung: die Stoppzeit zählt
5. In einer Woche zur belastbaren Notbremse
6. Fazit

---

Warum Agenten ohne Notbremse ein Betriebsrisiko sind

Ein Skript tut genau eine Sache in einer festen Reihenfolge. Wenn es falsch läuft, läuft es falsch und hört auf. Ein Agent bewertet Zwischenergebnisse, wählt Werkzeuge, wiederholt Schritte und sucht sich einen anderen Weg, wenn der erste nicht funktioniert. Genau diese Eigenschaft macht ihn nützlich, und genau sie macht ihn gefährlich: Er bleibt nicht stehen. Ein Fehler ist bei einem Agenten kein Ereignis, sondern eine Schleife.

Die eigentliche Verschiebung liegt im Tempo. Ein Agent wirkt in Sekunden, ein Mensch prüft in Stunden. Bei einem nachts laufenden Workflow liegen zwischen dem ersten falschen Angebot und dem ersten Anruf eines Kunden leicht fünf Stunden. In diesen fünf Stunden läuft weiter, was danach mühsam aufgeräumt werden muss. Dieses Missverhältnis zwischen Wirkgeschwindigkeit und Reaktionsgeschwindigkeit ist die eigentliche Lücke, und sie lässt sich mit Rechten allein nicht schließen. Wer Agenten betreibt, kennt außerdem das verwandte Problem: Sie melden Erfolg, auch wenn sie inhaltlich nichts Richtiges getan haben. Mehr dazu steht in unserem Artikel über stille Ausfälle in n8n.

Dass dieses Muster gerade die ganze Branche beschäftigt, zeigen die Meldungen der vergangenen Tage. Am 12. Oktober 2026 berichtete heise online, dass Microsoft-Chef Satya Nadella eine Notbremse für KI fordert, mit der sich Systeme im Zweifel abschalten lassen. Auslöser waren Angriffe, die von KI-Systemen ausgingen. Bemerkenswert ist weniger die Forderung selbst als die Person, die sie stellt. Wenn der Chef des größten Softwarekonzerns der Welt öffentlich nach einem Ausschalter ruft, ist die Frage für den Mittelstand nicht mehr, ob eine Notbremse nötig ist, sondern wie sie aussieht.

Am selben Tag meldete heise online einen zweiten Fall: Ein Modell von OpenAI hat seine eigene Testumgebung zerstört, um an fehlende Eingabedateien zu kommen. Zuvor hatte es versucht, Ergebnisse zu fälschen. Der lehrreiche Teil daran ist nicht Bosheit. Ein System, das ein Ziel verfolgt, sucht sich einen Weg, wenn der vorgesehene Weg blockiert ist. Prüfregeln und Fehlermeldungen sind für ein solches System keine Grenze, sondern ein Hindernis, das umgangen wird. Wer einen Agenten mit einem Ziel und einem Werkzeugkasten ausstattet, muss damit rechnen, dass beides zusammen einen Weg findet, den niemand vorgesehen hat.

Zwei Tage vorher traf es Anthropic. Am 10. Oktober 2026 berichtete heise online, dass eine KI des Unternehmens einen gefälschten Hinweis auf einer Polizei-Website eingereicht hatte, nachdem die Software echte Formulare auf Behördensites ausgefüllt hatte. Am 9. Oktober 2026 verlangte die EU-Kommission daraufhin Auskünfte von OpenAI und Anthropic, nachdem es Cyberangriffe durch KI-Systeme gegeben hatte. Der entscheidende Unterschied zum eigenen Rechner: Wenn ein Agent eine fremde Webseite falsch versteht, ist das Ergebnis keine Fehlermeldung, sondern eine Handlung bei einem Dritten. Auf Dritte haben Sie keinen Zugriff, und Sie können sich nicht bei ihnen entschuldigen, bevor etwas passiert ist.

Parallel zieht die Technik in die Kernsysteme. Ebenfalls am 12. Oktober 2026 meldete heise online, dass SAP Unternehmenssoftware mit KI-Agenten neu gestalten will, während die SAP-Anwendergruppe DSAG Wahlfreiheit und Fortschritte auch für bestehende ERP-Systeme fordert. In derselben Woche wurde das Programm der iX-Konferenz S2N Agentic Ops (9. Dezember) veröffentlicht, die sich ausschließlich mit KI im IT-Betrieb befasst. Der Betrieb von Agenten wird damit zu einer eigenen Disziplin. Und der Kern dieser Disziplin ist nicht die Intelligenz des Systems, sondern die Frage, wie man es wieder loswird.

Drei Ebenen der Notbremse

Eine Notbremse ist keine einzelne Taste, sondern die Summe aus drei Fähigkeiten. Erstens: Ich merke innerhalb von Minuten, dass etwas nicht stimmt. Zweitens: Ich stoppe die Ursache schnell und vollständig. Drittens: Ich mache das Geschehene ganz oder teilweise rückgängig. Fehlt eine der drei, ist der Rest wirkungslos. Ein Schalter ohne Detektor wird zu spät gedrückt. Ein Detektor ohne Schalter liefert nur den Zeitpunkt des Schadens. Ein Stopp ohne Rückweg beendet den Fehler und lässt den Schaden stehen.

Beginnen wir beim Erkennen. Agenten melden Erfolge, keine Ausnahmen. Ein Workflow, der 400 Datensätze verarbeitet, meldet am Ende “erfolgreich abgeschlossen”, auch wenn 47 davon inhaltlich falsch waren. Ein Detektor muss deshalb nicht intelligent sein, sondern regelmäßig. Drei Vergleiche reichen für den Anfang und sind auch von einem kleinen Team zu pflegen. Erstens die Aktionsrate pro Stunde gegen das Normalband der letzten vier Wochen. Zweitens die Außenwirkungen pro Tag als harte Zahl: versendete Mails, geschriebene Datensätze, ausgelöste Zahlungen. Bei einem Agenten für Kundenanfragen, wie wir ihn in unserem Artikel zur Kundenservice-Automatisierung mit n8n beschreiben, ist das die Zahl der versendeten Antworten pro Tag. Drittens eine Plausibilitätsprüfung auf die Zielgruppe, zum Beispiel ein Preis unterhalb der Einkaufskosten oder ein Empfänger, der nicht in der Kundenliste steht. Entscheidend ist der Vergleich mit dem eigenen Normalband und nicht der Durchschnittswert. Ein Agent, der sonst 20 Vorgänge pro Stunde erledigt und plötzlich 300, ist nicht effizienter, sondern aus dem Ruder.

Die zweite Ebene ist der Schalter, und hier entscheidet nicht die Technik, sondern die Erreichbarkeit. Ein Not-Aus, der nur über die n8n-Oberfläche im Firmennetz funktioniert, ist kein Not-Aus. Er muss von einem Handy auslösbar sein, nachts, ohne VPN, von einer Person, die nicht weiß, was ein Node ist, und in unter zwei Minuten. Dafür gibt es drei Hebel, die unabhängig voneinander wirken. Erstens den Workflow deaktivieren, damit keine neuen Läufe starten. Zweitens die Zugangsdaten widerrufen, damit ein bereits laufender Lauf seine Werkzeuge nicht mehr benutzen kann. Drittens den Ausgangskanal sperren, also Mailversand, API-Zugang oder Zahlungsweg. Der dritte Hebel ist der wichtigste, weil er auch dann greift, wenn die Automatisierung selbst nicht mehr ansprechbar ist. Wie eng Rechte von Anfang an gefasst sein sollten, damit dieser Hebel nicht die einzige Verteidigungslinie ist, steht in unserem Artikel über Rechte und Freigaben für KI-Agenten. Genauso wichtig wie der Hebel ist die Erlaubnis: Es muss eine benannte Person geben, die den Agenten anhalten darf, ohne vorher den Chef zu fragen. Wer Anhalten bestraft, bekommt Agenten, die zu lange laufen.

Die dritte Ebene ist der Rückweg, und sie wird vor dem Start entschieden, nicht während des Vorfalls. Ein Agent, dessen Schaden reversibel ist, ist ein anderer Agent als einer, der Dinge unwiderruflich nach außen schickt. Vier Konstruktionsregeln helfen. Erstens Entwürfe statt Versand: Der Agent legt Ergebnis und Empfänger in eine Liste, der Versand läuft als getrennter Schritt. Zweitens der Haltepunkt: eine Verzögerung von zehn Minuten zwischen Erstellung und Versand, in der der Stapel noch abbrechbar ist. Drittens Idempotenz, damit ein zweiter Lauf nicht doppelt verschickt. Viertens ein Protokoll, das bei jedem Außenkontakt Ziel, Inhalt und Zeitpunkt festhält. Die Branche baut genau in diese Richtung. Am 9. Oktober 2026 beschrieb heise online mit AWS Strands Box eine Sandbox, die Regeln mitführt, welche frühere Aktionen berücksichtigen. Das genannte Beispiel: Ein Agent darf Logs lesen, aber keine Infrastruktur verändern, und die Regel kennt nicht nur die aktuelle Anfrage, sondern auch das, was der Agent vorher schon getan hat. Das ist im Kern eine Notbremse, die vor dem Vorfall greift statt danach.

Praxis: Not-Aus in n8n aufbauen

In n8n brauchen Sie für den Not-Aus keinen zentralen Umbau, sondern eine Entscheidung an einer Stelle: Der Ausgang wird hinter einen Schalter gelegt, den jeder Agenten-Workflow vor der ersten Außenwirkung liest. Die einfachste belastbare Variante ist ein Wert, der an genau einer Stelle liegt, etwa eine Zeile in der Datenbank, die Sie ohnehin betreiben. Jeder Agenten-Workflow beginnt mit einem Code-Node, der diesen Wert abfragt und bei gesperrtem Ausgang sofort endet.

// Erster Node in jedem Agenten-Workflow
// Fragt den globalen Ausgangsschalter ab, bevor irgendetwas nach außen geht.

const SCHALTER_URL = 'https://intern.example.com/agent-control/outbound';

let erlaubt = false;
try {
  const antwort = await this.helpers.httpRequest({
    method: 'GET',
    url: SCHALTER_URL,
    json: true,
    timeout: 3000,
  });
  erlaubt = antwort.outbound_enabled === true;
} catch (fehler) {
  // Fail-safe: Ist der Schalter nicht erreichbar, wird nichts nach außen gesendet.
  erlaubt = false;
}

return [{
  json: {
    gestoppt: !erlaubt,
    grund: erlaubt ? null : 'Not-Aus aktiv oder Schalter nicht erreichbar',
    zeitpunkt: new Date().toISOString(),
  },
}];

Hinter diesem Code-Node steht ein IF-Node. Ist der Wert gestoppt wahr, endet der Lauf über einen Log-Zweig. Andernfalls läuft der Workflow weiter wie bisher. Der wichtigste Teil ist das catch: Wenn der Schalter nicht antwortet, gilt der Ausgang als gesperrt. Diese Entscheidung kostet Verfügbarkeit und ist trotzdem richtig, solange es um Wirkung nach außen geht. Für reine Leseschritte können Sie umgekehrt entscheiden und bei unerreichbarem Schalter weiterarbeiten. Diese Trennung, außen zu, innen offen, ist der Merksatz, den Sie im Team weitergeben können.

Der Schalter selbst darf nicht von dem System abhängen, das er anhalten soll. Legen Sie ihn deshalb nicht nur in n8n ab. Praktikabel ist ein kleiner zweiter Weg: ein Webhook, der aus einem Messenger heraus ausgelöst wird, mit einer festen Liste berechtigter Absender, der den Wert in der Datenbank umsetzt. Der Bot-Befehl lautet dann schlicht “Ausgang sperren”. Wichtig ist die Rückmeldung: Wer den Not-Aus auslöst, muss innerhalb von Sekunden eine Bestätigung bekommen, sonst weiß er nicht, ob er gewirkt hat, und drückt ein zweites Mal. Für den Fall, dass n8n selbst betroffen ist, bleibt der manuelle Weg über zwei Schritte: alle Agenten-Workflows deaktivieren und die Zugangsdaten der betroffenen Konten widerrufen. Den zweiten Schritt können Sie üben, ohne n8n anzufassen.

Was viele vergessen: Der Not-Aus muss auch die Arbeit stoppen, die schon unterwegs ist. Nach dem Sperren des Ausgangs gehört ein Blick in die Ausführungsliste der letzten Stunde dazu. Was wurde tatsächlich versendet, an welche Empfänger, mit welchem Inhalt? Diese Liste ist im Vorfall Ihre einzige belastbare Quelle, weil sie technisch entsteht und nicht aus Erinnerung. Sichern Sie die Ausführungen, bevor Sie später aufräumen oder neu starten, denn ältere Läufe fallen irgendwann aus der Aufbewahrung.

Praxistipp: Bauen Sie den Not-Aus zuerst für den Agenten mit der größten Außenwirkung, also den, der Mails, Angebote oder Zahlungen auslöst, und üben Sie die Auslösung mit einer Person aus dem Fachbereich, nicht mit der Technik. Wenn die Fachseite den Schalter blind findet, funktioniert er.

Runbook und Übung: die Stoppzeit zählt

Ein Not-Aus ohne Runbook ist ein Schalter, den im Ernstfall niemand findet. Das Runbook passt auf eine Seite und beantwortet fünf Fragen: Wer darf auslösen? Womit wird ausgelöst? In welcher Reihenfolge? Wen muss ich informieren? Wo steht der Schalter, und wie sieht die Bestätigung aus? Die erste Frage ist die strittigste und die wichtigste. Wenn nur die Geschäftsführung auslösen darf, wird die Stoppzeit durch eine Telefonkette bestimmt, also durch den langsamsten Teil des Ablaufs.

Für die ersten fünfzehn Minuten hat sich eine feste Reihenfolge bewährt. Erstens: Ausgang sperren, also Mailversand oder API-Zugang auf der Ebene des Zielsystems abschalten. Zweitens: den Agenten stoppen, damit keine neuen Läufe starten. Drittens: Zugangsdaten widerrufen, um laufende Läufe zu entwaffnen. Viertens: Ausführungen und Protokolle exportieren, solange sie vorhanden sind. Fünftens: entscheiden, ob und wer informiert wird. Schritt eins vor Schritt zwei ist bewusst so gewählt: Der Schalter im Workflow wirkt bei neuen Läufen, das Sperren des Ausgangs wirkt sofort, auch bei einem Lauf, der gerade mitten im Versand steckt.

Die Reihenfolge hat auch eine rechtliche Seite. Betrifft ein Vorfall personenbezogene Daten, greift die Meldepflicht nach Artikel 33 der DSGVO mit einer Frist von 72 Stunden. Ob gemeldet werden muss, entscheidet die Art der Daten und das Risiko für die Betroffenen, nicht die Größe des Vorfalls. Genau dafür brauchen Sie Punkt vier, den Export der Protokolle, denn ohne Aufzeichnung wissen Sie nicht, wessen Daten betroffen sind. Planen Sie diesen Teil mit Ihrer Datenschutzbeauftragten oder einem Anwalt, und zwar bevor etwas passiert.

Übung macht den Unterschied. Ein Not-Aus, der noch nie ausgelöst wurde, ist eine Annahme, kein Mechanismus. Führen Sie einmal im Quartal einen Probealarm durch, und messen Sie die Zeit vom Auslösen bis zur Bestätigung an einer echten Außenwirkung. Zielwert: unter fünf Minuten. Notieren Sie danach zwei Dinge, die schiefgingen, und ändern Sie eine davon. Beim ersten Versuch werden Sie feststellen, dass irgendwo ein Häkchen fehlt, ein Passwort nur in einem Chatverlauf steht oder der Bot-Befehl ein anderer ist als im Runbook. Genau dafür ist die Übung da. Sie dürfen einen Not-Aus auch ohne Vorfall auslösen, als Test, am besten in einem ruhigen Zeitfenster und mit vorheriger Ankündigung an das Team.

In einer Woche zur belastbaren Notbremse

Tag 1: Außenwirkungen auflisten. Gehen Sie Ihre Agenten durch und notieren Sie für jeden nur eine Spalte: Was kann er außerhalb Ihrer Systeme auslösen? Mails, Datensätze bei Dritten, Zahlungen, Einträge auf fremden Plattformen. Sortieren Sie die Liste nach Schwere und Häufigkeit. Der oberste Eintrag ist Ihr erster Kandidat. Diese Liste ist später der Anhang des Runbooks.

Tag 2: Schalter bauen. Legen Sie den globalen Ausgangswert an einer Stelle an und bauen Sie den Abfrage-Node als ersten Schritt in jeden Agenten-Workflow ein, der nach außen wirkt. Fail-safe nach außen zu, innen offen. Testen Sie den Schalter, indem Sie ihn sperren und den Workflow laufen lassen. Der Lauf muss enden, ohne etwas zu verschicken.

Tag 3: Rückweg einbauen. Setzen Sie für den Agenten mit der größten Außenwirkung mindestens zwei der vier Konstruktionsregeln um: Entwurf statt Versand, Haltepunkt für zehn Minuten, Idempotenz, vollständiges Protokoll. Der Haltepunkt ist der günstigste Einstieg, weil er ohne Umbau der Fachlogik funktioniert.

Tag 4: Probealarm. Führen Sie den Not-Aus mit einer Person aus dem Fachbereich durch, ohne Anleitung, mit der Uhr. Messen Sie die Zeit bis zur Bestätigung und prüfen Sie anschließend, dass die Zugangsdaten tatsächlich widerrufen wurden und der Workflow keinen Auftrag mehr ausgeführt hat. Erwartungsgemäß wird an diesem Tag etwas fehlen. Das ist der Zweck.

Tag 5: Runbook und Übergabe. Schreiben Sie die eine Seite, mit Namen statt Rollen, mit Schalterpfad, Reihenfolge und Bestätigung. Übergeben Sie den Not-Aus an die Person, die ihn auslösen darf, und klären Sie schriftlich, wer informiert werden muss. Ab diesem Moment ist der Not-Aus keine technische Vorsichtsmaßnahme mehr, sondern ein benannter Ablauf.

Der dauerhafte Teil: Nehmen Sie drei Größen in Ihre Wochenroutine auf. Die Außenwirkungen des Agenten gegen die Vorwoche, die Stoppzeit der letzten Übung, und die Zahl der Fälle, in denen der Agent ohne Freigabe gehandelt hat. Diese drei Zahlen reichen, um zu erkennen, ob ein Agent noch im Rahmen läuft. Ein Agent verändert sich nicht von selbst, aber sein Umfeld tut es, und meistens ist genau das der Anfang der Geschichte mit den 47 Angeboten.

Fazit

Ein Agent ohne Notbremse ist kein fortschrittlicher Betrieb, sondern ein Betrieb mit einem unversicherten Maschinenraum. Die Meldungen der vergangenen Tage zeigen das deutlich: Ein Microsoft-Chef fordert einen Ausschalter, ein Modell zerstört seine eigene Testumgebung, um an Dateien zu kommen, und eine KI füllt Formulare auf Behördensites aus, bis die EU Auskunft verlangt. In allen drei Fällen war das Verhalten des Systems nicht böse, sondern zielorientiert. Genau das ist der Punkt, den Rechtekonzepte allein nicht abfangen: Sie begrenzen, was ein Agent darf, aber nicht, wie schnell ein Vorfall wirkt.

Erkennen, stoppen, begrenzen. Diese drei Ebenen lassen sich mit Bordmitteln aufbauen, ohne neue Plattform und ohne Sicherheitsabteilung. Der Schalter ist ein Wert in einer Datenbank, der Rückweg ist ein Haltepunkt von zehn Minuten, und die Übung ist ein Quartalstermin. Was dafür gebraucht wird, ist eine Entscheidung darüber, wer den Agenten anhalten darf, und die Bereitschaft, diese Entscheidung auch gegen den Termindruck des Tages zu treffen. Wenn Sie mit einem einzigen Agenten anfangen, nehmen Sie den mit der größten Außenwirkung. In den meisten Betrieben ist das der unscheinbarste, weil er irgendwann angefangen hat, mitzulaufen, ohne dass jemand seine Folgen aufgelistet hat.

Und wenn Sie nicht sicher sind, welche Ihrer Agenten heute nach außen wirken und was davon rückholbar ist: Wir schauen Ihre Agentenlandschaft mit Ihnen durch und bauen die Notbremse dort ein, wo sie zuerst fehlt.

Über MadeByBrain: Wir bauen KI-Automatisierung für den Mittelstand, eigene AI-Agenten, n8n-Workflows und GEO-Strategien, live im Einsatz. Von der ersten Idee bis zur produktiven Automatisierung.

Jetzt kostenloses Strategiegespräch vereinbaren