KI-Agenten & programmierbares Geld

Ein Armaturenhersteller lässt einen KI-Agenten Verbrauchsmaterial nachbestellen: Dichtungen, Schleifmittel, Prüfgas. Der Agent vergleicht Angebote, legt den Warenkorb an und bezahlt beim Händler mit einem Kartentoken. Daneben ruft er für die Bedarfsplanung eine Schnittstelle mit Rohstoffpreisen ab, die je Abruf ein paar Cent in einem Stablecoin verlangt. Das Beispiel ist erdacht, beide Zahlungswege gibt es aber schon. Für den Finanzchef stellt sich zweimal dieselbe Frage, nämlich wer diese Zahlungen freigegeben hat und wo ihre Grenze steht.

Im Zahlungsrecht gibt es keinen Agenten

Ein Zahlungsvorgang wirkt gegenüber dem Zahler nur, wenn er ihm zugestimmt hat (§ 675j Abs. 1 BGB). Wie er zustimmt, vereinbaren Zahler und Zahlungsdienstleister. Die europäische Grundlage, die Zahlungsdiensterichtlinie PSD2, lässt die Zustimmung auch über den Zahlungsempfänger oder einen Zahlungsauslösedienst zu (Art. 64 Abs. 2). Einen Agenten als eigene Rolle kennt keine dieser Normen. Auch die neue Zahlungsdiensteverordnung (PSR), auf die sich Rat und Parlament im November 2025 politisch geeinigt haben, regelt ihn nicht. Künstliche Intelligenz erwähnt ihr Text nur bei der Betrugserkennung, verabschiedet ist sie noch nicht (Stand Oktober 2026).

Zahler bleibt also das Unternehmen. Ob eine Zahlung, die sein Agent mit den Zugangsdaten des Unternehmens auslöst, als zugestimmt gilt, sagt keine Norm ausdrücklich. Das hängt an der Vereinbarung mit der Bank und gehört in die rechtliche Prüfung, bevor ein Agent ein Zahlungsmittel bekommt. Klar ist dagegen, was die Bank verlangt. Löst der Zahler eine elektronische Zahlung aus, braucht es eine starke Kundenauthentifizierung (Art. 97 PSD2), also zwei unabhängige Merkmale aus Wissen, Besitz und Inhärenz. Ein Agent, der ohne Menschen zahlen soll, braucht deshalb einen Weg, auf dem diese Prüfung vorher oder an anderer Stelle stattfindet.

Die Grenze steht in der Zahlungsanweisung

Die Anbieter von Zahlungswegen für Agenten lösen das Freigabeproblem auf ähnliche Weise. Googles Agent Payments Protocol (AP2) arbeitet mit einem Zahlungsmandat, das der Nutzer unterschreibt. Es kann die zulässigen Empfänger, eine Betragsspanne und ein Gesamtbudget festlegen. Beim Agentic Commerce Protocol von OpenAI und Stripe erhält der Agent ein Zahlungstoken, das auf einen Händler und einen Warenkorbwert begrenzt ist und nur einmal gilt. Visa und Mastercard haben im April 2025 eigene Token für Agenten vorgestellt. Coinbase bietet Wallets für Agenten mit Obergrenzen je Sitzung und je Zahlung an; laut Dokumentation kann der Agent diese Grenzen nicht ändern. Viele dieser Verfahren sind noch in Erprobung (Stand Oktober 2026).

Das gemeinsame Muster ist eine Trennung. Der Agent entscheidet innerhalb eines Rahmens, den ein Mensch vorher gesetzt hat, und das Zahlungsmittel selbst trägt diesen Rahmen. Überschreitet der Agent ihn, lehnt nicht er die Zahlung ab, sondern das Token oder die Wallet. Geprüft wird damit nicht mehr jede einzelne Zahlung, sondern die Festlegung des Rahmens. Wo eine solche Regel sitzt und wer sie danach noch ändern kann, ist in Programmierbarkeit von digitalem Geld beschrieben.

x402: Bezahlen im Protokoll des Webs

Für den zweiten Fall im Beispiel, die Preisschnittstelle, gibt es einen eigenen Ansatz. x402 nutzt den HTTP-Statuscode 402 „Payment Required“. Der Server beantwortet eine Anfrage mit diesem Code und nennt seine Zahlungsbedingungen. Der Client schickt die Anfrage erneut, mit einer signierten Zahlung im Kopf der Anfrage. Ein Dienstleister, der sogenannte Facilitator, prüft die Zahlung und wickelt sie auf der Blockchain ab, zum Beispiel in USDC. Coinbase hat das Protokoll eingebracht, seit dem 14. Juli 2026 liegt es bei einer Stiftung unter dem Dach der Linux Foundation.

