Jak dać agentowi AI portfel, nie tracąc przy tym pieniędzy

Wyobraź sobie, że zleciłeś asystentowi AI zamówienie rzadkiej książki, opłacenie serwera lub zakup biletu na konferencję. Skrypt dociera do formularza płatności i... martwy punkt. Przekazanie danych głównej karty agentowi jest przerażające: jedna halucynacja lub błędny parser, a pieniądze trafią gdzieś, gdzie nie powinny. Zmuszanie człowieka do ręcznego wypełniania każdej kasy płatniczej mija się z celem automatyzacji.

Inżynierowie Stripe udostępnili interesujące narzędzie o nazwie link-cli. Rozwiązuje ono ten problem poprzez portfel Link, emitując jednorazowe karty wirtualne lub tokeny dla konkretnych transakcji dopiero po potwierdzeniu przez właściciela.

W tym artykule omówimy, jak działa to narzędzie, jak połączyć je z LLM za pomocą protokołu MCP oraz na jakie pułapki należy uważać.

Jak działa proces

Cały przepływ pracy kręci się wokół encji żądania wydatków. Agent nie ma dostępu do Twojego konta bankowego i nigdy nie widzi zapisanych kart.

Przepływ jest prosty:

1. Agent analizuje stronę sklepu, tworzy koszyk i gromadzi parametry zamówienia.
2. Przez CLI tworzone jest żądanie zakupu określające sprzedawcę, kwotę i szczegółowy kontekst wyjaśniający cel wydatku.
3. Powiadomienie push trafia na Twój telefon w aplikacji Link z prośbą o potwierdzenie.
4. Po zatwierdzeniu CLI otrzymuje tymczasową kartę wirtualną lub token.
5. Agent wstawia wygenerowane dane do formularza płatności i kończy zakup.

Parametr --context nie jest tylko na pokaz. Stripe wymaga szczegółowego opisu o długości co najmniej 100 znaków, abyś dokładnie wiedział, za co dokonuje się opłaty w powiadomieniu push. Potwierdzenie musi nastąpić w ciągu dokładnie 10 minut, po czym żądanie wygasa.

Formaty danych uwierzytelniających

Narzędzie może zwracać trzy typy danych płatniczych w zależności od tego, gdzie i jak agent dokonuje płatności.

Pierwsza opcja to standardowa jednorazowa karta wirtualna (PAN). Działa z dowolnym sklepem internetowym używającym standardowego formularza płatności HTML, nawet jeśli strona nigdy nie słyszała o Stripe.

Druga opcja to Shared Payment Token (SPT). Jest to rozwiązanie dla scenariuszy, w których sprzedawca obsługuje Machine Payments Protocol (MPP). Tutaj płatność odbywa się programowo przez HTTP 402 bez emulacji wprowadzania danych w przeglądarce.

Trzecia opcja to Link Pay Token (LPT). Jeśli strona płatności działa na Stripe i zawiera specjalny blok dla agentów AI, CLI generuje token bezpośrednio powiązany z kontem sprzedawcy.

Bezpieczeństwo logów i praca z MCP

Główny ból głowy przy obsłudze płatności w LLM to wyciek danych uwierzytelniających. Jeśli narzędzie wyprowadza pełny numer karty i CVC do stdout, te dane pozostaną w kontekście modelu, promptach systemowych, logach terminala i transkryptach agenta.

Programiści Stripe obejśli ten problem za pomocą argumentu --output-file. Polecenie zapisuje pełne dane karty do pliku lokalnego z uprawnieniami 0600, jednocześnie wyprowadzając zamaskowany JSON na standardowe wyjście:

Agent pobiera ścieżkę pliku, przekazuje ją do wewnętrznej przeglądarki jak Playwright, a w logach pozostają tylko marka karty i ostatnie cztery cyfry.

Do integracji z frameworkami jak Claude Code czy Cursor, narzędzie może działać jako serwer MCP (Model Context Protocol):

Jeśli agent działa w izolowanym kontenerze lub na zdalnym serwerze, polecenie link-cli serve uruchamia lokalny punkt końcowy HTTP dla MCP.

Przy okazji, do komunikacji z modelami językowymi domyślnie używany jest format toon. To zwięzły tekst wyjściowy bez szumu składni JSON, który oszczędza tokeny w oknie kontekstowym.

Limity i ograniczenia

Narzędzie jest we wczesnym stadium, więc zespół Stripe wbudował ścisłe granice bezpieczeństwa:

• Maksymalna kwota pojedynczego zakupu jest ograniczona do 500 USD (50 000 centów).
• Dzienny limit wydatków również wynosi 500 USD, z miesięcznym limitem 20 000 USD.
• Wystawione karty lub tokeny są aktywne tylko przez 12 godzin od momentu utworzenia żądania.
• Jednocześnie może istnieć nie więcej niż 10 potwierdzonych aktywnych żądań.

Dla lokalnych eksperymentów i testów integracyjnych dostępna jest flaga --test. Generuje ona testowe numery kart (na przykład 4000009990001984) i nie obciąża prawdziwych środków z konta Link.

Gdzie to znajduje zastosowanie

Narzędzie zostało stworzone dla konkretnej niszy: autonomicznych skryptów i asystentów, którzy okresowo muszą wykonywać transakcje w imieniu osoby.

Typowe przypadki użycia:

• Osobisti agenci do zakupu materiałów eksploatacyjnych, rezerwacji biletów lub subskrypcji.
• Automatyczne doładowania sald w usługach chmurowych i zewnętrznych API po osiągnięciu limitów.
• Płatności za premium endpointy przez Machine Payments Protocol (HTTP 402).
• Testowanie obciążeniowe i end-to-end kas płatniczych e-commerce.

Po próbie obciążenia agent może wysłać raport wyników przez link-cli report, wskazując status (sukces, CAPTCHA, blokada Cloudflare lub odrzucenie banku). Pomaga to zbierać statystyki niepowodzeń.

Projekt link-cli jest wąsko wyspecjalizowany, ale adresuje realną lukę bezpieczeństwa w autonomicznych agentach. Zamiast udostępniać klucze prywatne i dane uwierzytelniające, deweloper otrzymuje kontrolowaną bramkę z potwierdzeniem każdego kroku przez smartfon.

Główna wada na ten moment: narzędzie działa tylko z kontami Link w USA. Jeśli masz dostęp do amerykańskiego Link, możesz przetestować narzędzie od razu przez npx @stripe/link-cli onboard. Wszyscy inni będą musieli przestudiować kod źródłowy TypeScript w repozytorium i poczekać na rozszerzenie geograficzne.