Aktualizacja : 30 marca 2026
Czym jest Verifiable Intent (VI)? Verifiable Intent to otwarty standard kryptograficzny (wersja 0.1-draft, opublikowany w lutym 2026 roku przez Verifiable Intent Working Group), który pozwala użytkownikowi raz zdefiniować zakres uprawnień dla agenta AI — a następnie agent samodzielnie realizuje transakcje płatnicze w ramach tych granic, bez konieczności potwierdzania każdego zakupu. Każde działanie agenta jest kryptograficznie powiązane z pierwotną intencją użytkownika, weryfikowalną przez sklep i sieć płatniczą. Standard jest budowany z myślą o świecie, w którym AI-asystenci kupują, subskrybują i opłacają rachunki w Twoim imieniu.
Verifiable Intent i płatności agentic — w skrócie:
- VI działa w dwóch trybach: Immediate (użytkownik zatwierdza każdą transakcję) i Autonomous (agent działa samodzielnie w ramach zdefiniowanych limitów).
- Cały łańcuch zaufania opiera się na trzech warstwach podpisanych kryptograficznie: L1 (wydawca karty), L2 (użytkownik), L3 (agent AI).
- Użytkownik nie podpisuje każdej transakcji — podpisuje raz zakres uprawnień (np. „kupuj produkty sportowe do 500 zł miesięcznie u zatwierdzonych sprzedawców”).
- Sklep widzi tylko to, co kupujesz. Sieć płatnicza widzi tylko dane płatności. Żadna ze stron nie widzi całości — to tzw. selective disclosure.
- Specyfikacja V0.1 opiera się na standardach SD-JWT (RFC 9901), ES256 (ECDSA P-256) i confirmation claims (RFC 7800).
- Standard jest w fazie draft — żaden główny procesor płatności nie wdrożył go produkcyjnie (stan: marzec 2026), ale Mastercard jest wymieniony jako przykładowy Issuer w referencyjnym profilu kredencjałów.
- Największe ryzyko compliance to: autoryzacja bez dowodu ludzkiego zamiaru w rozumieniu PSD2 SCA oraz nowe wektory ataku na klucz prywatny agenta.
Jak działa Verifiable Intent — trzy warstwy, jeden łańcuch
VI buduje hierarchię zaufania złożoną z trzech podpisanych JWT, gdzie każda warstwa kryptograficznie wiąże się z poprzednią.
Warstwa 1 (L1) — Credential Provider (np. bank lub Mastercard)
Bank lub sieć płatnicza wystawia długoterminowy token (ważność ~1 rok), który zawiera tożsamość użytkownika i jego klucz publiczny. To fundament całego łańcucha — jeśli ten klucz zostanie skompromitowany, wszystkie powiązane transakcje tracą wiarygodność.
Warstwa 2 (L2) — Użytkownik
Użytkownik tworzy i podpisuje swoim kluczem prywatnym mandat zakupowy. Zawiera on albo finalne wartości transakcji (tryb Immediate), albo zestaw ograniczeń (tryb Autonomous): dozwolone sklepy, limit kwotowy, dozwolone kategorie produktów, okres ważności upoważnienia. Token L2 wiąże się kryptograficznie z L1 przez pole sd_hash.
W trybie Autonomous L2 zawiera też klucz publiczny agenta AI, co jest formalnym aktem delegacji uprawnień.
Warstwa 3 (L3) — Agent AI (tylko tryb Autonomous)
Agent, działając w ramach granic z L2, tworzy dwa oddzielne tokeny:
- L3a — mandat płatniczy, wysyłany do sieci płatniczej (kwota, odbiorca, instrument płatniczy)
- L3b — mandat zakupowy, wysyłany do sprzedawcy (koszyk, SKU, cena jednostkowa)
Oba tokeny żyją ~5 minut i wzajemnie się weryfikują przez wspólny checkout_hash. Agent nie może rozszerzyć swoich uprawnień ponad to, co zapisał użytkownik w L2.
W praktyce oznacza to: użytkownik ustawia raz „asystent może kupić dla mnie rakiety tenisowe do 300 USD w Tennis Warehouse lub Sports Direct” — a agent realizuje zamówienie sam, dostarczając sieci płatniczej i sklepowi tylko te dane, które każdy z nich potrzebuje. Żadna strona nie widzi kompletnego obrazu transakcji.
Czym różni się tryb Immediate od trybu Autonomous?
To rozróżnienie ma kluczowe znaczenie dla compliance i zarządzania ryzykiem.
| Aspekt | Tryb Immediate | Tryb Autonomous |
|---|---|---|
| Warstwy JWT | 2 (L1 + L2) | 3 (L1 + L2 + L3) |
| Obecność użytkownika | Wymagana przy każdej transakcji | Nie wymagana — agent działa sam |
| Zawartość L2 | Finalne wartości (kwota, koszyk) | Ograniczenia i klucz agenta |
| Rola agenta | Tylko przekazanie danych | Wybór produktów, tworzenie koszyka, budowanie L3 |
| Czas życia L2 | ~15 minut | 24 godziny – 30 dni |
| Weryfikacja SCA PSD2 | Bliżej tradycyjnej autoryzacji | Otwarte pytanie prawne |
| Ryzyko dla firmy | Niskie | Średnie–wysokie (zależy od limitów) |
W trybie Autonomous użytkownik definiuje uprawnienia, a agent działa w ich ramach przez dni lub tygodnie. Dla CEO i CFO kluczowe pytanie brzmi: kto odpowiada, gdy agent przekroczy intencję użytkownika? VI rozwiązuje to technicznie — agent fizycznie nie może wygenerować tokenu L3 poza granicami L2 — ale kwestia odpowiedzialności prawnej i regulacyjnej pozostaje otwarta.
Jakie korzyści biznesowe niesie Verifiable Intent dla firm działających w e-commerce i fintech?
VI adresuje realny problem, który w ciągu najbliższych 2–3 lat stanie się krytyczny dla każdej firmy budującej produkty z agentami AI.
Korzyść 1: Audytowalność działań agenta AI
Każda transakcja wykonana przez agenta zostawia kryptograficzny ślad: kto upoważnił (L2 z podpisem użytkownika), co agent wybrał (L3b), ile zapłacił (L3a) i czy mieścił się w limitach. To odpowiedź na pytanie „skąd wiesz, że AI kupiło to, co chciałeś?” — pytanie, które już teraz zadają regulatorzy w kontekście DORA i NIS2.
Korzyść 2: Prywatność przez architekturę (Privacy by Design)
Sklep widzi koszyk, ale nie widzi danych karty. Sieć płatnicza widzi kwotę i odbiorcę, ale nie widzi, co zostało kupione. To architekturalne oddzielenie danych zmniejsza ryzyko naruszenia art. 25 RODO (privacy by design) i ogranicza zakres CDE (Cardholder Data Environment) w rozumieniu PCI DSS — agent nie przekazuje pełnych danych kartowych przez sklep.
Korzyść 3: Granularne limity zamiast pełnomocnictwa
Zamiast dawać agentowi dostęp do karty kredytowej „na zapas”, użytkownik definiuje precyzyjny zakres: payment.amount.max = 500, mandate.checkout.allowed_merchant = ["merchant-001", "merchant-002"], payment.budget.cumulative = 2000. Agent nie może kupić drożej, nie może kupić u innego sprzedawcy, nie może przekroczyć miesięcznego budżetu.
Korzyść 4: Interoperacyjność z istniejącymi standardami
VI nie wymyśla nowego formatu — buduje na SD-JWT (RFC 9901), JWS (RFC 7515) i mechanizmach stosowanych już w OpenID4VP i FIDO2. Firmy posiadające infrastrukturę JWT mogą wdrożyć weryfikację VI bez budowania nowego stosu technologicznego od zera.
Jakie zagrożenia i ryzyka compliance niesie wdrożenie agentic payments z VI?
To pytanie, które CEO, CTO i CISOpowinni zadać zanim zdecydują o wdrożeniu.
Ryzyko 1: Luka między VI a PSD2 SCA
Dyrektywa PSD2 wymaga Strong Customer Authentication przy inicjowaniu transakcji płatniczych. VI w trybie Autonomous eliminuje interakcję użytkownika przy każdym zakupie — użytkownik „podpisuje” tylko raz, tworząc L2. Specyfikacja VI wprost przyznaje, że relacja z SCA jest otwartym pytaniem projektowym (patrz: design-rationale.md). Firmy fintech i PSP planujące wdrożenie VI powinny skonsultować interpretację z krajowym organem nadzoru (w Polsce: KNF) zanim wystawią usługę produkcyjnie.
Ryzyko 2: Kompromitacja klucza prywatnego agenta
Klucz prywatny agenta, zawarty w L2 jako klucz delegacji, to nowy wektor ataku. Jeśli napastnik przejmie klucz agenta, może w ramach limitów L2 realizować transakcje bez wiedzy użytkownika — i każda z nich będzie wyglądać jak autoryzowana. Specyfikacja zaleca Secure Enclave lub HSM po stronie serwera, ale nie wymaga konkretnego mechanizmu. Dla firm przetwarzających płatności klientów to wymóg analogiczny do ochrony kluczy w środowiskach PCI DSS.
Ryzyko 3: Standard jest w wersji draft
V0.1 z lutego 2026 roku nie jest standardem produkcyjnym. Specyfikacja zawiera explicite sekcje odroczone: rewokacja kredencjałów (revocation) nie jest zdefiniowana w v0.1 — jeśli użytkownik chce odwołać upoważnienie agenta przed wygaśnięciem L2, nie ma standaryzowanego mechanizmu. Firmy budujące na VI muszą same rozwiązać ten problem lub poczekać na kolejną wersję.
Ryzyko 4: Odpowiedzialność za działania agenta
Gdy agent AI kupi coś niezgodnego z intencją użytkownika (ale technicznie mieszczącego się w limitach L2), kto odpowiada? Producent modelu AI? Operator platformy? Wydawca L1? Specyfikacja VI rozwiązuje weryfikację techniczną, ale nie rozwiązuje pytania o odpowiedzialność prawną. W kontekście DORA (Digital Operational Resilience Act), firmy finansowe muszą dokumentować łańcuch odpowiedzialności za każde działanie systemu ICT — VI dostarcza ślad techniczny, ale polityki odpowiedzialności muszą powstać wewnętrznie.
Ryzyko 5: Atak replay i cross-merchant replay
Specyfikacja identyfikuje atak cross-merchant replay jako istotne zagrożenie: agent mógłby próbować użyć tego samego mandatu L2 u wielu sprzedawców jednocześnie. Mitygacja wymaga, aby sieci płatnicze śledziły wydane tokeny L3 per mandat L2 — co oznacza nowe wymagania dla systemów płatniczych, które dziś takiego stanu nie utrzymują.
Jak Verifiable Intent wpisuje się w regulacje PCI DSS, DORA i NIS2?
Dla firm w zakresie PCI DSS, DORA i NIS2 VI wprowadza nowe wektory do analizy ryzyka.
PCI DSS v4.0
VI ogranicza przepływ pełnych danych kartowych przez agenta — agent operuje na kryptograficznych tokenach, nie na PAN. To potencjalnie zmniejsza zakres CDE. Jednak klucz prywatny agenta musi być chroniony zgodnie z wymaganiami kryptograficznymi PCI DSS (Requirement 3.6 i 3.7: zarządzanie kluczami kryptograficznymi). Firmy wdrażające VI powinny przeanalizować, czy infrastruktura klucza agenta wchodzi w zakres oceny QSA. Zespół Patronusec prowadzi analizę luk PCI DSS i może ocenić wpływ nowych architektur agentic na Twój zakres CDE.
DORA (Digital Operational Resilience Act)
DORA wymaga dokumentowania i testowania odporności cyfrowej systemów ICT dla instytucji finansowych. Agent AI realizujący autonomiczne płatności to nowy komponent ICT podlegający wymogom art. 8 (zarządzanie ryzykiem ICT) i art. 28 (zarządzanie ryzykiem stron trzecich). Jeśli model AI jest dostarczany przez zewnętrznego dostawcę (np. API OpenAI, Anthropic), firma musi mieć udokumentowaną ocenę ryzyka tego dostawcy. Więcej o wymaganiach DORA dla systemów ICT znajdziesz na naszej stronie DORA compliance.
NIS2
Operatorzy usług kluczowych i dostawcy usług cyfrowych objęci NIS2 muszą zarządzać ryzykiem bezpieczeństwa łańcucha dostaw. VI jako standard open-source jest zależnością techniczną — organizacje muszą monitorować jego podatności i aktualizacje. Implementacja w wersji draft w systemach produkcyjnych to ryzyko, które wymaga formalnej oceny zgodnie z art. 21 NIS2. Szczegóły wdrożenia NIS2 w Twojej organizacji omówimy na stronie NIS2 wdrożenie.
Praktyczny przykład: jak agent AI kupuje rakietę tenisową z VI
Specyfikacja VI zawiera konkretny przykład, który dobrze ilustruje działanie standardu w trybie Autonomous.
Użytkownik posiada kartę Mastercard (numer kończący się na 8842). Chce, żeby jego asystent AI kupował sprzęt tenisowy w Tennis Warehouse lub Sports Direct, wydając maksymalnie 300 USD jednorazowo, łącznie nie więcej niż 2000 USD miesięcznie.
- Mastercard wystawia L1 — token z tożsamością użytkownika i jego kluczem publicznym (ważny 1 rok).
- Użytkownik tworzy L2 — podpisuje kryptograficznie zakres uprawnień: limity kwotowe, lista autoryzowanych sprzedawców, klucz publiczny agenta AI. L2 jest ważny np. 30 dni.
- Agent przegląda Tennis Warehouse — wybiera Babolat Pure Aero ($279.99), inicjuje checkout. Tennis Warehouse generuje podpisany
checkout_jwtz zawartością koszyka. - Agent tworzy L3a i L3b — dwa tokeny ważne 5 minut: L3a dla sieci płatniczej (kwota, odbiorca), L3b dla sklepu (koszyk). Oba tokeny zawierają ten sam
checkout_hash. - Weryfikacja — Tennis Warehouse weryfikuje L3b: czy koszyk zgadza się z tym, co wystawił? Sieć płatnicza weryfikuje L3a: czy kwota mieści się w limicie L2? Czy agent nie przekroczył miesięcznego budżetu?
- Płatność — jeśli wszystko się zgadza, transakcja jest autoryzowana. Użytkownik nie kliknął żadnego przycisku „zatwierdź”.
Cały łańcuch jest weryfikowalny i audytowalny — każda strona ma kryptograficzny dowód, że transakcja była zgodna z intencją użytkownika.
FAQ
Czy Verifiable Intent jest już wdrożony przez banki lub procesory płatności?
Według stanu na marzec 2026 roku VI pozostaje w fazie draft (v0.1). Specyfikacja wymienia Mastercard jako przykładowy Issuer w referencyjnym profilu kredencjałów, ale nie ma publicznych informacji o produkcyjnym wdrożeniu przez żaden bank ani procesor płatności. Standard jest publikowany jako open-source na GitHub przez Verifiable Intent Working Group.
Czym VI różni się od tokenizacji kart (np. Apple Pay, Google Pay)?
Tokenizacja kart zastępuje numer PAN tokenem dla konkretnego urządzenia lub transakcji — chroni dane karty przed kradzieżą. VI robi coś innego: tworzy kryptograficznie wiążący dowód, że konkretny agent AI działał w ramach intencji użytkownika. Oba mechanizmy mogą współistnieć — VI może operować na stokenizowanych instrumentach płatniczych.
Jak VI ma się do wymogów SCA (Strong Customer Authentication) z PSD2?
To otwarte pytanie w specyfikacji. W trybie Autonomous użytkownik nie zatwierdza każdej transakcji — co może być sprzeczne z wymogami SCA dla zleceń płatniczych. Twórcy VI wskazują w design-rationale.md, że relacja z SCA wymaga dalszej analizy prawnej. Firmy fintech planujące wdrożenie powinny skonsultować interpretację z regulatorem przed uruchomieniem produkcyjnym.
Co się dzieje, gdy agent przekroczy limity zdefiniowane w L2?
Technicznie jest to niemożliwe — agent nie może wygenerować prawidłowego tokenu L3 z wartościami przekraczającymi ograniczenia z L2. Sieć płatnicza weryfikuje L3a przeciwko ujawnionym ograniczeniom z L2 i odrzuca transakcję, jeśli wartości nie mieszczą się w granicach. To jedna z kluczowych gwarancji bezpieczeństwa VI.
Czy VI jest zgodne z RODO?
Architektura selective disclosure VI jest zbieżna z zasadą minimalizacji danych (art. 5 RODO) — każda strona widzi tylko dane niezbędne do swojej roli. Jednak VI operuje na danych tożsamościowych i finansowych, które są danymi osobowymi w rozumieniu RODO. Konieczna jest analiza DPIA (Data Protection Impact Assessment) dla każdego wdrożenia produkcyjnego, szczególnie w kontekście transgranicznego przekazywania danych między Credential Provider, siecią płatniczą i agentem AI.
Jakie są wymagania kryptograficzne VI?
VI wymaga algorytmu ES256 (ECDSA z krzywą P-256 i SHA-256) jako obowiązkowego dla wszystkich podpisów. Algorytm haszowania to SHA-256. Standard jest zbudowany na RFC 9901 (SD-JWT), RFC 7515 (JWS), RFC 7517 (JWK) i RFC 7800 (confirmation claims). Przyszłe wersje mogą dodać EdDSA z Ed25519.
Verifiable Intent i agentic payments -bezpłatna konsultacja
Twoja firma planuje wdrożenie agentów AI w procesach zakupowych lub płatniczych? Patronusec pomoże ocenić wpływ nowych architektur agentic na zakres PCI DSS, wymogi DORA i obowiązki z NIS2 — zanim pojawią się pytania od audytorów. Umów krótką, niezobowiązującą rozmowę z naszym zespołem.
