---
title: "Deterministische Gates gegen stille Verstöße von LLM-Agenten"
description: "In τ²-bench (Airline) sind 78 % der Fehler eines Budget-Agenten stille Policy-Verstöße ohne Tool-Fehler. Rein lesende Gates prüfen jeden Schreibzugriff vorab."
canonical: "https://www.kondevs.com/de/content-hub/deterministic-gates-silent-policy-violation-llm-agents/"
language: "de"
type: "article"
author: "KONDEVS"
published: "2026-11-11T22:19:56.548Z"
modified: "2026-11-11T22:19:56.548Z"
image: "https://www.kondevs.com/assets/images/content/de/deterministic-gates-silent-policy-violation-llm-agents/og.png"
tags: ["ki-agenten", "deterministische-gates", "policy-durchsetzung", "agenten-zuverlaessigkeit", "tool-calling", "integrationsvertraege", "KI-Agent", "Large Language Model (LLM)"]
---

> Den vollständigen Index dieser Website finden Sie in [llms.txt](https://www.kondevs.com/llms.txt); die ganze Website in einer Datei: [llms-full.txt](https://www.kondevs.com/llms-full.txt).

# Stille Fehler von KI-Agenten: ein Fall für deterministische Gates

In einem Agenten-Benchmark hinterließen 78 % der Fehler keine Spur. Rein lesende Gates prüfen jeden Schreibzugriff, bevor er ausgeführt wird.

EAI & Integration 11. November 2026 5 Min. Lesezeit

Von KONDEVS

![Strichzeichnung einer Reihe von Toren an einem fließenden Strom, durch jedes Tor gehen kleine Figuren](https://www.kondevs.com/cdn-cgi/image/width=1200,quality=80,format=auto/assets/images/content/de/deterministic-gates-silent-policy-violation-llm-agents/featured.png)

## Das Wichtigste in Kürze

- In der Airline-Domäne von τ²-bench waren 78 % der beobachteten Fehler eines Agenten mit Budget-Modell stille Fehlzustände: Der Schreibzugriff ging durch, und kein Tool-Fehler wurde sichtbar.
- Deterministische, rein lesende Gates prüfen vor der Ausführung jeden vorgeschlagenen Schreibzugriff gegen den Ist-Zustand und die fachliche Policy und blockieren ihn, wenn der Zustandsübergang verboten ist.
- Vier Gates zusammen hoben die Erfolgsquote über den gesamten Benchmark bei gpt-4o-mini von 29,6 % auf 42,0 %; der Gewinn konzentrierte sich auf die 26 von 50 Aufgaben, bei denen die Gates auslösten.
- Wo Tools die Regeln bereits selbst durchsetzen, brachten Gates wenig, wie Negativkontrollen in einer solchen Retail-Domäne und in BFCL zeigten.
- Ein Integrationsvertrag für Agenten sollte Berechtigungsgrenzen, die zulässigen Tools, Prüfungen von Vor- und Nachbedingungen bei Schreibzugriffen und die Protokollierung der Entscheidungswege festlegen.

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 Fehlerbild, das klassische Audits übersehen

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.

## Was deterministische Gates tatsächlich tun

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.

## Wann ein Gate nötig ist und wann das Tool genügt

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.

## Was das für den Integrationsvertrag Ihrer Agenten bedeutet

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.

## Häufige Fragen

### Was ist ein stiller Fehlzustand (Silent Wrong-State Failure)?

Ein Fehler, bei dem ein Agent mit Tool-Zugriff einen Zustand herbeiführt, den die fachliche Policy verbietet, ohne dass ein Tool-Fehler sichtbar wird. Der Schreibzugriff geht durch, der Zustand ändert sich, und niemand bemerkt es, bis sich die Folgen in nachgelagerten Systemen zeigen.

### Was macht ein deterministisches Gate vor der Ausführung?

Vor jeder Schreiboperation gleicht das Gate den vorgeschlagenen Aufruf mit dem Ist-Zustand und der fachlichen Policy ab. Es schlussfolgert nicht, es prüft: Ist der Zustandsübergang verboten, wird der Schreibzugriff vor der Ausführung blockiert.

### Wie stark haben die Gates den Erfolg der Agenten in der Studie verbessert?

In der Airline-Domäne von τ²-bench hoben vier Gates zusammen die Erfolgsquote über den gesamten Benchmark bei gpt-4o-mini von 29,6 % auf 42,0 %, ein Plus, das sich auf einem separaten Seed-Set reproduzieren ließ. Der Effekt konzentrierte sich auf die 26 von 50 Aufgaben, bei denen die Gates auslösten.

### Wann lohnt sich ein Gate nicht?

Wenn die API verbotene Zustandsübergänge bereits durch eine saubere Validierung ablehnt, ist ein Gate vor der Ausführung Aufwand ohne Nutzen. Wie streng ein Gate prüft, sollte sich nach den Kosten eines stillen Fehlzustands richten: Tools für Abrechnung, Kontoaktionen, Medizin oder Recht brauchen strengere Gates als eine rein lesende Abfrage im Produktkatalog.

## Quellen

1. [Reason Less, Verify More: Deterministic Gates Recover a Silent Policy-Violation Failure Mode in Tool-Using LLM Agents (arXiv:2607.07405), arXiv (Vikas Reddy, Sumanth Reddy Challaram, Abhishek Basu; v1 8 July 2026)](https://arxiv.org/abs/2607.07405)
2. [AgentLeak: A Benchmark for Internal-Channel Privacy Leakage in Multi-Agent LLM Systems (arXiv:2602.11510), arXiv (Faouzi El Yagoubi et al.)](https://arxiv.org/abs/2602.11510)
3. [The AI trust gap: Why code verification matters, Sonar (State of Code Developer Survey, 22 January 2026)](https://www.sonarsource.com/blog/ai-coding-trust-gap/)
4. [State of AI code quality in 2025, Qodo (survey of 609 developers)](https://www.qodo.ai/reports/state-of-ai-code-quality/)
5. [From Spark to Fire: Modeling and Mitigating Error Cascades in LLM-Based Multi-Agent Collaboration (arXiv:2603.04474), arXiv](https://arxiv.org/abs/2603.04474)
6. [The Berkeley Function Calling Leaderboard (BFCL): From Tool Use to Agentic Evaluation of Large Language Models, PMLR vol. 267 (ICML 2025), Patil et al.](https://proceedings.mlr.press/v267/patil25a.html)

## Verwandte Begriffe und Leistungen

Wichtige Begriffe: [KI-Agent](https://www.kondevs.com/de/glossary/#ai-agent), [Large Language Model (LLM)](https://www.kondevs.com/de/glossary/#large-language-model)

Unsere Leistung: [Enterprise Integration & BPM](https://www.kondevs.com/de/services/eai-integration/)

ki-agenten deterministische-gates policy-durchsetzung agenten-zuverlaessigkeit tool-calling integrationsvertraege