Zaktualizowano: 6 sierpnia 2026
Czym różni się network token od tokena agentowego? Network token zastępuje numer karty płatniczej surogatem wydanym przez organizację kartową i działa u sprzedawcy, dla którego został wystawiony. Token agentowy to ten sam mechanizm rozszerzony o powiązanie z konkretnym agentem AI, jego uprawnieniami i udokumentowaną zgodą posiadacza karty. Różnica nie jest kosmetyczna: token agentowy niesie informację o tym, kto wykonuje transakcję i w jakich granicach, a nie wyłącznie o tym, która karta za nią płaci.
Definicja kanoniczna: Token agentowy to płatniczy token sieciowy powiązany z konkretnym agentem AI, zakresem sprzedawców i zgodą posiadacza karty. Network token zastępuje numer karty (PAN) bez tego powiązania z agentem.
Network token a token agentowy – w skrócie:
- Network token wydaje organizacja kartowa przez własną usługę tokenizacyjną: Visa Token Service (VTS) lub Mastercard Digital Enablement Service (MDES), zgodnie ze specyfikacją EMVCo EMV Payment Tokenisation – Technical Framework.
- Token agentowy to nadbudowa nad tą samą infrastrukturą. Mastercard ogłosił program Agent Pay wraz z Agentic Tokens 29 kwietnia 2025, wskazując, że rozwiązanie opiera się na istniejących mechanizmach tokenizacji.
- Token PSP (vault token) wydaje dostawca usług płatniczych lub sejf danych. Nie jest przenośny między dostawcami, nie aktualizuje się automatycznie po wznowieniu karty i nie niesie kryptogramu transakcyjnego.
- Shared Payment Token (SPT) to prymityw z protokołu Agentic Commerce Protocol opublikowanego przez Stripe i OpenAI 29 września 2025, ograniczony do jednego sprzedawcy i jednej kwoty koszyka.
- Zgodnie z zasadami Visa Core Rules obowiązującymi od 18 kwietnia 2026 transakcja agentowa realizowana na przechowywanym poświadczeniu musi wykorzystywać token, a nie surowy numer karty.
- Żaden typ tokena nie wyprowadza organizacji z zakresu PCI DSS automatycznie. Decyduje faktyczny przepływ danych, a nie deklaracja dostawcy.
- Patronusec jako akredytowany QSA (Qualified Security Assessor) prowadzi scoping środowisk płatniczych opartych na tokenizacji sieciowej i agentowej, od analizy luk po Report on Compliance.
Spis treści
Czym jest network token i kto go wydaje?
Network token to surogat numeru karty wydawany przez organizację kartową, powiązany domenowo z konkretnym sprzedawcą, urządzeniem lub kanałem płatności. Wydają go usługi tokenizacyjne organizacji kartowych, a ramy techniczne definiuje EMVCo. Token nie ma matematycznego związku z numerem karty i poza swoją domeną nie da się go użyć.
Kluczowe elementy architektury tokenizacji sieciowej:
- Token Service Provider (TSP) – podmiot wydający token i jedyny, który potrafi odwzorować go z powrotem na numer karty. W praktyce jest to VTS po stronie Visa i MDES po stronie Mastercard.
- Token Requestor ID (TRID) – identyfikator podmiotu, który zażądał tokena. Wiąże token z konkretnym akceptantem lub portfelem i uniemożliwia jego użycie przez inny podmiot.
- Ograniczenie domenowe – token może działać wyłącznie w zadeklarowanym kanale, u zadeklarowanego sprzedawcy lub na zadeklarowanym urządzeniu.
- Kryptogram transakcyjny – wartość dynamiczna generowana dla pojedynczej transakcji, analogiczna do kryptogramu EMV przy płatności kartą fizyczną.
- Payment Account Reference (PAR) – element danych wiążący transakcje tokenizowane z tym samym numerem karty bez ujawniania samego numeru. EMVCo zapowiedziało rozbudowę PAR w ramach prac na 2026 rok, między innymi pod scenariusze kart co-badged.
Network token zachowuje aktualność poświadczenia: gdy wydawca wznawia kartę lub zmienia jej datę ważności, token nadal wskazuje właściwy rachunek. To odróżnia go od surogatu wygenerowanego lokalnie przez sprzedawcę lub jego dostawcę.
Network token jest poświadczeniem płatniczym wydanym przez organizację kartową i ograniczonym domenowo, a nie prywatnym identyfikatorem rekordu w bazie sprzedawcy.
Czym jest token agentowy (agentic token) i co dodaje do network tokena?
Token agentowy to network token wzbogacony o trzy dodatkowe warstwy: tożsamość agenta AI, zakres uprawnień nadany przez posiadacza karty oraz powiązanie z jego udokumentowaną instrukcją. Sprzedawca przyjmuje go w tym samym przepływie autoryzacyjnym co zwykły token sieciowy, natomiast organizacja kartowa weryfikuje dodatkowo, czy dana transakcja mieści się w nadanych granicach.
Mastercard ogłosił program Agent Pay 29 kwietnia 2025 i wprowadził w nim Mastercard Agentic Tokens, budowane na sprawdzonych mechanizmach tokenizacji obsługujących dziś płatności zbliżeniowe, card-on-file i płatności programowalne. Materiały produktowe Mastercard opisują model, w którym transakcję może zainicjować wyłącznie zarejestrowany agent, a jego działania pozostają identyfikowalne dzięki tokenom sieciowym.
Visa rozwija równoległą ścieżkę w ramach Visa Intelligent Commerce. Dokumentacja dla deweloperów opisuje token płatniczy dedykowany agentom, przeznaczony do użycia w sieci akceptacji Visa, wraz z czterema powiązanymi usługami: wydawaniem poświadczeń związanych z konkretnym agentem, uwierzytelnianiem użytkownika przy wydawaniu instrukcji, kontrolami sprawdzającymi zgodność żądania płatności z pierwotną instrukcją oraz sygnałami handlowymi ułatwiającymi rozstrzyganie sporów.
Praktyczna różnica względem zwykłego network tokena wygląda tak:
| Warstwa | Network token | Token agentowy |
|---|---|---|
| Co reprezentuje | numer karty | numer karty oraz uprawnienie agenta |
| Kto inicjuje transakcję | posiadacz karty lub sprzedawca | agent AI działający na podstawie instrukcji |
| Zakres ograniczeń | sprzedawca, kanał, urządzenie | dodatkowo: limit kwotowy, kategoria sprzedawcy, czas życia sesji |
| Źródło zgody | umowa card-on-file | udokumentowana instrukcja posiadacza karty |
| Ślad audytowy | identyfikator zgłaszającego token | identyfikator agenta i powiązanie z instrukcją |
W warstwie regulacji kartowych ten model przestał być opcjonalny. Visa Core Rules and Visa Product and Service Rules obowiązujące od 18 kwietnia 2026 wprowadziły kategorie Agentic Payment Provider i Agentic Payment Enabler oraz wymóg, aby transakcja agentowa na przechowywanym poświadczeniu wykorzystywała token pozyskany od Visa lub od zarejestrowanego enablera. Obowiązki obu ról opisujemy szczegółowo w aktywie o Agentic Payment Provider i network tokenach Visa.
Token agentowy różni się od zwykłego network tokena tym, że koduje uprawnienie do działania, a nie wyłącznie odwołanie do rachunku.
Czym różni się token PSP i Shared Payment Token od network tokena?
Token PSP wydaje dostawca usług płatniczych lub sejf danych i tylko on potrafi go odwzorować na numer karty. Shared Payment Token to poświadczenie jednorazowe, przypisane do jednego sprzedawcy i jednej kwoty, wykorzystywane w protokole agentowym. Oba typy rozwiązują inny problem niż network token, dlatego w dojrzałych architekturach występują równolegle, a nie zamiennie.
Token PSP (vault token) powstaje po stronie dostawcy, który przyjął numer karty i zwrócił referencję. Główną korzyścią jest ograniczenie liczby systemów sprzedawcy stykających się z danymi kartowymi. Ceną jest brak przenoszalności: migracja do innego dostawcy zwykle wymaga ponownego pozyskania danych kart od klientów albo migracji sejfu przez wyspecjalizowanego pośrednika. Token PSP nie aktualizuje się po wznowieniu karty i nie niesie kryptogramu transakcyjnego.
Shared Payment Token (SPT) to prymityw wprowadzony przez Stripe wraz z publikacją Agentic Commerce Protocol (ACP) 29 września 2025, opracowanego wspólnie z OpenAI. SPT pozwala aplikacji agentowej zainicjować płatność bez wglądu w poświadczenia kupującego i jest ograniczony do konkretnego sprzedawcy oraz kwoty koszyka. Powiązana specyfikacja Delegated Payment po stronie OpenAI zakłada, że to dostawca usług płatniczych zwraca token o zawężonym zakresie, a dokumentacja wprost ostrzega, że bezpośrednia integracja z tą specyfikacją oznacza obsługę danych posiadacza karty i może wpłynąć na zakres PCI DSS.
Pełna taksonomia w jednym ujęciu:
| Typ tokena | Kto wydaje | Zakres użycia | Aktualizacja po wznowieniu karty | Typowa rola w architekturze |
|---|---|---|---|---|
| Network token | organizacja kartowa (VTS, MDES) | sprzedawca, kanał, urządzenie | tak | poświadczenie autoryzacyjne wielokrotnego użytku |
| Token agentowy | organizacja kartowa | agent, sprzedawca, limit, czas | tak | poświadczenie dla transakcji inicjowanej przez AI |
| Token PSP (vault) | dostawca usług płatniczych lub sejf | wyłącznie ekosystem tego dostawcy | nie | ograniczenie liczby systemów w kontakcie z danymi kartowymi |
| Shared Payment Token | dostawca usług płatniczych w ramach ACP | jeden sprzedawca, jedna kwota | nie dotyczy (jednorazowy) | przekazanie płatności z agenta do sprzedawcy |
Warto odnotować kierunek prac standaryzacyjnych. EMVCo poinformowało w listopadzie 2025, że analizuje rozwój specyfikacji EMV 3-D Secure, EMV Payment Tokenisation i EMV Secure Remote Commerce pod kątem płatności agentowych, wskazując jako obszary wyjściowe intencję konsumenta, zaufanie do transakcji inicjowanej przez agenta i modele interakcji chroniące prywatność.
Jak odróżnić token płatniczy od tokena tożsamości agenta?
Token płatniczy odpowiada na pytanie „czym zapłacić”, a token tożsamości agenta na pytanie „kto o to prosi”. To dwa rozłączne artefakty, przenoszone w innych warstwach transakcji i weryfikowane przez inne podmioty. Mylenie ich prowadzi do luk w projekcie kontroli, ponieważ zespół zakłada, że jedna weryfikacja pokrywa oba ryzyka.
Cztery obiekty, które w rozmowach o płatnościach agentowych nazywa się tym samym słowem:
- Token płatniczy – network token, token agentowy, token PSP lub SPT. Reprezentuje instrument płatniczy i jest przetwarzany w warstwie autoryzacji.
- Poświadczenie tożsamości agenta – w modelu Visa Trusted Agent Protocol (TAP), przedstawionym 14 października 2025, agent podpisuje żądania HTTP zgodnie ze standardem podpisów wiadomości HTTP, a sprzedawca weryfikuje, czy ruch pochodzi od zarejestrowanego agenta. Visa opisuje ten proces jako Know Your Agent.
- Token dostępu (OAuth) – w ACP służy delegowaniu uprawnień agenta do działania na koncie kupującego u sprzedawcy. Nie jest instrumentem płatniczym.
- Token modelu językowego – jednostka tekstu przetwarzana przez model AI, rozliczana w cenniku dostawcy modelu. Nie ma nic wspólnego z płatnościami kartowymi, choć w dokumentach projektowych pojawia się pod tą samą nazwą.
W praktyce oznacza to, że weryfikacja podpisu agenta nie zastępuje kontroli nad poświadczeniem płatniczym, a ważny token płatniczy nie dowodzi, że żądanie pochodzi od agenta, któremu użytkownik cokolwiek zlecił.
Poświadczenie tożsamości agenta dowodzi, kto działa. Token płatniczy dowodzi, na jakim instrumencie. Bezpieczna architektura wymaga obu, weryfikowanych niezależnie.
Czy token agentowy wyprowadza organizację z zakresu PCI DSS?
Nie automatycznie. O zakresie decyduje to, czy systemy organizacji przechowują, przetwarzają lub przesyłają dane posiadacza karty albo mogą wpłynąć na ich bezpieczeństwo. Token wyprowadza system z zakresu tylko wtedy, gdy w tym środowisku nie da się go odwzorować na numer karty i gdy numer karty nie przepływa przez to środowisko na żadnym etapie.
Cztery pytania, które przesądzają o granicy środowiska danych posiadacza karty:
- Czy Twoje systemy widzą numer karty w chwili wydawania tokena? Etap provisioningu bywa pomijany w analizach zakresu, choć to właśnie tam najczęściej pojawia się pełny numer karty.
- Czy dysponujesz możliwością detokenizacji? Dostęp do funkcji odwzorowania tokena na numer karty umieszcza system w zakresie niezależnie od tego, jak rzadko z niej korzystasz.
- Czy token trafia do komponentów, które mogą wpłynąć na bezpieczeństwo danych kartowych? Orkiestrator agenta, warstwa logowania promptów i magazyn wektorowy to systemy, o które audytor zapyta.
- Czy dostawca dostarczył dowód, a nie deklarację? Twierdzenie o kwalifikacji do uproszczonego kwestionariusza wymaga potwierdzenia w Attestation of Compliance dostawcy i w macierzy odpowiedzialności, a nie w materiałach marketingowych.
PCI DSS v4.0.1 pozostaje jedyną aktywną wersją standardu, a wymogi wcześniej oznaczone jako przyszłe obowiązują od 31 marca 2025. Oznacza to, że projekt środowiska agentowego oceniany jest dziś według pełnego zestawu wymagań, bez okresu przejściowego.
Patronusec Insight: W projektach scopingowych najczęstszym nieporozumieniem pozostaje przekonanie, że tokenizacja sama w sobie redukuje zakres certyfikacji. Redukuje, ale wyłącznie dla podmiotu, który realnie nie ma dostępu do numeru karty ani do funkcji detokenizacji. W środowiskach agentowych dochodzi drugi problem: dane kartowe potrafią wyciec nie przez bazę, lecz przez ślad rozumowania modelu, log wywołań narzędzi albo kontekst przekazany do zewnętrznego dostawcy modelu. Pytanie, które zadaje audytor, brzmi „gdzie ten token jest widoczny i kto może go zamienić na numer karty”. Jeśli budujesz platformę agentową i nie masz jeszcze analizy luk PCI DSS obejmującej wprost obsługę tokenów i telemetrię modelu, definicja zakresu jest najprawdopodobniej niepełna.
Jakie wymogi PCI DSS dotyczą systemów AI inicjujących płatności?
Zastosowanie AI nie znosi żadnego wymogu standardu. PCI SSC opublikowała 11 września 2025 zestaw zasad dla systemów AI w środowiskach płatniczych, otwierając go regułą bezwzględną: system AI musi zostać wdrożony i utrzymywany zgodnie z obowiązującymi wymogami PCI SSC, a złożoność modelu nie zwalnia z ich spełnienia.
Zasady PCI SSC układają się w mapę kontroli, którą można zestawić z właściwościami tokena agentowego:
| Właściwość tokena agentowego | Zasada PCI SSC dla systemów AI | Powiązany obszar PCI DSS |
|---|---|---|
| Limit kwotowy, kategoria sprzedawcy, czas życia | dostęp do danych kartowych wyłącznie w postaci chronionej, z ograniczeniami użycia | Wymóg 3 i Wymóg 4 |
| Powiązanie z tożsamością agenta | poświadczenia ograniczone, specyficzne dla przypadku użycia i kontekstu | Wymóg 7 i Wymóg 8 |
| Rejestrowanie działań agenta | działania możliwe do zalogowania i monitorowania, z odpowiedzialnością konkretnej osoby | Wymóg 10 |
| Możliwość unieważnienia tokena | system dający się w prosty sposób wyłączyć | Wymóg 8 i Wymóg 12 |
| Odporność na manipulację instrukcją | ochrona przed złośliwym wejściem i nieprawidłowym wyjściem | Wymóg 6 i Wymóg 11 |
| Izolacja środowiska agenta | oddzielenie środowiska operacyjnego i danych użytkowników | Wymóg 1 |
Trzy zasady zasługują na osobne odnotowanie, ponieważ zmieniają sposób projektowania platformy agentowej:
- System AI nie może przyjąć odpowiedzialności. PCI SSC wskazuje, że role wymagające formalnej akceptacji odpowiedzialności, w tym zatwierdzenia na poziomie zarządczym i funkcja custodiana kluczy, nie nadają się dla systemów AI. Za działania agenta odpowiada wskazana osoba.
- Systemowi AI nie powierza się sekretów o dużym wpływie. Do tej kategorii PCI SSC zalicza wprost tokeny dostępu do API, poświadczenia użytkowników i materiał kryptograficzny.
- Agenta traktuje się jak potencjalnego złośliwego insidera. PCI SSC zaleca uwzględnienie tego scenariusza w analizie zagrożeń i w testowaniu planu reagowania na incydenty, do czego odnosi się Wymóg 12.10.
W tym kontekście token agentowy pełni rolę mechanizmu, który PCI SSC opisuje jako dopuszczalny sposób udostępnienia AI danych płatniczych: dane w postaci chronionej, z ograniczeniem kwoty, częstotliwości, sprzedawcy i czasu życia poświadczenia.
Jakie błędy popełniają praktycy przy rozróżnianiu tokenów?
Najczęstsze pomyłki nie wynikają z braku wiedzy technicznej, lecz z używania jednego słowa na określenie czterech różnych obiektów. Poniższe błędy powtarzają się w dokumentacji zakresu, w macierzach odpowiedzialności i w rozmowach z dostawcami.
❌ Traktowanie każdego „tokena” jako tego samego bytu – token modelu językowego, token dostępu OAuth, network token i token agentowy pełnią rozłączne funkcje i podlegają innym kontrolom.
❌ Uznanie, że network token automatycznie wyprowadza z zakresu PCI DSS – o zakresie decyduje dostęp do numeru karty i do funkcji detokenizacji, a nie sam fakt użycia tokena.
❌ Mylenie tożsamości agenta z poświadczeniem płatniczym – zweryfikowany podpis agenta nie mówi nic o uprawnieniu do obciążenia karty, a ważny token nie potwierdza, kto go przedstawia.
❌ Zakładanie przenoszalności tokena PSP – token wydany przez jednego dostawcę pozostaje bezużyteczny poza jego sejfem, co przy zmianie dostawcy oznacza ponowne pozyskanie poświadczeń.
❌ Przechowywanie Shared Payment Token „na później” – SPT jest przypisany do jednego sprzedawcy i jednej kwoty, a wzorzec implementacyjny zakłada obciążenie natychmiastowe, bez zapisu poświadczenia.
❌ Pomijanie telemetrii modelu w analizie zakresu – logi promptów, ślady wywołań narzędzi i magazyny kontekstu potrafią zawierać dane, których nie ma w żadnej bazie produkcyjnej.
FAQ – Network token a token agentowy
Czy token agentowy to to samo co network token?
Nie w pełni. Token agentowy działa na infrastrukturze tokenizacji sieciowej i u sprzedawcy zachowuje się jak network token, ale dodatkowo wiąże poświadczenie z tożsamością agenta AI, zakresem uprawnień i zgodą posiadacza karty. Zwykły network token reprezentuje wyłącznie instrument płatniczy.
Kto wydaje network token?
Organizacja kartowa przez własną usługę tokenizacyjną: Visa Token Service po stronie Visa i Mastercard Digital Enablement Service po stronie Mastercard. Ramy techniczne definiuje EMVCo w specyfikacji EMV Payment Tokenisation. Dostawca usług płatniczych może wystąpić o token w imieniu akceptanta, ale sam go nie wydaje.
Czym różni się token PSP od network tokena?
Token PSP wydaje dostawca usług płatniczych i tylko jego sejf potrafi odwzorować go na numer karty. Nie jest przenośny między dostawcami, nie aktualizuje się po wznowieniu karty i nie niesie kryptogramu transakcyjnego. Network token wydaje organizacja kartowa i działa w całej sieci akceptacji.
Czy transakcja agentowa może wykorzystywać surowy numer karty?
Nie, jeśli podlega zasadom Visa dla płatności agentowych obowiązującym od 18 kwi 2026. Transakcja realizowana na przechowywanym poświadczeniu wymaga tokena pozyskanego od Visa lub od zarejestrowanego Agentic Payment Enablera. Użycie surowego numeru karty stanowi naruszenie zasad.
Czy tokenizacja zwalnia z audytu PCI DSS?
Nie. Tokenizacja może istotnie zmniejszyć liczbę systemów w zakresie, ale obowiązek potwierdzenia zgodności pozostaje. Jeśli Twoje środowisko widzi numer karty na etapie wydawania tokena lub ma dostęp do detokenizacji, pozostaje w zakresie PCI DSS v4.0.1 niezależnie od typu użytego tokena.
Jak Patronusec pomaga określić zakres PCI DSS w środowisku agentowym?
Zaczynamy od mapy przepływu danych obejmującej provisioning tokena, warstwę orkiestracji agenta i telemetrię modelu, a następnie zestawiamy ją z wymogami PCI DSS v4.0.1. Jako akredytowany QSA przedstawiamy stałą wycenę po bezpłatnej rozmowie scope assessment.
Co czytać dalej?
Ścieżka od klasyfikacji obowiązków do gotowości audytowej:
- Agentic Payment Provider i network tokeny Visa – 7 obowiązków PCI DSS – obowiązki ról APP i APE po zmianach z 18 kwietnia 2026.
- Zakres certyfikacji PCI DSS – od czego zacząć i jak go określić – metoda kategoryzacji systemów, którą stosujemy w projektach scopingowych.
- Przewodnik po standardzie PCI DSS – role akceptanta i service providera oraz metody potwierdzania zgodności.
- Polityka AI w firmie – 10 elementów – warstwa nadzoru nad wykorzystaniem AI, na której opiera się kontrola nad agentami.
Tokenizacja agentowa a zakres PCI DSS – bezpłatna konsultacja
Patronusec jest akredytowanym QSA i prowadzi projekty PCI DSS dla firm z sektorów fintech, e-commerce i płatności, w tym dla platform budujących obsługę płatności inicjowanych przez agentów AI.
Umów rozmowę scope assessment | Certyfikacja PCI DSS | Analiza luk