So stattet man einen KI-Agenten mit einem Wallet aus, ohne dabei pleite zu werden

Stellen Sie sich vor, Sie haben einen KI-Assistenten beauftragt, ein seltenes Buch zu bestellen, einen Server zu bezahlen oder eine Konferenzkarte zu kaufen. Das Skript erreicht das Zahlungsformular, und dann – Sackgasse. Es ist beängstigend, einem Agenten die Details Ihrer Hauptkarte zu übergeben: Eine Halluzination oder ein fehlerhafter Parser, und das Geld geht dorthin, wo es nicht hingehört. Wenn Sie eine Person zwingen, jeden Checkout manuell auszufüllen, widerspricht das dem Zweck der Automatisierung.

Stripe-Ingenieure haben ein interessantes Werkzeug namens link-cli veröffentlicht. Es löst dieses Problem durch Link Wallet, indem es Einweg-virtuelle Karten oder Token für bestimmte Transaktionen erst nach Bestätigung durch den Besitzer ausgibt.

In diesem Artikel erfahren Sie, wie das Tool funktioniert, wie Sie es über das MCP-Protokoll mit einem LLM verbinden und welche Fallstricke Sie vermeiden sollten.

So funktioniert der Prozess

Der gesamte Workflow dreht sich um die Spend-Request-Entität. Der Agent hat keinen Zugriff auf Ihr Bankkonto und sieht niemals gespeicherte Karten.

Der Ablauf ist unkompliziert:

1. Der Agent analysiert die Shop-Seite, erstellt einen Warenkorb und sammelt Bestellparameter.
2. Über die CLI wird eine Kaufanfrage erstellt, die den Händler, den Betrag und einen detaillierten Kontext angibt, der den Zweck der Ausgabe erklärt.
3. Eine Push-Benachrichtigung wird auf Ihrem Telefon in der Link-App angezeigt und fordert zur Bestätigung auf.
4. Nach der Genehmigung empfängt die CLI eine temporäre virtuelle Karte oder ein Token.
5. Der Agent fügt die generierten Anmeldedaten in das Zahlungsformular ein und schließt den Kauf ab.

Der --context-Parameter dient nicht nur zur Zierde. Stripe erfordert eine detaillierte Beschreibung von mindestens 100 Zeichen, damit Sie in der Push-Benachrichtigung genau wissen, wofür die Gebühr bestimmt ist. Die Bestätigung muss innerhalb von genau 10 Minuten erfolgen, danach läuft die Anfrage ab.

Anmeldedatenformate

Das Dienstprogramm kann je nach Zahlungsort und -art drei verschiedene Zahlungsdatenformate zurückgeben.

Die erste Option ist eine Standard-Einweg-virtuelle Karte (PAN). Sie funktioniert mit jedem Online-Shop, der ein Standard-HTML-Checkout-Formular verwendet, selbst wenn die Website noch nie von Stripe gehört hat.

Die zweite Option ist ein Shared Payment Token (SPT). Dies ist für Szenarien gedacht, in denen der Händler das Machine Payments Protocol (MPP) unterstützt. Hier erfolgt die Zahlung programmatisch über HTTP 402, ohne Browser-Dateneingabe zu emulieren.

Die dritte Option ist ein Link Pay Token (LPT). Wenn der Checkout auf Stripe läuft und die Seite einen speziellen Block für KI-Agenten enthält, generiert die CLI ein Token, das direkt mit dem Händlerkonto verknüpft ist.

Logs-Sicherheit und Arbeit mit MCP

Das Hauptproblem beim Umgang mit Zahlungen in LLMs ist das Abfließen von Anmeldedaten. Wenn das Dienstprogramm die vollständige Kartennummer und den CVC an stdout ausgibt, verbleiben diese Daten im Kontext des Modells, in System-Prompts, Terminal-Logs und Agent-Transkripten.

Die Entwickler von Stripe haben dies mit dem --output-file-Argument umgangen. Der Befehl speichert vollständige Kartendaten in einer lokalen Datei mit 0600-Zugriffsberechtigungen, während maskierte JSON-Daten an die Standardausgabe ausgegeben werden:

Der Agent nimmt den Dateipfad, übergibt ihn an einen internen Browser-Runner wie Playwright, und nur die Kartenmarke und die letzten vier Ziffern verbleiben in den Logs.

Für die Integration mit Frameworks wie Claude Code oder Cursor kann das Dienstprogramm als MCP-Server (Model Context Protocol) ausgeführt werden:

Wenn der Agent in einem isolierten Container oder auf einem Remote-Server läuft, startet der link-cli serve-Befehl einen lokalen HTTP-Endpunkt für MCP.

Übrigens wird für die Kommunikation mit Sprachmodellen standardmäßig das toon-Format verwendet. Dies ist eine kompakte Textausgabe ohne JSON-Syntax-Rauschen, die Tokens im Kontextfenster spart.

Limits und Einschränkungen

Das Tool befindet sich in einem frühen Stadium, daher hat das Stripe-Team strenge Sicherheitsgrenzen eingebaut:

• Der maximale Einzelkaufbetrag ist auf 500 $ (50.000 Cents) begrenzt.
• Das tägliche Ausgabenlimit beträgt ebenfalls 500 $, mit einer monatlichen Obergrenze von 20.000 $.
• Ausgestellte Karten oder Tokens sind nur 12 Stunden ab dem Zeitpunkt der Anfrageerstellung aktiv.
• Es können nicht mehr als 10 bestätigte aktive Anfragen gleichzeitig existieren.

Für lokale Experimente und Integrationstests gibt es den --test-Flag. Es generiert Testkartennummern (zum Beispiel 4000009990001984) und bucht keine echten Gelder vom Link-Konto ab.

Wo dies anwendbar ist

Das Dienstprogramm wurde für eine spezifische Nische entwickelt: autonome Skripte und Assistenten, die regelmäßig Transaktionen im Auftrag einer Person ausführen müssen.

Typische Anwendungsfälle:

• Persönliche Agenten für den Kauf von Verbrauchsmaterialien, Buchung von Tickets oder Abonnements.
• Automatische Kontostandsauffüllungen in Cloud-Diensten und Drittanbieter-APIs, wenn Limits erreicht werden.
• Bezahlung von Premium-Endpunkten über das Machine Payments Protocol (HTTP 402).
• Lasttests und End-to-End-Tests von E-Commerce-Checkouts.

Nach einem Zahlungsversuch kann der Agent ein Ergebnis über link-cli report melden und den Status angeben (Erfolg, CAPTCHA, Cloudflare-Block oder Bankablehnung). Dies hilft, Fehlerstatistiken zu sammeln.

Das link-cli-Projekt ist eng spezialisiert, aber es adressiert eine reale Sicherheitslücke in autonomen Agenten. Anstatt private Schlüssel und Anmeldedaten zu teilen, erhält der Entwickler ein kontrolliertes Gateway mit Bestätigung jedes Schritts über das Smartphone.

Der größte Nachteil im Moment: Das Tool funktioniert nur mit US-basierten Link-Konten. Wenn Sie Zugang zu US Link haben, können Sie das Tool jetzt über npx @stripe/link-cli onboard testen. Alle anderen müssen den TypeScript-Quellcode im Repository studieren und auf eine geografische Erweiterung warten.