Salesforce und IBM bauen den Not-Aus für KI-Agenten

Wer KI-Agenten im Betrieb anhalten will, kann das bei Salesforce seit dem 27. Oktober von Hand tun: Der manuelle Agent Kill Switch ist allgemein verfügbar, der von Evals automatisch ausgelöste folgt laut Salesforce erst im Januar 2027. Dasselbe gilt für FinOps Dashboard, Model Wallet und Kostenrichtlinien, die bereits GA sind. Bei IBM sind HashiCorp Vault 2.2 und Agent Identity verfügbar, der Kill Switch in watsonx Orchestrate (Contain) ist dagegen erst Tech Preview.

Das betrifft alle Betriebe, die Agenten bereits produktiv laufen lassen. Die Ankündigungen vom 27. Oktober 2026 trennen sauber zwischen Beta, Preview und GA, und genau diese Trennung entscheidet, worauf Sie sich verlassen dürfen. Ein Not-Aus, den erst ein Mensch bemerken und betätigen muss, ist etwas anderes als eine Schranke, die selbstständig schließt.

Was Salesforce in Agent Fabric freischaltet

Salesforce erweitert Agent Fabric um Agent Evals, API Evals und zusätzliche Kostenkontrollen. Agent Evals erzeugen vor dem Deployment Tests und bewerten anschließend Agenten, Sprachmodelle (LLMs) und MCP-Server im laufenden Betrieb. MCP steht für Model Context Protocol, eine Schnittstelle, über die Agenten auf Werkzeuge und Datenquellen zugreifen. Die Bewertung umfasst damit den Agenten selbst und alles, was er benutzt.

Für die Kostenseite nennt Salesforce drei Bausteine: das FinOps Dashboard, das Model Wallet und Cost Optimization Policies. Das Model Wallet setzt laut Salesforce harte Limits, die Anfragen stoppen, bevor die Kosten das Budget übersteigen. Ein Dashboard zeigt Überschreitungen lediglich an. Eine technisch durchgesetzte Obergrenze schützt dagegen vor dem klassischen Fall des Agenten, der in einer Schleife hängt und über Nacht Token verbraucht.

Die Verfügbarkeit nach Herstellerangabe im Einzelnen:

• Agent Evals und API Evals: Beta im November 2026, GA im Januar 2027
• Custom Agent Scanner: Beta seit 27. Oktober, GA im Januar 2027
• Agent Kill Switch: GA
• Triggered-Agent Kill Switch (durch Evals ausgelöst): GA im Januar 2027
• Open Policies for Federated API Gateways: GA
• FinOps Dashboard, Model Wallet, Cost Optimization Policies: GA

dm-Einordnung: Die Liste zeigt eine Reihenfolge, die man leicht übersieht: Die Bremsen und Budgetgrenzen sind zuerst da, die Messung, die darüber entscheidet, wann gebremst werden soll, kommt später. Bis Januar 2027 fehlt damit die automatische Verbindung zwischen Qualitätsurteil und Eingriff. Zwischen November und Januar lassen sich Agent Evals in der Beta ausprobieren, produktive Abläufe sollten sich darauf aber noch nicht stützen.

dm-Einordnung: Wer bereits Agenten mit Salesforce betreibt, sollte festlegen, wer den manuellen Kill Switch außerhalb der Bürozeiten bedienen darf und woran diese Person einen Fehlerfall erkennt. Ohne Evals in GA bleibt das Erkennen eine menschliche Aufgabe. Dazu gehören ein benannter Ansprechpartner je Agent, eine kurze Anleitung für den Eingriff und eine Regel, wer danach den Betrieb wieder freigibt. Die Beta der Evals eignet sich, um Testfälle und Schwellenwerte vorzubereiten, damit der spätere Triggered-Agent Kill Switch nicht mit ungeprüften Annahmen startet. Dass die Frage der Zuständigkeit auch bei Zugriffsrechten anderer Plattformen drängt, zeigt etwa die Debatte um offene Fragen an CIOs bei SAP OpenShell. Das Muster ist gleich: Die Technik für Kontrolle existiert, die Verantwortlichkeit muss der Betrieb selbst regeln.

dm-Einordnung zu den Budgetgrenzen: Ein hartes Limit stoppt Anfragen, es entscheidet aber nicht, welche Anfragen wichtig sind. Wer das Model Wallet einsetzt, sollte vorab bestimmen, welche Agenten bei Erreichen der Grenze Vorrang behalten und wer bei einem Stopp informiert wird. Sonst steht im Ernstfall ein geschäftskritischer Ablauf still, weil ein Testagent das Budget verbraucht hat.

Preise und Lizenzmodelle nennt die Salesforce-Mitteilung zu Agent Fabric nicht. Ob die Kostenkontrollen Zusatzkosten verursachen, lässt sich daraus nicht ableiten und muss vertraglich geklärt werden.

Der Kill Switch und wer ihn auslöst

Bei Salesforce gibt es zwei Arten, einen Agenten zu stoppen. Der manuelle Agent Kill Switch ist laut Mitteilung vom 27. Oktober GA: Ein Mensch erkennt das Problem und schaltet ab. Der Triggered-Agent Kill Switch soll dagegen im Januar 2027 GA werden. Auslöser ist dann ein Ergebnis der Agent Evals.

