Ein Support-Chatbot für den Mandanten acme erhält ein Ticket mit der Bitte um eine Rückerstattung. Der Anrufer sendet lediglich einen Chat-Text, doch die assist-api veranlasst das Modell dazu, eine payments.refund-Anfrage zu generieren, und übermittelt diese unter Verwendung der weitreichenden Zahlungsberechtigungen des Dienstes. Das Backend erstellt einen Rückerstattungsvorschlag, zu dessen Initiierung u_123 niemals berechtigt war. Hierfür waren keine exotischen Methoden erforderlich. Nicht vertrauenswürdiger Text aus der Nachricht des Anrufers führte direkt zu einer Aktion, obwohl das Modell nicht befugt war, über die Zulässigkeit dieser Aktion zu entscheiden.
Ein Guardrail (Schutzmechanismus) ist ein Kontrollpunkt, der einschränkt, was eine LLM-Anwendung akzeptiert, ausgibt, zurückgibt oder ausführt. Im vorliegenden Fehlerfall würde der einfachste sinnvolle Guardrail eine Rückerstattungsanfrage ablehnen, sofern der authentifizierte Akteur nicht über den erforderlichen Berechtigungsumfang (Scope) verfügt und eine serverseitige Genehmigungsinstanz die tatsächlichen Rückerstattungsparameter akzeptiert. Die Formulierung des Prompts bietet keinen solchen Schutz, da das Modell lediglich dem Text folgt, den es empfängt; es authentifiziert keine Anrufer, verwaltet keine Budgets und erteilt keine Berechtigungen für Tools.
Das laufende System weist einen Pfad auf, den wir unverändert lassen. Der Endnutzer u_123 gehört zum Mandanten acme und ruft die assist-api über das llm-gateway auf. Der FastAPI-Dienst stellt einen Prompt zusammen, ruft den Anbieter providerA über die chat-Route mit dem Modell $CHAT_MODEL auf und kann dabei eine Tool-Aktion anfordern. u_123 verfügt über die Berechtigungen chat:invoke und payments:refund:propose, jedoch nicht über uneingeschränkte Zahlungsbefugnisse.
Die Vereinbarung für Zahlungsoperationen bleibt eng gefasst und explizit. Das einzige Tool für Zahlungen ist payments.refund, welches die Parameter invoice_id (z. B. inv_987), amount_cents als Ganzzahl (z. B. 1299) und reason als Zeichenkette (String) erfordert. Ein vorgeschlagene Rückerstattung stellt noch keine Erlaubnis zur tatsächlichen Durchführung der Rückerstattung dar. Der Server prüft die Mandantenzugehörigkeit, den Berechtigungsumfang, die Argumente und das Vorliegen einer Genehmigung, bevor eine irreversible Zahlungsaktion ausgeführt wird.
Jede Schnittstelle, über die Text übertragen wird, gilt als nicht vertrauenswürdig; dies umfasst die Nachricht des Anrufers, abgerufene Dokumente, Tool-Ergebnisse sowie die Modellausgabe. Ein abgerufenes Support-Dokument kann Anweisungen enthalten, die im Widerspruch zur Richtlinie der Anwendung stehen, und die Modellausgabe kann Felder enthalten, die bei einer Weitergabe an eine Zahlungs-API ohne vorherige Validierung ein Sicherheitsrisiko darstellen würden. Dies entspricht dem Punkt LLM01 (Prompt Injection) der „OWASP Top 10 for LLM Applications 2025“, die im November 2024 vom OWASP GenAI Security Project veröffentlicht wurden. Die Invariante ist eindeutig: Kein Tool-Aufruf darf mit mehr Berechtigungen ausgeführt werden, als sie durch die Aktion von u_123 legitimiert sind.
Der festgelegte Pfad führt die nicht vertrauenswürdigen Eingaben und die Durchsetzungsgrenzen in einer einzigen Ansicht zusammen.
Das Gateway stellt fest, wer den Aufruf getätigt hat, während die assist-api den Tenant, die Scopes, den Tool-Vertrag und die Genehmigungspflicht des Benutzers durchsetzt. Der Anbieter providerA generiert eine Ausgabe unter Verwendung seiner eigenen Anbieter-Zugangsdaten; diese dürfen jedoch niemals die Befugnis verleihen, Rückerstattungen im Namen von u_123 durchzuführen. Die Nutzung der weiterreichenden Berechtigungen des Dienstes für einen Benutzer, der selbst nicht über diese verfügt, führt zu einem „Confused Deputy“-Sicherheitsproblem.
Regel zur Systemgrenze
Das Modell darf
payments.refundvorschlagen; nur serverseitige Prüfungen dürfen diesen Vorgang autorisieren oder ausführen.
Da jede Systemgrenze eine andere Aufgabe erfüllt, sollte eine Ablehnung diejenige Stufe kenntlich machen, die den Vorgang nicht sicher fortsetzen konnte. Das llm-gateway gibt bei fehlenden, ungültigen, widerrufenen oder kompromittierten Zugangsdaten den Status 401 Unauthorized zurück. Nach der Authentifizierung geben das Gateway oder die Anwendung 403 Forbidden zurück, wenn dem Aufrufer ein erforderlicher Scope fehlt. Auch bei einem blockierten Ziel für den Abruf eines Tools wird 403 Forbidden zurückgegeben; das blockierte Ziel wird dabei nicht kontaktiert.
Nach der Antwort von providerA validiert die assist-api die Modellausgabe, bevor diese an einen Parser, eine Zahlungs-API oder eine andere nachgelagerte Komponente weitergeleitet wird. Bei einer Ausgabe, die nicht dem Schema entspricht, wird 422 Unprocessable Content zurückgegeben – die in RFC 9110 definierte Bezeichnung für das, was in älterer Dokumentation als „Unprocessable Entity“ bezeichnet wurde. Die Wiederverwendung eines Idempotenz-Schlüssels mit abweichenden Rückerstattungsparametern führt ebenfalls zu 422 Unprocessable Content; die Wiederverwendung desselben Schlüssels, während die erste Anfrage noch aktiv ist, führt zu 409 Conflict.
Die übrigen Ergebnisse spiegeln eher betriebliche Grenzen als eine Entscheidung des Modells wider.
202 Accepted wird zurückgegeben, wenn eine irreversible Rückerstattung zur Genehmigung zurückgehalten wird (zusammen mit einer Kennung für die ausstehende Genehmigung).429 Too Many Requests (mit Retry-After-Angabe) wird zurückgegeben, wenn ein gemeinsames Kontingent oder ein Ratenlimit (Rate Limit) ausgeschöpft ist.503 Service Unavailable wird zurückgegeben, wenn der Speicher für die Durchsetzung von Richtlinien (Enforcement Store) nicht verfügbar ist und die Anwendung Richtlinien nicht sicher durchsetzen kann.504 Gateway Timeout wird zurückgegeben, wenn providerA das Zeitlimit für den Anbieteraufruf überschreitet.Diese Ergebnisse verhindern, dass Clients eine Ablehnung lediglich als vagen Fehler des Modells interpretieren. Sie zeigen zudem auf, wo nach der Ursache gesucht werden muss: ob es sich um ein Problem bei der Identitätsprüfung am llm-gateway, bei der Validierung in der assist-api oder bei einem nicht abgeschlossenen Anbieteraufruf handelt.
Im ersten Fehlerszenario verfügt der Angreifer lediglich über eine Chat-Nachricht, löst damit jedoch einen Vorschlag für eine irreversible Rückerstattung aus. Welche Stufe sollte den Zugriff zuerst verweigern: A, Authentifizierung des Aufrufers und Tenant-Zuordnung am llm-gateway; B, Tool-Autorisierung und -Freigabe an der assist-api; oder C, Überprüfung der Ausgabe nach dem Modell?