MCP a płatności agentowe — jak agent dostaje narzędzie do zapłaty

Model Context Protocol (MCP) to otwarty standard, który pozwala podłączyć do modelu językowego zewnętrzne narzędzia i akcje w jednolity sposób. Coraz częściej pojawia się pytanie, czy „zapłać” może być takim narzędziem — i co to oznacza dla bezpieczeństwa pieniędzy.

W skrócie: MCP nie jest protokołem płatności. To sposób, w jaki agent dowiaduje się, że ma do dyspozycji narzędzie typu pay, i w jaki sposób je wywołuje. Sama transakcja, autoryzacja i kontrola limitu dzieją się poza modelem — w serwerze narzędzia i u dostawcy płatności. Model jedynie prosi o płatność; nigdy nie powinien być jedynym podmiotem, który decyduje, czy ją wykonać.

Czym właściwie jest MCP?

MCP, opisany w dokumentacji modelcontextprotocol.io, rozwiązuje prosty problem: jak w ustandaryzowany sposób dać modelowi dostęp do funkcji świata zewnętrznego. Zamiast budować osobną integrację pod każdy model i każde narzędzie, stawiasz serwer MCP, który wystawia listę narzędzi z opisem i schematem parametrów. Klient (aplikacja prowadząca agenta) podłącza się do serwera, pobiera tę listę i przekazuje ją modelowi.

Gdy model uzna, że chce użyć narzędzia, zwraca ustrukturyzowane wywołanie: nazwę narzędzia plus argumenty. Klient przekazuje je do serwera, serwer wykonuje akcję i odsyła wynik. To wszystko. MCP to warstwa transportu i opisu narzędzi, a nie logika biznesowa tych narzędzi.

Dlatego płatność świetnie się w ten model wpisuje — ale tylko jako jedno z wielu możliwych narzędzi, nie jako serce protokołu.

Jak „zapłać” staje się narzędziem MCP?

Wyobraź sobie serwer MCP wystawiony przez dostawcę płatności albo platformę zakupową. Wśród narzędzi, obok search_products czy get_cart, pojawia się narzędzie pay z opisanym schematem parametrów:

• amount — kwota,
• currency — waluta,
• payee — odbiorca,
• order_reference — identyfikator zamówienia,
• ewentualnie mandate_id — odwołanie do wcześniej wydanego mandatu.

Agent realizujący zadanie użytkownika („kup mi te słuchawki do 400 zł”) dochodzi do momentu finalizacji i emituje wywołanie pay z konkretnymi argumentami. Klient odbiera to wywołanie i przekazuje je do serwera narzędzia.

I tutaj zaczyna się część, która decyduje o bezpieczeństwie: co robi serwer, zanim cokolwiek obciąży kartę.

Dlaczego autoryzacja i limity muszą być poza modelem?

To jest sedno całego tematu. Model językowy jest niedeterministyczny i podatny na manipulację. Treść, którą przetwarza — opis produktu, e-mail, strona internetowa, wynik wcześniejszego narzędzia — może zawierać ukryte instrukcje. To klasyczny atak typu prompt injection: złośliwy tekst próbuje przekonać agenta, żeby zapłacił więcej, komu innemu albo wielokrotnie. Rozwijamy ten wątek w osobnym tekście o zagrożeniach wstrzykiwania poleceń przy transakcjach.

Skoro model można nakłonić do wyemitowania wywołania pay z dowolnymi argumentami, nie może być jedynym strażnikiem limitu. Gdyby kontrola kwoty istniała tylko w prompcie systemowym („nie wydawaj więcej niż 400 zł”), wystarczyłoby jedno sprytne zdanie w treści, żeby ją obejść. Prompt to nie zabezpieczenie — to sugestia.

Dlatego prawdziwa autoryzacja musi siedzieć tam, gdzie atakujący nie sięga przez tekst: w kodzie serwera narzędzia i po stronie dostawcy. Serwer, otrzymawszy wywołanie pay, sprawdza niezależnie:

Kontrola	Gdzie egzekwowana	Czego dotyczy
Limit kwotowy	Serwer narzędzia / dostawca	Czy kwota mieści się w mandacie użytkownika
Tożsamość i mandat	Dostawca płatności	Czy agent ma ważne uprawnienie do płacenia w imieniu użytkownika
Odbiorca	Serwer narzędzia	Czy payee jest na liście dozwolonych albo zgodny z zamówieniem
Częstotliwość	Serwer narzędzia	Limity dzienne, liczba transakcji, wykrywanie powtórzeń
Potwierdzenie	Aplikacja / użytkownik	Czy dla tej kwoty wymagana jest akceptacja człowieka

Model wnioskuje, że chce zapłacić. Serwer decyduje, czy wolno. To rozdzielenie ról jest fundamentem bezpiecznej architektury — opisujemy je szerzej w przewodniku, jak złożyć agenta zdolnego do płacenia.

Mandat zamiast zaufania do modelu

Dobrze zaprojektowany serwer płatniczy nie wierzy modelowi na słowo, że „użytkownik się zgodził”. Zamiast tego operuje na mandacie — uprawnieniu wydanym wcześniej przez użytkownika, z wpisanymi ograniczeniami: maksymalna kwota, dozwolone kategorie odbiorców, okno czasowe, jednorazowość lub cykliczność.

Mandat jest cyfrowo powiązany z tożsamością użytkownika i weryfikowany przez dostawcę, a nie generowany przez model. Gdy przychodzi wywołanie pay, serwer dopasowuje je do mandatu. Jeśli kwota go przekracza albo odbiorca nie pasuje — transakcja jest odrzucana, bez względu na to, jak przekonująco model „uzasadnił” zakup. W praktyce token mandatu bywa też powiązany z konkretnym zamówieniem, żeby agent nie mógł użyć tej samej zgody dwa razy.

Praktyczne zasady projektowania narzędzia płatniczego w MCP

Jeśli budujesz albo wybierasz serwer MCP z funkcją płatności, warto trzymać się kilku reguł:

• Walidacja po stronie serwera jest obowiązkowa. Każdy parametr wywołania pay traktuj jako niezaufane dane wejściowe, tak samo jak dane z formularza w sieci.
• Limity nie żyją w prompcie. Kwoty, odbiorcy i częstotliwość egzekwuje kod, najlepiej na podstawie mandatu weryfikowanego przez dostawcę.
• Człowiek w pętli przy progach ryzyka. Powyżej ustalonej kwoty albo dla nowego odbiorcy wymagaj jawnego potwierdzenia użytkownika, zanim serwer dokończy transakcję.
• Idempotencja i ślad audytowy. Każda płatność z identyfikatorem zamówienia, logiem wywołania i odpowiedzi — to chroni przed powtórzeniami i ułatwia reklamacje.
• Najmniejsze uprawnienia. Serwer płatniczy wystawia tylko te narzędzia, które są naprawdę potrzebne, z możliwie wąskim schematem parametrów.

Co z tego wynika?

MCP to nie magiczny portfel dla agentów, tylko czysty kanał, którym agent prosi o akcję. Bezpieczeństwo płatności agentowych nie powstaje w modelu i nie powstaje w samym protokole — powstaje w warstwie, która stoi między wywołaniem a pieniędzmi. Model proponuje; serwer narzędzia i dostawca rozstrzygają. Kto przeniesie autoryzację i limity do tej warstwy, ten może bezpiecznie dać agentowi narzędzie do zapłaty. Kto zostawi je w prompcie, ten prędzej czy później zapłaci za cudzy pomysł ukryty w opisie produktu.