Laut Salesforce lösen Evals bei Unterschreiten vorgegebener Schwellen vordefinierte Eingriffe aus, „including the Agent Kill Switch — with approval where the team’s policy requires it“. Zwei Dinge sind daran wichtig. Erstens ist der Kill Switch nur einer von mehreren möglichen Eingriffen, nicht der einzige. Zweitens kann die Policy eines Teams verlangen, dass ein Mensch den Eingriff freigibt. Die Software schlägt den Eingriff vor, ein Mensch bestätigt ihn.

Dahinter steht eine Entwurfsentscheidung mit betrieblichen Folgen. Ein vollautomatischer Stopp schützt schneller, kann aber legitime Abläufe unterbrechen, wenn die Schwelle falsch gesetzt ist. Eine Freigabepflicht verhindert Fehlalarme, kostet jedoch Zeit, die bei einem laufenden Fehler teuer sein kann. Welche Variante passt, hängt davon ab, was der Agent tun darf: Ein Agent, der Texte entwirft, verträgt eine Freigabeschleife. Ein Agent, der Bestellungen auslöst oder Preise ändert, braucht eine kürzere Reaktionszeit.

Salesforce selbst führt ein Händler-Szenario an. Das ist ein Herstellerbeispiel und kein Praxisbericht; Daten dazu, wie oft Kill Switches bei Kunden tatsächlich genutzt werden, nennt die Quelle nicht. Es zeigt die Logik, nicht die Wirksamkeit.

dm-Einordnung: Bevor der Triggered Kill Switch im Januar 2027 verfügbar ist, lässt sich die Policy bereits planen. Ein Betrieb sollte pro Agent drei Dinge festhalten: welche Messwerte einen Eingriff rechtfertigen, ob eine Freigabe nötig ist und wer sie in welcher Frist erteilt. Wer die Freigabe an eine Person ohne Vertretung bindet, baut sich einen Engpass. Bei der Inventarisierung der Agenten hilft der Blick auf KI-Agenten im IT Asset Management, denn ein Not-Aus setzt voraus, dass bekannt ist, welche Agenten überhaupt laufen und wem sie gehören.

Ebenso wichtig ist die Unterscheidung zwischen Abschalten und Aufräumen. Ein gestoppter Agent hat womöglich schon Daten verändert oder Vorgänge angestoßen. Die Mitteilung sagt nichts darüber, ob und wie der Kill Switch solche Folgen zurückrollt. Das sollten Betriebe im Test mit realistischen Abläufen prüfen, statt es anzunehmen.

Agenten-Identität und Zugangsdaten bei IBM

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptBusiness team in a glass meeting room discussing a large screen with abstract budget gauges and agent workflow nodes, daylight, professional mood. Photorealistic editorial magazine photo, 16:9. Absolutely no text, no letters, no numbers, no logos, no brand marks.

IBM setzt an einer anderen Stelle an als Salesforce: bei der Frage, wer ein Agent überhaupt ist und was er sich nehmen darf. Laut IBM-Mitteilung vom 27. Oktober 2026 (TechXchange) bekommt über HashiCorp Vault mit Agent Identity jeder Agent eine eigene Identität. Die Zugangsdaten sind kurzlebig, die Rechte folgen dem Prinzip der geringsten Berechtigung (Least Privilege), und bei einer unautorisierten Aktion werden sie in Echtzeit widerrufen.

Der Nutzen zeigt sich im Vergleich zur gängigen Praxis. Oft laufen Agenten unter geteilten Dienstkonten oder mit langlebigen API-Schlüsseln. Wird ein solcher Schlüssel missbraucht, ist unklar, welcher Agent gehandelt hat, und der Entzug trifft alle Nutzer des Kontos. Eigene Identitäten machen Handlungen zuordenbar, kurze Laufzeiten begrenzen den Schaden eines Lecks.

Vault 2.2 bringt laut IBM eigene Agentenkonten, automatische Erneuerung der Credentials und Post-Quanten-Verschlüsselung. Vault 2.2 und Agent Identity sind GA, ebenso Orchestrate Evaluate, Concert und Terraform Policy.

dm-Einordnung zur Einführung: Eigene Agentenkonten setzen voraus, dass bekannt ist, welche Agenten existieren und welche Systeme sie erreichen. Praktisch beginnt das mit einer Bestandsaufnahme der vorhandenen Dienstkonten und Schlüssel, danach folgt die Zuordnung je Agent mit möglichst engen Rechten. Die automatische Erneuerung verlangt, dass die angebundenen Anwendungen mit wechselnden Zugangsdaten umgehen können. Das ist bei älteren Systemen nicht selbstverständlich und sollte vor einer Umstellung getestet werden.

In watsonx Orchestrate nennt IBM drei Funktionen mit unterschiedlichem Status:

• Discover (Tech Preview): findet Agenten unter anderem in Amazon Bedrock, Microsoft Foundry und Google Gemini
• Contain (Tech Preview): isolierte Sandboxes und ein Kill Switch
• Evaluate (GA): Tests und Kostentracking

