Bounded Autonomy: typisierte Action-Contracts auf der Consumer-Seite stoppen LLM-Fehler in Enterprise-Software

Was ist das Problem?

In Enterprise-Software — CRM, ERP, interne Tools, Kundensupport-Plattformen — führen KI-Agenten zunehmend Aktionen mit Konsequenzen aus: Datensätze aktualisieren, E-Mails senden, Workflows auslösen, auf verschiedene Kunden-Workspaces zugreifen. Das Problem entsteht, wenn ein LLM einen Fehler macht, der Sicherheitsgrenzen verletzt:

• Nicht autorisierte Aktionen — der Agent führt eine Funktion aus, für die der Benutzer keine Berechtigungen hat
• Fehlerhafte Anfragen — die Struktur eines Tool-Aufrufs verletzt das erwartete Format, die API bricht zusammen
• Cross-Workspace-Ausführung — in einer Multi-Tenant-Umgebung greift der Agent auf die Daten eines anderen Kunden zu
• Unerlaubte Eskalation — der Agent verwendet Tools, die eine höhere Berechtigungsstufe erfordern, als der Benutzer genehmigt hat

Die klassische Lösung lautet „Modell besser trainieren” oder „Guardrails im Prompt hinzufügen”. Beide sind probabilistisch — das Modell kann immer noch Fehler machen, nur seltener. In Enterprise-Umgebungen, wo ein Fehler einen DSGVO-Verstoß oder Vertrauensverlust beim Kunden bedeuten kann, reicht das nicht aus.

Die vom Paper vorgeschlagene Lösung

Das am 17. April 2026 auf arXiv vorgestellte Paper schlägt eine deterministische Schicht außerhalb des Modells vor:

• Typed Action Contracts definieren explizit, welche Aktionen der Agent ausführen darf, mit welchen Argumenten, in welchem Kontext und unter welchen Voraussetzungen
• Consumer-Side Execution bedeutet, dass das LLM Aktionen nicht direkt ausführt — es generiert eine strukturierte Action-Request, die die Consumer-Anwendung dann vor jeder Ausführung gegen den Typ-Vertrag validiert
• Besteht die Anfrage die Typprüfung nicht (falscher Typ, fehlende Berechtigung, falscher Workspace), findet die Aktion nicht statt — unabhängig davon, was das LLM „dachte”

Architektonisch verlagert dies die Sicherheitslast vom probabilistischen Modell auf ein deterministisches Typsystem — statische Prüfung statt Hoffnung zur Laufzeit.

Wie sieht das in der Praxis aus?

Die Autoren liefern konkrete Beispiele aus Enterprise-Umgebungen:

Beispiel 1 — Workspace-Isolation:

UpdateCustomerRecord(customerId: CustomerId, fields: CustomerFields)
  requires: caller.workspace == customer.workspace

Versucht das LLM, einen Kunden aus einem anderen Workspace zu aktualisieren, lehnt das Typsystem dies vor der Ausführung ab.

Beispiel 2 — Berechtigungen:

SendExternalEmail(to: EmailAddress, body: String)
  requires: caller.permissions.includes(SEND_EXTERNAL)

Das Modell kann eine perfekte E-Mail verfassen — fehlt dem Benutzer die SEND_EXTERNAL-Berechtigung, schlägt die Aktion statisch fehl.

Beispiel 3 — Semantische Constraints:

DeleteRecord(id: RecordId)
  requires: record.createdBy == caller || caller.isAdmin

Das Modell kann den Datensatz eines anderen nicht löschen, selbst wenn es ihm logisch erscheint.

Warum ist das besser als Prompt-Engineering?

• Prompt-Engineering setzt darauf, dass das Modell die Anweisung liest und befolgt. Es besteht immer die Möglichkeit, dass das Modell Grenzfälle falsch interpretiert oder versehentlich eine Einschränkung verletzt.
• Typ-Contracts operieren auf der Ebene der Compiler-Prüfung. Sie hängen nicht vom Modellverhalten ab. Wenn korrekt definiert, sind Fehler in den Klassen, die sie abdecken, unmöglich.

Der Trade-off ist die Implementierungskomplexität. Das Typsystem muss sorgfältig gestaltet werden, um reale Szenarien abzudecken, ohne übermäßig starr zu sein. Das Paper enthält Beispiele aus mehreren Enterprise-Bereichen (Vertrieb, Support, HR) und zeigt, dass es praktisch umsetzbar ist.

Implikationen für den Aufbau von KI-Tools

Für Entwickler, die Enterprise-KI-Integrationen bauen, bietet das Paper ein konkretes Designmuster:

1. Definieren Sie explizit alle Aktionen, die der Agent ausführen darf
2. Schreiben Sie für jede Aktion einen typisierten Vertrag mit Vorbedingungen
3. Lassen Sie das Modell eine strukturierte Action-Request produzieren, anstatt direkt auszuführen
4. Die Validierung läuft durch einen deterministischen Typ-Checker vor jeglichen Seiteneffekten

Der Ansatz deckt sich mit den MCP-Trends (Model Context Protocol), die ebenfalls strukturierte Tool-Calls anstelle freier Ausführung fördern. Kombiniert mit MCP ergibt sich eine mehrschichtige Verteidigung, bei der sowohl MCP als auch Typ-Contracts verschiedene Fehlerklassen blockieren.

Das Paper ist ein Preprint, aber die Idee ist konkret genug, dass Teams, die heute Enterprise-KI entwickeln, die Prinzipien sofort anwenden können — ohne auf eine formale peer-reviewte Publikation warten zu müssen.