Die Netzgebühr trägt beim Verfahren für Ethereum-kompatible Netze der Facilitator, nicht der Zahler. Wie eine Gebühr zu buchen ist, die ein Dritter übernimmt, ist in Buchung, Bewertung & Steuer beschrieben. Für den Finanzchef wichtiger ist ein Satz aus der Spezifikation: Budgets und Ausgabengrenzen regelt x402 ausdrücklich nicht, sie bleiben Sache der Implementierung. Wer einen Agenten über x402 zahlen lässt, muss die Grenze also selbst bauen, in der Wallet oder davor.

Eine Liste, die das Recht schon kennt

Der Gedanke, den Rahmen statt der einzelnen Zahlung freizugeben, ist im Zahlungsrecht nicht neu. Die technischen Regulierungsstandards zur starken Kundenauthentifizierung, die Delegierte Verordnung (EU) 2018/389, kennen eine Liste vertrauenswürdiger Empfänger. An Empfänger auf dieser Liste darf die Bank ohne starke Authentifizierung zahlen (Art. 13). Wer die Liste anlegt oder ändert, muss sich dagegen stark authentifizieren. Für Unternehmen gibt es eine zweite Ausnahme: gesicherte Zahlungsprozesse, die nur Nicht-Verbrauchern offenstehen, wenn die Aufsicht sie für mindestens gleich sicher hält (Art. 17).

Das Recht setzt den Menschen damit an dieselbe Stelle wie die Protokolle der Agenten, an die Änderung der Liste und nicht an die einzelne Zahlung. Übertragen auf das Beispiel zahlt der Agent nur an Händler, die der Einkauf freigegeben hat. Einen neuen Händler aufzunehmen bleibt eine Handlung eines Menschen, mit starker Authentifizierung.

Wo das Risiko liegt

Das erste Risiko ist die Haftung. Für Verbraucher begrenzt das Gesetz den Schaden aus einer nicht autorisierten Zahlung (§ 675v BGB). Bei Unternehmen können Bank und Kunde diese Regel ganz oder teilweise ausschließen (§ 675e Abs. 4 BGB). Ob der eigene Vertrag mit der Bank einen solchen Ausschluss enthält, sollte der Finanzchef wissen, bevor ein Agent zahlt.

Das zweite Risiko ist die Manipulation. Ein Agent liest Webseiten, Angebote und Dateien, und diese Inhalte können ihn steuern. Die OWASP-Liste der Risiken von Anwendungen mit Sprachmodellen führt diese Prompt-Injection in ihrer Fassung 2025 an erster Stelle, auch in der indirekten Form über fremde Inhalte. Ein präpariertes Angebot könnte einen Agenten dazu bringen, an einen anderen Empfänger zu zahlen. Dagegen hilft keine Anweisung an den Agenten, sondern eine Grenze, die er nicht ändern kann: die Empfängerliste im Mandat oder in der Wallet.

Das dritte Risiko ist die Identität. Ein Händler sieht eine Anfrage, aber nicht, wessen Agent sie stellt. Ein Gastbeitrag bei a16z crypto hat diese Lücke im Januar 2026 „Know Your Agent“ genannt, in Anlehnung an die Kundenprüfung KYC. Visa hat im Oktober 2025 mit dem Trusted Agent Protocol einen Ansatz vorgestellt, mit dem ein Agent seine Identität kryptografisch nachweist. Ob sich einer dieser Ansätze durchsetzt, ist offen.

Das Mandat als Freigabebeleg

In der Buchhaltung bleibt jede Zahlung eines Agenten eine Zahlung des Unternehmens, mit Beleg, Konto und Kostenstelle. Neu ist, was als Freigabe gilt. Bisher zeichnete ein Mensch die einzelne Bestellung oder den Zahllauf ab. Bei einem Agenten zeichnet er den Rahmen: ein Mandat mit Empfängern, Betragsspanne und Budget, unterschrieben und befristet. Das Vier-Augen-Prinzip wandert damit von der Zahlung zum Mandat.

Für die Prüfung verschiebt sich die Frage entsprechend. Gefragt wird nicht mehr, wer eine Zahlung freigegeben hat, sondern unter welchem Mandat sie lief und wer dieses Mandat gezeichnet hat. Beantworten lässt sich das nur, wenn jede Zahlung die Kennung ihres Mandats bis in die Buchung mitführt, so wie heute die Rechnungsnummer im Verwendungszweck. Wie eine Zahlung ihre Referenz in den Abgleich trägt, ist in Abgleich & Zahlungsflüsse beschrieben.