Ledgerline leitet die Support-Anfrage eines Mitarbeiters über eine Assistant-API, einen Modellanbieter und ein Rückerstattungstool weiter. Ein Jira-Ticket enthielt Text, der eine Kundenrückerstattung forderte; der Assistent interpretierte diesen Text als Anweisung, woraufhin die Tool-Ausführungskomponente ein gemeinsam genutztes Zahlungsdienstkonto für die Durchführung der Rückerstattung verwendete. Dem Antragsteller fehlte zwar die Berechtigung für Rückerstattungen, doch das Backend überprüfte den Antragsteller zum Zeitpunkt der Ausführung nicht. Es waren weder Malware noch gestohlene Zugangsdaten erforderlich. Nicht vertrauenswürdiger Ticket-Text gelangte in die Agenten-Schleife und löste einen privilegierten Vorgang aus, den die Anwendung bereitgestellt hatte.
Dieser Fehler kombiniert Prompt Injection – wobei nicht vertrauenswürdiger Text das modellgesteuerte Verhalten einer Anwendung verändert – mit Excessive Agency (übermäßiger Handlungsbefugnis), bei der die Anwendung diesem Verhalten Befugnisse einräumt, die über die Rechte des ursprünglichen Mitarbeiters hinausgehen. OWASP bezeichnet diese Schwachstellen in seinem Leitfaden für 2025 (veröffentlicht vom OWASP GenAI Security Project im November 2024) als LLM01 Prompt Injection und LLM06 Excessive Agency. Der Wortlaut eines Prompts kann keine Rückerstattung autorisieren, da das Modell lediglich Text erzeugt; der Server entscheidet, ob eine Zahlungsaktion tatsächlich ausgeführt wird.
Die Rückerstattung wurde durchgeführt, weil Ledgerline zuließ, dass eine Anfrage mehrere Vertrauensgrenzen überschritt, ohne die Identität des Initiators beizubehalten. Eine Nachricht eines Mitarbeiters gilt als nicht vertrauenswürdig. Ein abgerufenenes Support-Dokument ist ebenfalls nicht vertrauenswürdig, selbst wenn es von Ledgerline gespeichert wurde. Das Ergebnis eines Tools stellt eine nicht vertrauenswürdige Eingabe für den nächsten Modellaufruf dar. Auch die Modellausgabe ist nicht vertrauenswürdig, da eine vorgeschlagene refund-Aktion (Rückerstattung) keinen Beleg dafür liefert, dass der Mitarbeiter diese Aktion tatsächlich durchführen darf.
Die Assistant-API authentifiziert den Mitarbeiter, bevor der Prompt zusammengestellt wird. Eine Abrufberechtigung beschränkt den Zugriff auf Dokumente, die zum Mandanten (Tenant) und zu den Berechtigungen des Mitarbeiters gehören, bevor der Dokumententext in den Prompt integriert wird. Die Tool-Ausführungskomponente empfängt die authentifizierte Identität sowie die angeforderten Parameter und setzt die Richtlinie für die Aktion durch, bevor sie das Zahlungssystem kontaktiert. Das Audit-Protokoll zeichnet die Identität, die angeforderte Aktion, die Entscheidung und das Ergebnis auf. Der Modellanbieter generiert zwar eine mögliche Aktion, erteilt jedoch niemals die Berechtigung zu deren Ausführung. Der Anfragepfad macht jede Grenze sichtbar:
Der Prozess trennt die Textverarbeitung von der Autorisierung. Die Authentifizierung kann einen unbekannten Aufrufer abweisen, der Abrufprozess kann einen unzulässigen Kundendatensatz zurückhalten, und die Tool-Schnittstelle kann eine Rückerstattung verweigern, selbst wenn das Modell diese nachdrücklich empfiehlt. Ein Audit-Eintrag kann die Aktion zwar nicht verhindern, ermöglicht es Ledgerline jedoch festzustellen, welcher Akteur (Principal), welche Richtlinienentscheidung und welche Parameter zu dem Ergebnis geführt haben.
Da jede Schnittstelle (Boundary) auf eine andere Fehlerart reagiert, gibt Ledgerline einen konsistenten Status-Vertrag zurück, anstatt jede Ablehnung als Modellfehler zu behandeln. 401 Unauthorized bedeutet, dass die Anfrage fehlende, ungültige, widerrufene oder kompromittierte Zugangsdaten aufweist. 403 Forbidden bedeutet, dass einem authentifizierten Mitarbeiter die erforderliche Berechtigung fehlt – etwa bei der Beantragung einer Rückerstattung ohne entsprechende Befugnis oder beim Versuch, Daten außerhalb der eigenen Berechtigungen abzurufen.
Andere Phasen nutzen spezifischere Ergebnisse:
409 Conflict bedeutet, dass die erste Anfrage mit einem bestimmten Idempotenz-Schlüssel noch läuft.422 Unprocessable Content bedeutet, dass die Modellausgabe nicht dem von Ledgerline geforderten Aktionsschema entspricht oder ein Idempotenz-Schlüssel mit anderen Parametern wiederverwendet wurde.429 Too Many Requests (zusammen mit Retry-After) bedeutet, dass ein Mandant (Tenant) ein Raten- oder Ausgabenlimit ausgeschöpft hat.503 Service Unavailable bedeutet, dass Ledgerline einen erforderlichen Zähler nicht durchsetzen kann oder ein aktiver Circuit Breaker den Aufruf eines Anbieters blockiert.504 Gateway Timeout bedeutet, dass der Modellanbieter das von Ledgerline vorgegebene Zeitlimit überschritten hat.Ein Statuscode identifiziert die Schnittstelle, die die Entscheidung getroffen hat. Wird eine Kundensuche vor der Zusammenstellung des Prompts abgelehnt, gibt Ledgerline 403 Forbidden zurück; kein abgerufenes Dokument gelangt zum Anbieter. Enthält eine vorgeschlagene Rückerstattung fehlerhafte Parameter, meldet der Server 422 Unprocessable Content, bevor die Tool-Ausführungskomponente den Zahlungsdienst kontaktiert. Durch diese Ergebnisse wird die Ablehnung zu einem beobachtbaren Backend-Verhalten und nicht bloß zu einem Satz innerhalb eines System-Prompts.
Regel zur Autorisierung Eine gemeinsame Dienst-Identität (Shared Service Identity) darf eine Anfrage zwar übertragen, sie darf jedoch nicht den Mitarbeiter-Akteur (Principal) ersetzen, der zur Autorisierung der Aktion dient.
Der beschriebene Vorfall ist ein klassisches Beispiel für das „Confused Deputy“-Problem (einen „verwirrten Stellvertreter“). Die für Rückerstattungen zuständige Komponente von Ledgerline verfügte über umfassende Dienstberechtigungen und nutzte diese im Auftrag eines Mitarbeiters, der selbst nicht über die entsprechende Berechtigung verfügte. Zwar kann die Zahlungs-API die Dienstberechtigungsnachweise von Ledgerline validieren, doch kann sie die fehlende Berechtigung des Mitarbeiters nicht nachträglich feststellen, sofern Ledgerline diese Identitätsinformation nicht selbst übermittelt und prüft. Würde man die Kontrolle auf die Phase der Prompt-Erstellung vorverlegen, könnten nachfolgende Texte, Tool-Ergebnisse oder Modellausgaben die geplante Aktion noch verändern.
Die zuverlässige Kontrollinstanz ist der serverseitige Tool-Handler; dort liegen Ledgerline beide für eine Entscheidung erforderlichen Informationen vor: die Identität des authentifizierten Mitarbeiters und die konkreten Parameter der Rückerstattung. Prompt-Regeln können zwar das Verhalten des Modells steuern und der Anbieter kann einen potenziellen Tool-Aufruf vorschlagen, doch keiner dieser Mechanismen setzt die Autorisierungsrichtlinie von Ledgerline verbindlich durch. An welcher Stelle sollte die Rückerstattung für das Jira-Ticket also gestoppt werden: bei den Prompt-Regeln, beim Modell, beim Tool-Handler oder bei der Zahlungs-API?