Linux Foundation ogłosiła utworzenie x402 Foundation 14 lipca 2026 r., zapewniając protokołowi płatności dla agentów AI oficjalny dom. Visa, Mastercard, Stripe i Google podpisały się jako członkowie założyciele.

Ogłoszenie nie przedstawiło żadnego sposobu na udowodnienie, że roszczenie płatnicze jest autentyczne. Brakuje zestawu testów zgodności, profilu bezpieczeństwa, programu certyfikacji oraz procedury walidacji. Tory zostały wytyczone, ale brakuje dowodu na to, że agent rzeczywiście otrzymał uprawnienie do dokonania płatności.

Premiera i brakujący element

Protokół x402 standaryzuje sposób, w jaki autonomiczni agenci oprogramowania wymieniają się potwierdzeniami i dowodami płatności. Ta standaryzacja jest niezbędnym krokiem, ale stanowi tylko połowę tego, czego potrzebuje system płatności. W tradycyjnych finansach transakcja nie jest akceptowana tylko dlatego, że format wiadomości jest poprawny; musi ona również przejść szereg kontroli bezpieczeństwa, które weryfikują zamiar płatnika, autentyczność żądania oraz integralność łańcucha kryptograficznego.

Dokumenty założycielskie x402 szczegółowo opisują format wiadomości, jednak nie idą o krok dalej, określając środowisko testowe, które sprawdzałoby, czy dana implementacja wymusza wymagane kontrole bezpieczeństwa. Bez neutralnego zestawu testów każdy dostawca może twierdzić, że „postępuje zgodnie ze specyfikacją”, jednocześnie po cichu pomijając kluczowe zabezpieczenia.

Dlaczego samo potwierdzenie nie wystarczy

Potwierdzenie płatności w świecie x402 zawiera trzy twierdzenia:

  1. Akcja miała miejsce.
  2. Akcja została autoryzowana.
  3. Kontrole bezpieczeństwa faktycznie zostały przeprowadzone.

Podpisy cyfrowe mogą zagwarantować pierwsze twierdzenie – dowodzą, że ktoś podpisał dany rekord. Nie wnoszą jednak nic do drugiego i trzeciego twierdzenia. Atakujący może sfałszować potwierdzenie, które wygląda na ważne, odtworzyć stare potwierdzenie lub zmanipulować czas przesyłania wiadomości tak, aby pierwotna autoryzacja nigdy nie miała miejsca. Obecny standard nie określa, jak wykrywać lub zapobiegać takim atakom.

Konkretny atak, który omija standardowe kontrole

Niedawna praca ShareLock (arXiv 2606.27027) demonstruje klasę ataków, które byłyby niewidoczne dla parsera weryfikującego każdą część potwierdzenia w izolacji. Autorzy pokazują, jak przeciwnik może ukryć złośliwe instrukcje w kilku opisach narzędzi. Każdy pojedynczy opis przechodzi wszystkie kontrole składniowe i sygnatury, ale gdy system składa elementy w całość, ich połączony efekt tworzy ukrytą komendę, która autoryzuje płatność bez zgody płatnika.

Ponieważ specyfikacja x402 wymaga jedynie poprawnego parsowania każdego komponentu, atak opisany w ShareLock zakończyłby się sukcesem w przypadku każdej implementacji polegającej wyłącznie na istniejących regułach walidacji. Problem nie leży w błędzie kryptograficznym, lecz w luce w zapewnieniu, że twierdzenie o uprawnieniu zachowuje swoją ważność po złożeniu elementów.

Kto powinien testować uprawnienia

Autor protokołu nie może przeprowadzić testów typu red-team na własnym projekcie bez stronniczości, a dostawca nie może certyfikować własnego bezpieczeństwa bez niezależnej perspektywy. Przemysł potrzebuje zatem neutralnych, konfrontacyjnych ram testowych, które:

  • Wykonują pełny zestaw testów zgodności w odniesieniu do sposobu, w jaki implementacja obsługuje potwierdzenia, podpisy i przejścia stanów.
  • Przeprowadzają scenariusze ataków oparte na modelowaniu zagrożeń, takie jak wieloczęściowa iniekcja pokazana przez ShareLock, aby zweryfikować, czy twierdzenie o uprawnieniu pozostaje wiarygodne po złożeniu elementów.
  • Wydają certyfikaty dopiero po tym, jak niezależne laboratorium wykaże, że implementacja jest odporna na ataki typu replay, fałszerstwo oraz desynchronizację.

Premiera x402 pozostawiła tę warstwę pustą od pierwszego dnia. Bez zewnętrznego zestawu testów każde stwierdzenie o „zgodności” może oznaczać po prostu „przejście testu składni”.

Podsumowanie

Protokół x402 ma już swój dom, ale bez neutralnego dla dostawców zestawu ram testowych w zakresie zgodności i bezpieczeństwa, uprawnienie stojące za każdą płatnością pozostaje niezweryfikowane. Dopóki niezależny organ nie udowodni, że twierdzenie o „autoryzacji” w potwierdzeniu wytrzymuje ataki w świecie rzeczywistym, obietnica bezpiecznego handlu opartego na agentach AI pozostanie nieosiągalna.