Agenci AI już płacą w Polsce, a nowe badanie wykryło 33 luki w protokołach agentic commerce — trzy pozwalają złożyć atak prowadzący do przejęcia płatności

AI nie tylko podpowiada już, co kupić. W Polsce wykonano pierwsze uwierzytelnione transakcje, w których agent AI działał w imieniu użytkownika, a europejskie sieci płatnicze przechodzą z demonstracji technologii do transakcji realizowanych w środowiskach produkcyjnych. To nadal nie jest usługa, którą każdy klient banku może dziś włączyć jednym przełącznikiem w aplikacji, ale granica została przekroczona: agent może dojść do etapu, na którym w grę wchodzą prawdziwe pieniądze.

I właśnie w tym momencie pojawia się problem większy niż klasyczny „AI dało się oszukać promptem”. Opublikowane 23 lipca 2026 r. badanie „Protocol-Level Attacks on Agentic Commerce Platforms” opisuje 33 podatności w trzech platformach agentic commerce. Autor pokazał też, że trzy z nich można połączyć w jeden łańcuch kończący się przekierowaniem płatności do portfela napastnika. Co gorsza, zasadnicza część problemu nie znajduje się w samym modelu językowym. Znajduje się niżej — w sposobie, w jaki agent ufa rejestrom usług, przekazuje dane uwierzytelniające, utrzymuje sesję i ustala odbiorcę pieniędzy.

Dla banku, fintechu albo sklepu oznacza to zmianę priorytetów. Lepszy model AI i filtr prompt injection nie wystarczą, jeżeli infrastruktura pozwala agentowi zaakceptować niezweryfikowany adres płatności albo uwierzyć niezaufanej odpowiedzi sieciowej.

Polska przestała być rynkiem wyłącznie testującym pomysł

Pod koniec maja 2026 r. Mastercard poinformował o wykonaniu pierwszych uwierzytelnionych transakcji agentowych w Polsce z wykorzystaniem Mastercard Agent Pay. W pilotażu uczestniczyły mBank, Bank Pekao oraz UniCredit Polska. To ważniejsze niż kolejna prezentacja pokazująca chatbota wyszukującego buty czy hotel: tutaj agent doszedł do części procesu związanej z rzeczywistą autoryzacją płatności.

Równolegle Mastercard poinformował, że na poziomie sieciowym wszyscy europejscy wydawcy Mastercard są przygotowani do Agent Pay, a europejskie banki przeprowadzały kontrolowane transakcje na żywo z wykorzystaniem passkeys. Mechanizm ma zachowywać ślad pozwalający powiązać działanie agenta z konkretną zgodą użytkownika.

Visa poszła podobną drogą. 2 lipca 2026 r. firma ogłosiła realizację transakcji agentowych w środowiskach produkcyjnych w Europie. Agent wyszukiwał produkt, wybierał go i inicjował zakup zgodnie z parametrami zadanymi przez właściciela karty. Na liście wydawców, którzy wykonali takie transakcje, znalazły się między innymi mBank i PKO Bank Polski. Wszystkie transakcje w programie Agentic Ready były zabezpieczane przez Visa Payment Passkeys.

To ostatnie jest istotne w polskich realiach. Europejski rynek płatniczy nie może po prostu przekazać agentowi numeru karty i pozwolić mu robić wszystkiego bez kontroli. Strong Customer Authentication, czyli SCA, nadal wymusza silne uwierzytelnienie w sytuacjach określonych przez PSD2 i przepisy wykonawcze. Dla płatności zdalnych istnieją wyjątki — na przykład zależne od kwoty i analizy ryzyka — ale agent AI nie dostaje automatycznie zwolnienia tylko dlatego, że działa jako oprogramowanie.

W praktyce sensowny model wygląda więc mniej efektownie niż wizja „AI ma moją kartę i kupuje, co trzeba”, ale jest bezpieczniejszy:

• użytkownik określa zakres zadania i limity,
• agent otrzymuje tokenizowane uprawnienie zamiast pełnych danych karty,
• system identyfikuje zarówno użytkownika, jak i działającego agenta,
• operacja finansowa jest związana z konkretną zgodą lub wcześniej ustalonym mandatem,
• bank zachowuje możliwość oceny ryzyka i wymuszenia dodatkowego uwierzytelnienia.

