W komunikatach branżowych z 2025 i 2026 powtarza się pewien zestaw słów, który brzmi jak deklaracja gotowości. „Tożsamość agenta jest standardem”. „Mamy już protokoły uwierzytelnienia”. „Kryptograficzna weryfikacja działa produkcyjnie”. Te zdania pojawiają się w prezentacjach na konferencjach, w postach na LinkedInie polskich konsultantów AI, w branżowych newsletterach — czasem dosłownie, czasem w wariantach. Wszystkie sugerują jedno: problem tożsamości agenta jest rozwiązany, można na nim budować.
To jest narracja, która ma podstawę faktualną. Bo trzy konkretne rozwiązania istnieją. HTTP Message Signatures jest opublikowanym standardem IETF — RFC 9421 z lutego 2024. AP2, czyli Agent Payments Protocol Google’a, jest opublikowaną propozycją z konkretną specyfikacją. Moltbook, platforma rejestru tożsamości agentów, jest działającym produktem, kupionym w marcu 2026 przez Metę. Każde z tych rozwiązań coś robi w warstwie tożsamości agenta. Każde działa.
Problem polega na tym, że żadne z tych rozwiązań osobno nie rozwiązuje problemu tożsamości agenta. I że wszystkie trzy razem też go nie rozwiązują — bo nie są ze sobą zintegrowane, żadne z nich nie ma masowej adopcji, żadne nie jest dziś używane jako warstwa weryfikacji w produkcyjnych przepływach agentic commerce. To są trzy klocki, które w swojej dziedzinie spełniają swoje zadanie. Ale układanka, do której miały trafić, jeszcze nie jest złożona.
Ten wpis jest piątym, ostatnim tematycznym w serii „Czego nie wdrożycie w 2026 — agentic web między hype a produkcją”. Tym razem nie krytykujemy koncepcji ani sprzedaży. Krytykujemy narrację, która z istnienia klocków robi twierdzenie o gotowej układance — i sprawia, że właściciele stron i sklepów dostają wrażenie, jakby mogli już dziś budować architekturę bezpieczeństwa wokół zidentyfikowanego, weryfikowalnego agenta.
Co reklamują
Najczęstsze sformułowania, które krążą wokół tematu tożsamości agenta w polskim internecie 2025-2026, mają cztery wyraźne motywy.
Pierwszy — narracja standardu. „HTTP Message Signatures to standard kryptograficznej weryfikacji żądań agentów”. „Tożsamość agenta jest oparta na podpisach, dokładnie tak jak certyfikaty SSL”. „Mamy infrastrukturę PKI dla agentów”. Te zdania sugerują, że istnieje rozwiązanie analogiczne do HTTPS — że strona może zweryfikować agenta tak, jak przeglądarka weryfikuje serwer.
Drugi — narracja platformowa. „Moltbook buduje rejestr agentów, który zostanie infrastrukturą całego ekosystemu”. „Meta przejmuje warstwę tożsamości agentów dla swoich platform”. Sugestia: jest centralny rejestr, który rozwiązuje problem identyfikacji.
Trzeci — narracja protokołowa. „AP2 to protokół, który umożliwia agentom uwierzytelnione transakcje”. „Google buduje warstwę tożsamości w warstwie protokołu”. Sugestia: tożsamość agenta jest wbudowana w infrastrukturę płatniczą dla AI.
Czwarty — narracja konsultingowa. „Pomagamy klientom wdrożyć weryfikację tożsamości agenta”. „Audyt tożsamości w architekturze agent-readiness”. To są oferty, które zaczynają pojawiać się w polskich agencjach. Klient płaci za wdrożenie warstwy weryfikacji — i zazwyczaj nie wie, że warstwa, którą kupuje, składa się z fragmentów, które jeszcze ze sobą nie współpracują.
Wszystkie cztery narracje używają faktów. HTTP Message Signatures rzeczywiście istnieje. Moltbook rzeczywiście został przejęty. AP2 rzeczywiście jest opublikowany. Konsulting w warstwie tożsamości — rzeczywiście jest sprzedawany. Problem polega na tym, że każdy z tych faktów jest zdjęty z większego kontekstu i zaprezentowany jako kompletna odpowiedź. Czytelnik dostaje cztery deklaracje, które razem brzmią jak jedna gotowa rzecz. A to są cztery różne rzeczy w różnych stadiach rozwoju.
Co naprawdę jest
Rzeczywiste rozróżnienie wymaga prześledzenia każdego z tych elementów osobno.
HTTP Message Signatures (RFC 9421). To jest istotnie standard. IETF opublikowało go w lutym 2024. Specyfikacja jest finalna, dostępna publicznie, gotowa do implementacji. Mechanizm pozwala kryptograficznie podpisać żądanie HTTP, tak żeby odbiorca mógł zweryfikować jego pochodzenie i integralność. Dla tożsamości agenta to jest świetna podstawa — ale tylko podstawa. Sam standard nie definiuje, kto ma klucze podpisujące, jak się je dystrybuuje, ktozarządza ich rotacją, jak się odwołuje skradzione albo nadużywane klucze. To jest jak posiadanie składni dla certyfikatów SSL bez urzędów certyfikacji, listy odwołań CRL i procesów Browser CA Forum. Składnia działa. Reszta infrastruktury zaufania — nie istnieje. Adopcja RFC 9421 wśród operatorów agentów jest dziś marginalna. Żaden z dużych dostawców (OpenAI, Anthropic, Google, Perplexity) nie wymaga ani powszechnie nie używa podpisów Message Signatures w swoich produkcyjnych agentach.
AP2 (Agent Payments Protocol). Google opublikowało specyfikację w 2025. Ma rozwiązywać konkretny problem — uwierzytelnienie agenta w transakcjach finansowych, z mandatem podpisanym kryptograficznie przez użytkownika. Specyfikacja jest dostępna, ale wdrożenia są w fazie wczesnych testów. Liczba sklepów obsługujących płatności AP2 w skali produkcyjnej jest dziś niska. Liczba agentów, które AP2 implementują, też. To nie jest infrastruktura — to jest propozycja, która zaczyna się testować.
Moltbook. Platforma społecznościowa dla agentów AI z elementami rejestru tożsamości. Działa, ma użytkowników (głównie agentów), Meta ją przejęła w marcu 2026. Z perspektywy „rejestru tożsamości agentów” — to jest jeden taki rejestr. Konkurujący operatorzy (OpenAI, Anthropic, mniejsi gracze) nie wpisują swoich agentów do Moltbook. Nie ma protokołu, który by mówił „aby zweryfikować agenta, sprawdź jego wpis w Moltbook” — bo Moltbook jest własnością Mety, a operatorzy spoza Mety nie mają powodu, żeby mu zaufać. To jest jak jedna baza adresów IP przy braku globalnego DNS. Działa wewnątrz, nie działa międzyplatformowo.
Te trzy elementy razem dają obraz, który jest istotnie inny niż „tożsamość agenta jako rozwiązany problem”. Mamy:
- Standard kryptograficzny bez infrastruktury zaufania
- Protokół płatności w fazie wczesnych testów
- Jeden rejestr należący do jednego dostawcy
Aby powstał ekosystem tożsamości agenta — analogiczny do tego, jak działa dziś PKI dla HTTPS albo OAuth dla aplikacji webowych — musi się stać kilka rzeczy. Któreś z istniejących rozwiązań musi osiągnąć masową adopcję. Operatorzy agentów muszą się porozumieć co do wspólnego protokołu. Powstać musi struktura organizacyjna analogiczna do CA/Browser Forum. Standardy muszą zostać zharmonizowane.
Żadna z tych rzeczy się dziś nie dzieje w sposób, który dawałby podstawę do twierdzenia „mamy gotową warstwę tożsamości”.
Dlaczego to nie znaczy, że tożsamość agenta nie zostanie rozwiązana
Krytyka narracji o gotowej tożsamości agenta nie oznacza pesymizmu wobec problemu. Wręcz przeciwnie — istnienie trzech klocków jest sygnałem, że rozwiązanie jest bliżej niż dwa lata temu. Pytanie polega tylko na tym, czy mówimy o tym, co dziś jest, czy o tym, co powstaje.
Trzy obserwacje, które sugerują, że kierunek jest właściwy.
Pierwsza — HTTP Message Signatures jako fundament wystarcza. Standard kryptograficzny, który jest stabilny, finalny i dobrze zaprojektowany, to nie jest mała rzecz. Cała warstwa wyższa — urzędy certyfikacji dla agentów, listy odwołań, polityki zaufania — może być zbudowana na tym standardzie, bez zmieniania go. To znacznie redukuje przyszłe ryzyko niekompatybilności. W pewnym sensie najtrudniejsza część kryptograficzna jest już za nami.
Druga — silne motywacje rynkowe. Każdy z dużych operatorów AI ma własny interes w ustaleniu wiarygodnej tożsamości agentów. OpenAI nie chce, żeby kompromitujące zachowania agentów ChatGPT były anonimowe. Anthropic nie chce, żeby pod ClaudeBot podszywały się boty trzecie. Sklepy nie chcą obsługiwać płatności od agentów, których tożsamości nie da się zweryfikować. Te interesy mogą — choć nie muszą — doprowadzić do uzgodnień protokołowych w ciągu najbliższych dwóch-trzech lat.
Trzecia — historyczny precedens. Web przeszedł już dwa razy podobną ewolucję tożsamości. Najpierw od anonimowego ruchu do kont użytkownika z hasłami. Potem od haseł do federacji (OAuth, SAML, SSO). Trzecia ewolucja — dla tożsamości pośredników działających w imieniu użytkownika — jest logiczną kontynuacją. Pisałem o tym konkretnie w filarze piątym Agent-ready, gdzie rozkładam całą logikę. Tu, w serii krytycznej, trzymam się pytania o moment: jesteśmy na początku trzeciej ewolucji, nie w jej połowie ani w końcu.
To są mocne argumenty za tym, że problem zostanie rozwiązany. Ale rozwiązanie wymaga jeszcze pracy, którą trzeba wykonać. Sprzedawanie dziś klientom „warstwy tożsamości agenta” jako kompletnego rozwiązania pomija tę pracę.
Co zamiast tego zrobić w 2026
Cztery praktyczne rekomendacje dla właściciela strony albo sklepu, który zastanawia się, jak dziś podejść do warstwy tożsamości agenta.
Po pierwsze — buduj na warstwach, które istnieją i działają. OAuth dla zalogowanych użytkowników. Sesyjne uwierzytelnienie. Drugi czynnik (2FA) dla wrażliwych operacji. Email confirmation dla nieodwracalnych akcji. To są warstwy, które są dziś sprawdzone, które działają niezależnie od tego, jaki agent obsługuje twojego klienta, i które przy okazji rozwiązują 80% problemów, jakie miałaby docelowa warstwa tożsamości agenta. Klient autoryzowany przez OAuth, który robi zakup wymagający potwierdzenia mailem — to jest warstwa, którą agent nie obejdzie nawet jeśli ma fałszywą tożsamość.
Po drugie — obserwuj rozwój standardów, ale nie inwestuj w wczesne wdrożenia produkcyjne. Adopcja RFC 9421 wśród operatorów agentów. Wdrożenia AP2 w sklepach poza ekosystemem Google. Pojawienie się drugiego (poza Moltbook) rejestru tożsamości agentów. Inicjatywy standaryzacyjne typu OAuth for Agents. Każdy z tych ruchów jest sygnałem, że ekosystem dojrzewa. Bez nich pozostajemy z trzema klockami.
Po trzecie — jeśli sprzedajesz usługi agencyjne, nie wpisuj „warstwy tożsamości agenta” do oferty jako gotowego pakietu. Sami możemy w to wpaść — bo klient pyta, my chcemy odpowiedzieć, narracja branżowa daje nam słownik. Ale uczciwa odpowiedź dziś brzmi: „warstwa tożsamości agenta jest w fazie kształtowania, nie ma jeszcze produkcyjnego standardu, możemy przygotować twoją architekturę tak, żeby była gotowa, kiedy standard się ustabilizuje”. To jest dłuższe zdanie niż „audyt tożsamości w architekturze agent-readiness”. Ale prawdziwsze.
Po czwarte — projektuj architekturę bezpieczeństwa pod założenie, że tożsamość agenta jest dziś deklaratywna, nie zweryfikowana. Każdy user-agent w nagłówku HTTP może być sfałszowany. Każda deklaracja agenta o tym, kogo reprezentuje, może być nieprawdziwa. Większość agentów dziś jest uczciwych — ale architektura bezpieczeństwa nie powinna zakładać uczciwości jako warunku działania. Mechanizmy odwracalności akcji, potwierdzeń drugim kanałem, limitów per konto — to są rozwiązania, które działają niezależnie od tego, czy znasz prawdziwą tożsamość agenta.
Czego nie warto robić w 2026: kupować wdrożenia warstwy tożsamości agenta jako pakietu agencyjnego. Sprzedawać go klientom. Inwestować w integracje z Moltbook albo AP2 jako głównym kanałem weryfikacji. Każda z tych decyzji bazuje na założeniu, że ekosystem jest dojrzały — co po prostu nie jest prawdą.
Kiedy wrócić do tematu
Cztery sygnały, które będą znaczyć, że warstwa tożsamości agenta zaczyna być rozwiązanym problemem.
Pierwszy — któryś z dużych operatorów AI publicznie wymaga RFC 9421 albo równoważnego standardu kryptograficznej weryfikacji. Dziś żaden tego nie robi. Kiedy jeden zacznie — będzie to sygnał, że standard wchodzi do mainstreamu.
Drugi — drugi (poza Moltbook) rejestr tożsamości agentów osiąga znaczącą adopcję. Rejestr zarządzany przez konsorcjum, otwarty standard zarządzania tożsamościami, czy nawet konkurencyjny komercyjny rejestr — cokolwiek, co rozbije monopol jednej firmy nad warstwą zaufania.
Trzeci — AP2 albo następca osiąga masowe wdrożenie poza Google. Sklepy obsługujące płatności AP2 w skali porównywalnej do dzisiejszych BLIK-ów, kart i przelewów. Bez tego AP2 pozostaje propozycją w fazie testów.
Czwarty — branżowe konsorcjum ustanawia standard tożsamości agenta. Coś analogicznego do CA/Browser Forum dla certyfikatów SSL — organizacja, w której operatorzy agentów, sklepy, dostawcy infrastruktury uzgadniają wspólny protokół. Bez tego mamy fragmentację.
Do żadnego z tych sygnałów dziś nie doszło. Trzy klocki istnieją. Czekają na resztę układanki. Zanim zostanie ułożona, warto budować architekturę pod dzisiejszą rzeczywistość — w której agent jest aktorem deklaratywnym, nie zweryfikowanym.
Tożsamość agenta zostanie rozwiązana. Nie wiem kiedy. Wiem tylko, że dziś nie jest. I że budowanie architektury na założeniu, że jest, jest budowaniem na fundamencie, który jeszcze nie wylany.
