Skip to main content
Anwendungsfall

Ein Agent darf zahlen — aber nicht heimlich: fünf deterministische Kontrollen zwischen Absicht und Geld

Ein Zahlungsdienstleister lässt einen Support-Agenten Rückerstattungen über Wero auslösen — die Wallet der European Payments Initiative, abgewickelt über SEPA Instant. Der legitime Fall über 240,00 € durchläuft jede Prüfung und endet trotzdem mit HTTP 403: Der Agent kann nicht zahlen, er kann beantragen. Dann trägt dieselbe Konversation eine versteckte Anweisung über 48.500,00 €. Das Modell fällt darauf herein — bewegt werden 0,00 €.

5
deterministische Kontrollen im Aufrufpfad — keine davon ein Prompt
0,00 €
bewegt bei der Prompt-Injection über 48.500 € — abgelehnt ist abgelehnt
Einmal
gilt eine Freigabe: an Server und Tool gebunden, nach dem Aufruf verbraucht
Gerenderte DarstellungSimuliertes SzenarioKeine realen Gelder transferiert
Demo in Deutsch, Englisch und Spanisch
Die Ausgangslage

Die Frage ist nicht, ob ein Agent eine Zahlung auslösen kann — das kann jeder LLM-Stack seit Jahren. Die Frage ist, was passiert, wenn das Modell überredet wird. Für eine Bank ist ein Agent, dessen Grenze in einem System-Prompt steht, kein Produkt, sondern ein Prüfungsbefund: Wer die Grenze verschieben will, braucht dann nur einen besseren Prompt.

So funktioniert es
1

Der legitime Fall endet mit 403

240,00 € Rückerstattung: Agent-Bindung, Tool-Allowlist und Policy-Gate sind grün, die Sicherheitsklasse stuft das Werkzeug als destruktiv ein — der Aufruf endet mit HTTP 403 und einer Freigabe-Anfrage. Der Agent kann beantragen, nicht zahlen.

2

Die Prompt-Injection scheitert am Policy-Gate

Dieselbe Konversation, versteckte Anweisung über 48.500,00 €. Die Demo zeigt ehrlich, dass das Modell darauf hereinfällt. Das Policy-Gate wertet Betrag, Währung und Korridor mit den echten Argumenten aus — deterministisch und fail-closed — und lehnt ab. Weil es vor dem Freigabe-Gate steht, entsteht keine Pending-Zeile: kein Klick kann das Limit aufheben, und im UI steht ein roter Block ohne Bestätigen-Knopf.

3

Freigabe, Ausführung, Beweis

Ein Mensch gibt frei. Die Freigabe erzeugt ein Einmal-Token, gebunden an genau diesen Server und dieses Werkzeug, mit Verfallszeit. Erst dann bewegt sich Geld. Der zweite Aufruf verlangt erneut eine Freigabe, weil das Token verbraucht ist. Danach greifen Durchsatzgrenze und Audit-Schreib.

Im Produkt
Reale SystemdemoSimuliertes SzenarioKeine realen Gelder transferiert
Das Ergebnis
5
deterministische Kontrollen im Aufrufpfad — keine davon ein Prompt
0,00 €
bewegt bei der Prompt-Injection über 48.500 € — abgelehnt ist abgelehnt
Einmal
gilt eine Freigabe: an Server und Tool gebunden, nach dem Aufruf verbraucht
Worauf es fußt

Echt sind die fünf Kontrollen und ihre Reihenfolge, die Einmal-Token-Semantik samt Server- und Werkzeugbindung, die Fail-closed-Eigenschaft und die Tatsache, dass ein policy-abgelehnter Aufruf keine Freigabe-Zeile erzeugt. Beispiel sind der Zahlungsdienstleister sowie alle Beträge, Namen und IBANs: Der Konnektor der Demo ist eine Sandbox und bewegt kein echtes Geld. Daneben steht ein echter Wero-Konnektor unter Integrationen — eine öffentliche Wero-API gibt es nicht, deshalb spricht er ISO 20022 pain.001 gegen das Gateway Ihrer Bank oder Ihres PSP und liest pain.002 für den Status. Er ruht, bis Endpunkt, Auftraggeber und Zugangsdaten hinterlegt sind.

Demo anfragen

Sehen Sie es an Ihrem eigenen Use Case.

30 Minuten, zugeschnitten auf Ihre Branche, Frameworks und Integrationen. Sie gehen mit einem konkreten Szenario — nicht mit einer Verkaufsschleife.