Ein LLM-Agent mit Tool-Zugriff storniert eine Buchung, die er nie stornieren durfte. Das Tool meldet Erfolg. Der Agent meldet die Aufgabe als erledigt. Kein Fehler wird ausgelöst. Kein Log vermerkt den Verstoß. In regulierten Umgebungen ist dies das Fehlerbild, auf das es am meisten ankommt.
Ein Paper von Reddy, Challaram und Basu (arXiv:2607.07405, Juli 2026) unterlegt das Problem mit harten Zahlen. In der Airline-Domäne von τ²-bench sind 78 % der beobachteten Fehler eines Agenten mit Budget-Modell stille Fehlzustände (Silent Wrong-State Failures): Der Agent führt einen Zustand herbei, den die fachliche Policy verbietet, aber kein Tool-Fehler wird sichtbar. Der Schreibzugriff geht durch. Der Zustand ändert sich. Niemand bemerkt es, bis sich die Folgen in nachgelagerten Systemen zeigen.
Wenn Ihre Agenten mit Backends arbeiten, die fachliche Policies nicht selbst durchsetzen (SAP-Transaktionen, Systeme zur Schadenbearbeitung, Buchungssysteme), ist das für Sie als Integrationsarchitekt keine akademische Randfrage. Es ist eine betriebliche Lücke zwischen Ihren Tools und Ihrer Compliance-Grenze.
Das Monitoring in Unternehmen konzentriert sich meist auf explizite Fehler: HTTP-Antworten mit 4xx/5xx, Exception-Traces, Nachrichten in der Dead Letter Queue. Dieses Modell setzt voraus, dass Tools fehlerhafte Aufrufe ablehnen. In Umgebungen ohne eigene Policy-Prüfung akzeptiert ein Tool jedoch jede formal korrekte Anfrage. Die Policy steckt in den Geschäftsregeln, nicht im API-Vertrag. Ein Agent kann einen strukturell gültigen Aufruf absetzen, der gegen eine fachliche Vorgabe verstößt, und das Tool führt ihn aus.
Ein eigener Benchmark zum Datenschutz, AgentLeak, weist in dieselbe Richtung: Nachrichten zwischen Agenten geben private Daten mit einer Rate von 68,8 % preis, und Audits, die nur die Ausgaben prüfen, übersehen 41,7 % der Datenschutzverstöße. Eine klassische Audit-Architektur, die auf Tool-Antworten und die Selbstauskünfte der Agenten schaut, deckt diesen Bereich nicht ab.
Hinzu kommt ein Problem, das sich selbst verstärkt. Wenn die probabilistische Vermutung eines Agenten für den nächsten Agenten zur gesicherten Tatsache wird, entsteht das, was die Fachliteratur eine Halluzinationskaskade nennt. In einer Multi-Agenten-Pipeline, die Schadenfälle oder Kontoänderungen bearbeitet, kann eine ungeprüfte Schlussfolgerung aus Schritt zwei bis Schritt fünf zu einem Verstoß gegen regulatorische Vorgaben anwachsen. Jede Station macht etwas glaubwürdiger, das nie geprüft wurde.
Der Ansatz, den Reddy et al. vorschlagen, ist bewusst schlicht: deterministische, rein lesende Gates, die vor der Ausführung prüfen. Vor jeder Schreiboperation gleicht ein Gate den vorgeschlagenen Aufruf mit dem Ist-Zustand und der fachlichen Policy ab. Das Gate schlussfolgert nicht. Es prüft. Ist der Zustandsübergang verboten, wird der Schreibzugriff vor der Ausführung blockiert.
Vier Gates zusammen hoben die Erfolgsquote über den gesamten Benchmark bei gpt-4o-mini von 29,6 % auf 42,0 %, ein Plus von 12,4 Prozentpunkten, das sich auf einem separaten Seed-Set reproduzieren ließ (P = 0,0008). Der Effekt konzentrierte sich auf die 26 von 50 Aufgaben, bei denen die Gates tatsächlich auslösten: Dort betrug die Verbesserung 19,2 Prozentpunkte. Bei den 24 Aufgaben, bei denen kein Gate auslöste, war die Veränderung nicht von null zu unterscheiden.
Diese Konzentration ist aufschlussreich. Sie zeigt genau, wo der Nutzen liegt: an der Grenze zwischen dem Schlussfolgern des Agenten und Schreibzugriffen, die einen Zustand ändern. Nicht überall. Nicht bei Aufgaben, in denen das Tool die Regeln bereits selbst durchsetzt. Gates helfen genau dort, wo der Tool-Ebene die Durchsetzung der Policy fehlt.
Das Paper berichtet außerdem über erste, noch nicht replizierte Hinweise darauf, dass das Muster auch bei Frontier-Modellen gilt. Dieselben vier Gates steigerten die Erfolgsquote von gpt-5.2 von 61,2 % auf 71,6 %. Auch leistungsfähigere Modelle versuchen Schreibzugriffe, die gegen die Policy verstoßen. Nach dieser Datenlage sieht das Fehlerbild nicht nach einer Fähigkeitslücke aus, die sich allein durch besseres Schlussfolgern schließen lässt.
Nicht jeder Tool-Aufruf braucht ein Gate. Das Paper enthält zwei Negativkontrollen, die die Grenze klar ziehen: In einer Retail-Domäne, deren Tools die Regeln selbst durchsetzen, und in BFCL (einem Benchmark für Function Calling) brachten die Gates wenig. Wenn Ihre API verbotene Zustandsübergänge bereits durch eine saubere Validierung ablehnt, ist ein Gate vor der Ausführung Aufwand ohne Nutzen.
Die Entscheidung richtet sich nach Risikostufen. Agenten für die Abrechnung, Agenten für Kontoaktionen, medizinische oder juristische Tools: Sie brauchen strengere Gates und breitere Stichproben für die Validierung. Eine rein lesende Abfrage in einem Produktkatalog braucht das wahrscheinlich nicht. Umfragen unter Entwicklern weisen in dieselbe Richtung: 61 % der Entwickler stimmen zu, dass KI-Tools oft Code erzeugen, der korrekt aussieht, aber nicht zuverlässig ist, und rund 65 % der Entwickler, die KI für Refactoring nutzen, sagen, dass der Assistent relevanten Kontext übersieht.
Wie streng ein Gate prüft, sollte sich nach den Kosten eines stillen Fehlzustands richten. In einem Buchungssystem lässt sich eine fälschlich stornierte Reservierung wiederherstellen. In einer Pipeline zur Schadenregulierung oder bei einer regulatorischen Meldung führt dieselbe Fehlerklasse zu Prüfungsfeststellungen, Bußgeldern oder Schlimmerem.
Wenn Sie Agenten mit Tool-Zugriff produktiv einsetzen, ist die praktische Konsequenz ein Artefakt: ein Integrationsvertrag für Agenten, der Folgendes festlegt: Identität und Berechtigungsgrenzen, die zulässigen Tools, Prüfungen von Vor- und Nachbedingungen bei zustandsändernden Aufrufen und Logging-Vorgaben, die die Entscheidungswege (Decision Traces) erfassen, nicht nur die Ausgaben.
Festschreiben sollten Sie auch die betrieblichen Anforderungen: eine Fehlertaxonomie, die Tool-Fehler von stillen Fehlzuständen unterscheidet; SLIs, die neben dem Aufgabenerfolg auch verfolgen, wie oft Gates auslösen und wie oft sie blockieren; Aufbewahrungsregeln für die Logs der Nachrichten zwischen Agenten, nicht nur für die Endergebnisse; und ein Runbook für die Untersuchung blockierter Schreibzugriffe, einschließlich der Frage, wie sich feststellen lässt, ob das Gate einen echten Verstoß verhindert hat oder ein False Positive vorlag.
Der Mehraufwand ist real. Gates erhöhen die Latenz auf jedem Schreibpfad. Sie verlangen, dass Policy-Definitionen als strukturierte, versionierte Artefakte getrennt vom Modell gepflegt werden. Sie erzeugen eine neue Klasse von False Positives, die eine Triage brauchen. Nichts davon ist umsonst. Die Alternative ist aber das, was diese Studie in einer Benchmark-Domäne gemessen hat: Bei einem Agenten mit Budget-Modell lösten 78 % der beobachteten Fehler überhaupt keinen Tool-Fehler aus.
Reddy et al. betonen ausdrücklich, dass deterministische Gates den Erfolg einer Aufgabe nicht garantieren. Sie verhindern eine bekannte Klasse stiller Verstöße an der Stelle, an der der Agent handelt. Das ist eine engere Aussage als die meisten Versprechen zur Zuverlässigkeit von KI, und eine ehrlichere. In der Integrationsarchitektur ist nicht die Leistungsfähigkeit die entscheidende Grenze, sondern die Kontrolle. Die Agenten mögen schlussfolgern, so viel sie wollen: Den Schreibzugriff muss trotzdem jemand prüfen.