Visa stosuje dodatkowo Trusted Agent Protocol i Agent Directory, aby sklep mógł odróżnić zweryfikowanego agenta zakupowego od zwykłego bota. Sieć podkreśla, że rozwiązanie może współpracować z istniejącą infrastrukturą merchantów oraz systemami Cloudflare i Akamai.

Polski rynek będzie przy tym musiał rozwiązać jeszcze jeden lokalny problem: agentic commerce nie może zatrzymać się na kartach. BLIK jest zbyt ważnym elementem polskiego checkoutu, żeby pozostał poza tym modelem. PPRO poinformowało w sierpniu 2026 r. o partnerstwie z BLIKIEM mającym rozwijać obsługę lokalnych płatności w środowisku agentowym. To dopiero budowa infrastruktury, a nie masowo dostępna funkcja „zapłać BLIKIEM przez agenta”, ale kierunek jest czytelny.

I tu pojawia się pierwsza niedogodność całego modelu. Agentic commerce jest dziś mocno pofragmentowany. Visa rozwija własną warstwę zaufania, Mastercard własne tokeny i Agent Pay, istnieją AP2, x402, MCP, A2A oraz kolejne warstwy pośredniczące. Dla klienta końcowego wszystko ma wyglądać jak jedno polecenie: „kup mi najtańszy lot do Rzymu do 900 zł”. Dla zespołu bezpieczeństwa pod spodem oznacza to kilka rejestrów, tożsamości, protokołów, sesji i punktów decyzyjnych. Każdy jest osobnym miejscem, w którym można zgubić integralność transakcji.

33 podatności pokazują, że problem zaczyna się poniżej modelu AI

Badanie Yedidela Loucka z Ariel University obejmuje trzy rozwiązania: CoralOS, Fetch.ai uAgents i referencyjną implementację Google Agent Payments Protocol AP2 v0.2.0. Łącznie autor sklasyfikował 33 podatności:

• 11 ustaleń dotyczących CoralOS, przy czym liczba obejmuje dziesięć osobnych podatności oraz jeden złożony łańcuch ataku,
• 8 podatności w Fetch.ai uAgents,
• 14 podatności w AP2 v0.2.0.

Nie wszystkie mają identyczną wagę, a badanie jest preprintem, a nie końcowym słowem branży w sprawie bezpieczeństwa agentic commerce. Istotna jest jednak metoda: autor oddziela ataki semantyczne od strukturalnych.

Atak semantyczny próbuje wpłynąć na rozumowanie modelu. Przykład jest dobrze znany: agent czyta złośliwy opis produktu zawierający ukrytą instrukcję i zaczyna wykonywać polecenia napastnika. Skuteczność zależy wtedy między innymi od użytego modelu i jego zabezpieczeń.

Atak strukturalny nie musi przekonywać modelu do niczego. Wykorzystuje fakt, że infrastruktura na przykład:

• przyjmuje niepodpisaną odpowiedź rejestru,
• nie wiąże kryptograficznie odbiorcy płatności z właściwą usługą,
• przesyła lub zapisuje dane uwierzytelniające w miejscu, w którym może je przechwycić inny komponent,
• nieprawidłowo izoluje sesje,
• pozwala na wyścig dwóch operacji sprawdzających ten sam stan płatności.

W takich przypadkach wymiana modelu na „mądrzejszy” niewiele zmienia.

Dobrym przykładem jest wykryta w CoralOS luka związana z federacją. Przy pobieraniu portfela odbiorcy system akceptował adres zwrócony przez zdalny serwer bez kryptograficznego związania go z tożsamością tego serwera. Jeżeli zaufanie do serwera zostało przełamane, można było podstawić portfel napastnika jako beneficjenta escrow.

Fetch.ai miał inny zestaw problemów. W jednym przypadku resolver pobierał z rejestru adres endpointu i nie weryfikował kryptograficznie, czy endpoint rzeczywiście należy do deklarowanego agenta. Badanie opisuje również przechowywanie kluczy prywatnych w niezaszyfrowanym pliku JSON oraz błąd prowadzący do zmiany adresu portfela po restarcie agenta. To ostatnie nie jest efektownym „hackiem”, ale z punktu widzenia użytkownika rezultat może być równie nieprzyjemny: pieniądze trafiają pod adres powiązany z kluczem, którego system później nie ma.