Hier liegt der Kern des Vergleichs: IBMs Kill Switch gehört zu Contain und ist Tech Preview, also noch nicht allgemein verfügbar. Die belastbare Bremse bei IBM ist nach Stand der Mitteilung der Widerruf von Zugangsdaten über Vault. Ein Datum für die Previews nennt die Mitteilung nicht, und eine fehlende Angabe ist kein Beleg, dass sie weit entfernt sind. Kundendaten zur Nutzung eines Kill Switch liefert die Mitteilung ebenfalls nicht.

dm-Einordnung zu Discover: Dass die Funktion Agenten in mehreren Fremdplattformen finden soll, adressiert ein reales Problem, denn was niemand kennt, kann niemand absichern. Als Tech Preview taugt sie zum Ausprobieren in einer abgegrenzten Umgebung. Als Grundlage eines vollständigen Agentenverzeichnisses sollten Sie sie erst nutzen, wenn der Status GA erreicht ist.

Zur Begründung zitiert IBM Gartner: Bis 2028 soll es in einem Fortune-500-Unternehmen über 150.000 Agenten geben, und nur 13 % der Organisationen sähen eine passende Governance. Das ist eine von IBM wiedergegebene Prognose und Umfrage, die wir nicht selbst geprüft haben. Sie taugt als Hinweis auf die Größenordnung, nicht als Messwert für Ihren Betrieb.

dm-Einordnung: Identität und Kill Switch sind verschiedene Ebenen. Der Widerruf von Credentials stoppt, was ein Agent bei Dritten tun kann, aber nicht zwingend, was er intern weiter berechnet. Wer beide Anbieter nutzt, sollte klären, an welcher Stelle welcher Stopp greift, und das in einem Ablaufplan festhalten: wer widerruft, wer stoppt, wer prüft danach die Protokolle.

Bis zu 75 Prozent und andere Herstellerangaben

Salesforce schreibt, Cost Optimization Policies senkten den Token-Verbrauch „by up to 75% (based on test scenarios)“. Zwei Einschränkungen stecken schon im Satz: „bis zu“ nennt den Bestfall, und „based on test scenarios“ verweist auf Testszenarien statt auf Produktivbetrieb. Eine unabhängige Messung der 75 Prozent nennt die Quelle nicht. Als Planungsgröße taugt die Zahl daher nicht.

Ein Token ist die Abrechnungseinheit, in der Sprachmodelle Text verarbeiten. Wie stark sich der Verbrauch senken lässt, hängt davon ab, wie viel Verschwendung vorher drinsteckt: lange Kontexte, wiederholte Abfragen, unnötig große Modelle. Ein bereits schlank gebauter Agent hat wenig Spielraum, ein ungeprüfter Prototyp viel. dm-Einordnung: Die 75 Prozent beschreiben deshalb eher eine mögliche Obergrenze der Einsparung bei ungünstiger Ausgangslage.

Weitere Zahlen stammen ebenfalls von Salesforce: über 1,2 Milliarden Requests täglich und 96 % der Unternehmen, die Agenten auf mehr als einer Plattform betreiben. Beide sind Herstellerangaben, und die Quelle erläutert nicht, wie sie ermittelt wurden. Die zweite Zahl stützt ein Argument, das plausibel ist: Wer Agenten bei mehreren Anbietern hat, braucht Kontrolle, die über eine einzelne Plattform hinausgeht. Genau dafür sind Open Policies for Federated API Gateways gedacht, die GA sind. Auch IBMs Discover zielt darauf, Agenten in fremden Umgebungen zu finden.

Bei beiden Anbietern gilt: Die Ankündigungen beschreiben Funktionen, keine Ergebnisse. Preise und Lizenzmodelle nennen beide Quellen nicht, ebenso keine Kundendaten zur Nutzung der Kill Switches.

dm-Einordnung: Was Betriebe vor einer Einführung prüfen sollten:

• Status je Funktion: GA, Beta oder Tech Preview, und nur GA in produktive Abläufe einplanen
• Eigener Test der Einsparung: den Token-Verbrauch eines realen Agenten vor und nach den Richtlinien messen, statt die 75 Prozent anzusetzen
• Wirkung des Limits: ob das Model Wallet bei Erreichen der Grenze Anfragen ablehnt und wie der Agent darauf reagiert
• Zuständigkeit: wer den manuellen Kill Switch bedient und wer Credential-Widerrufe auswertet
• Plattformübergreifende Lücken: welche Agenten weder Salesforce noch IBM erfassen

dm-Rechnung als Veranschaulichung, ausdrücklich hypothetisch: Verbraucht ein Agent monatlich 100 Millionen Token, wären 75 Prozent Einsparung rechnerisch 25 Millionen verbleibende Token. Erreicht Ihr Betrieb stattdessen 20 Prozent, blieben 80 Millionen. Der Abstand von 55 Millionen Token zeigt, wie stark sich ein Budget verschiebt, je nachdem, ob die Herstellerzahl oder die eigene Messung gilt.