AP2 wygląda na tle tych przykładów dojrzalej, bo jego architektura opiera się na kryptograficznie podpisywanych mandatach opisujących intencję, koszyk i płatność. Mimo tego analiza referencyjnej wersji AP2 v0.2.0 wykazała 14 problemów. Trzy dotyczyły konkretnie implementacji Python i nie występowały w implementacji Go, ale kolejne trzy zostały zakwalifikowane jako luki specyfikacji — związane między innymi z powiązaniem e-maila, świeżością nonce i ograniczeniem odbiorcy płatności.

To praktyczna lekcja dla polskiego banku lub operatora płatności: zgodność ze standardem nie jest równoznaczna z bezpieczną implementacją, a bezpieczna implementacja nie naprawi wszystkiego, jeżeli sam standard pozostawia ważny warunek niewymuszony.

Autor badania przetestował również warstwę ochronną nazwaną PCAT — Protocol-level Commerce Agent Trust. W eksperymentach sprowadzała ona skuteczność czterech z pięciu analizowanych strukturalnych klas ataków do zera; dla problemu obserwowalnych kanałów z danymi uwierzytelniającymi możliwe było jedynie ostrzeganie. To nie znaczy, że PCAT „rozwiązuje bezpieczeństwo agentów”. Pokazuje coś bardziej użytecznego: kontrola wstawiona na granicy protokołu potrafi zatrzymać klasę ataków, której nie zatrzyma nowy model językowy.

Trzy luki wystarczyły, żeby zbudować pełne przejęcie płatności

Najmocniejszą częścią badania nie jest sama liczba 33. Lista podatności zawsze wygląda groźnie, dopóki nie wiadomo, czy da się z niej zbudować realny scenariusz finansowy.

Tutaj się dało.

Autor połączył trzy podatności CoralOS: V5, V4 i V9 w jeden łańcuch prowadzący od manipulacji źródłem danych aż do przekierowania środków.

Pierwszy etap dotyczył łańcucha dostaw i rejestru agentów. Złośliwy marketplace mógł wprowadzić do rejestru spreparowanego agenta obsługującego płatność wraz ze złośliwą instrukcją.

Drugi wykorzystywał wyciek sekretu sesji. Po uruchomieniu takiego agenta jego agentSecret pojawiał się w logach serwera. W demonstracji opisanej w pracy następowało to po 138 ms. Przejęcie tego sekretu dawało napastnikowi możliwość wejścia w aktywną sesję MCP.

Trzeci element uderzał już bezpośrednio w pieniądze. Przy federacji system przyjmował zwrócony przez zdalną usługę adres portfela Solana bez odpowiedniej weryfikacji, dzięki czemu beneficjent escrow mógł zostać podmieniony na portfel atakującego.

W pojedynczym przebiegu badacz uzyskał jednocześnie widoczność sesji MCP, zmianę zachowania agenta i przekierowanie płatności. Co szczególnie niewygodne z punktu widzenia operacyjnego, transakcja mogła wyglądać technicznie poprawnie: podpisy były ważne, system nie musiał się wysypać, a sam model wykonywał czynności zgodne z informacjami dostarczonymi mu przez infrastrukturę.

Dlatego zespoły wdrażające płatności agentowe powinny odwrócić typową kolejność prac bezpieczeństwa.

Priorytet pierwszy: powiązanie odbiorcy pieniędzy z tożsamością i intencją użytkownika. Adres rachunku, portfela albo token płatniczy nie może być parametrem, który agent po prostu odbiera od poprzedniego komponentu i przekazuje dalej. Odbiorca powinien być objęty kryptograficznie weryfikowanym mandatem. W klasycznych płatnościach zdalnych europejskie RTS-y idą w podobnym kierunku: kod uwierzytelniający dla określonych transakcji musi być związany z kwotą i odbiorcą.

Priorytet drugi: sekrety agenta nie mogą trafiać do zwykłych logów, promptów ani odpowiedzi narzędziowych. Redakcja logów po fakcie jest za późna. Jeżeli sekret może zostać zserializowany w zwykłym logu aplikacyjnym, trzeba potraktować architekturę jako niespełniającą wymagań dla płatności.

Priorytet trzeci: każdy registry, resolver i marketplace trzeba traktować jako potencjalnie niezaufany. Odpowiedź „agent X znajduje się pod endpointem Y” powinna mieć dowód pochodzenia i integralności. TLS zabezpiecza kanał do serwera, ale nie rozwiązuje problemu, jeżeli sam serwer lub rejestr może przekazać fałszywe dane.

Dopiero później warto rozbudowywać ochronę przeciw prompt injection. Ona jest potrzebna, ale nie zastąpi kontroli protokołu.

Jest też prosta decyzja graniczna dla przedsiębiorstw wdrażających takie systemy w Polsce. Jeżeli agent może samodzielnie zmienić beneficjenta płatności, zwiększyć kwotę albo wybrać nowego sprzedawcę bez ponownego sprawdzenia, czy mieści się to w mandacie użytkownika, nie powinien otrzymywać autonomii finansowej. Nie wystarczy dzienny limit 500 czy 1000 zł. Pięć „poprawnych” płatności po 200 zł do złego odbiorcy nadal daje 1000 zł straty.

Podobnie z automatycznym akceptowaniem niskich kwot. Europejskie przepisy przewidują wyjątki od SCA między innymi dla części płatności niskiego ryzyka, ale wyjątek regulacyjny nie jest mechanizmem bezpieczeństwa agenta. Jeżeli infrastruktura błędnie ustaliła beneficjenta, brak dodatkowego uwierzytelnienia tylko skraca drogę ataku.

Najbezpieczniejszy punkt startu dla polskich wdrożeń jest więc dość konserwatywny: pozwolić agentowi wyszukiwać, negocjować i budować koszyk autonomicznie, ale przy nowych odbiorcach lub przekroczeniu ustalonego progu wymagać potwierdzenia użytkownika z pokazaniem konkretnej kwoty, sprzedawcy i przedmiotu zakupu. Pełną autonomię warto uruchamiać dopiero dla dobrze zdefiniowanych scenariuszy — na przykład zakupu tej samej usługi od zatwierdzonego dostawcy w określonym limicie.

To mniej spektakularne niż agent z nieograniczonym dostępem do portfela. Za to znacznie łatwiej ustalić później, kto zezwolił na transakcję i dlaczego została wykonana.

FAQ: agenci AI i płatności

Czy klient polskiego banku może już dziś po prostu włączyć agenta AI, który będzie płacił za wszystkie zakupy?
Nie. W Polsce wykonano już uwierzytelnione płatności agentowe, ale rynek znajduje się na etapie kontrolowanych wdrożeń, integracji i stopniowego udostępniania infrastruktury. Nie należy utożsamiać przeprowadzonej transakcji produkcyjnej z masową dostępnością funkcji dla wszystkich klientów.

Czy badanie naprawdę wykryło dokładnie 33 podatności?
Tak. Praca z 23 lipca 2026 r. opisuje 33 ustalenia dotyczące trzech platform: CoralOS, Fetch.ai uAgents oraz AP2 v0.2.0. Autor grupuje problemy w sześć klas przyczyn źródłowych.

Czy wszystkie 33 luki pozwalają ukraść pieniądze?
Nie. Mają różne konsekwencje — od problemów z tożsamością i endpointami po sekrety, sesje oraz stan płatności. Szczególnie istotne jest jednak to, że trzy podatności CoralOS zostały połączone w pełny łańcuch prowadzący do przekierowania płatności.

Czy wystarczy zastosować lepszy model AI, żeby usunąć problem?
Nie. To jedna z głównych tez badania. Część wykrytych ataków jest strukturalna: wykorzystuje zachowanie protokołu i infrastruktury niezależnie od jakości rozumowania modelu. Model może poprawnie wykonywać swoją pracę, podczas gdy system przekazuje mu fałszywy adres odbiorcy.

Czy płatności agentowe omijają europejskie SCA?
Nie automatycznie. W Europie nadal obowiązują zasady silnego uwierzytelniania płatności wraz z określonymi wyjątkami. Visa deklaruje, że transakcje wykonane w programie Agentic Ready były zabezpieczane Payment Passkeys z uwzględnieniem wymogów SCA.

Co firma wdrażająca agenta płatniczego powinna sprawdzić jako pierwsze?
Nie prompt. Najpierw trzeba sprawdzić, w jaki sposób system kryptograficznie wiąże użytkownika, zakres zgody, kwotę i beneficjenta płatności oraz czy żadnego z tych elementów nie może jednostronnie podmienić marketplace, resolver, zewnętrzny agent albo narzędzie MCP. Następny test powinien objąć sekrety w logach i izolację sesji. Dopiero potem ma sens strojenie filtrów prompt injection. Wyniki badania pokazują, że właśnie ta kolejność usuwa najbardziej niebezpieczną ślepą plamę obecnych wdrożeń agentic commerce.