W sporze, który Amazon toczy z Perplexity od listopada 2025, pojawił się szczegół, który łatwo przeoczyć, a który mówi więcej o stanie warstwy tożsamości w dzisiejszym webie niż cały formalny pozew. Kiedy Amazon wprowadził techniczne blokady dla agenta Comet, Perplexity w ciągu 24 godzin wypuściło aktualizację, która omijała blokadę. Jak? Agent przestał przedstawiać się jako Comet. Zaczął przedstawiać się jako zwykła przeglądarka Chrome, żeby Amazon nie miał jak go odróżnić od ludzkiego użytkownika.
To nie jest obraz skomplikowanego ataku hakerskiego. To jest obraz architektury, w której nic nie zmusza agenta do prawdy. User-agent w nagłówku HTTP, który jest dziś głównym sposobem, w jaki strona rozpoznaje, kto ją odwiedza, to jest deklaracja. Deklaracja, którą agent może zmienić za każdym żądaniem. Nie ma podpisu, nie ma weryfikacji, nie ma rejestru. Jest string tekstowy, któremu strona wierzy, bo nie ma innego wyjścia.
W dzisiejszym wpisie zatrzymamy się właśnie na tej warstwie — filarze piątym agent-readiness, tożsamości i zaufaniu. Nie dlatego, że dziś mamy gotowe rozwiązania. Dlatego, że nie mamy — i to jest temat, którego nie można już przeoczać, jeśli prowadzisz stronę, która w jakikolwiek sposób pozwala agentowi działać. Filar 4, opisany w poprzednim wpisie, pokazał, co zrobić z agentem, który już u ciebie działa. Filar 5 pyta jedno pytanie głębiej — skąd właściwie wiesz, że agent jest tym, za kogo się podaje.
Żeby nie zacząć od zera, warto wcześniej spojrzeć, skąd w ogóle wziął się dzisiejszy model zaufania w webie. Bo trzecia ewolucja tożsamości, której teraz jesteśmy świadkami, jest kolejnym krokiem na drodze, po której web już dwukrotnie przeszedł.
Pierwsza ewolucja — od anonimowego ruchu do konta użytkownika
W latach dziewięćdziesiątych web nie znał pojęcia tożsamości. Strona otrzymywała żądanie HTTP, odpowiadała treścią, nie miała powodu pytać, kto jest po drugiej stronie. Anonymous user był domyślnym modelem — każdy użytkownik był dla strony taki sam, nieidentyfikowalny poza adresem IP i user-agentem (który nawet wtedy był prostą deklaracją).
To działało dopóki strony były pasywnymi dokumentami do czytania. Kiedy zaczęły pojawiać się formularze, forum, sklepy, webmail — model anonimowy przestał wystarczać. Strona potrzebowała pamiętać, kim jest ten użytkownik, czy już wcześniej coś zamawiał, co ma w koszyku, jakie wiadomości dostał. Tak powstał pierwszy prosty model tożsamości: login i hasło. Strona pyta, użytkownik odpowiada, strona mu wierzy, bo ma tajemnicę, którą zna tylko prawdziwy właściciel konta.
Ten model miał swoje ograniczenia. Hasło można wykraść, można odgadnąć, można je wyłudzić. Użytkownik musiał pamiętać dziesiątki haseł do dziesiątek kont. Każda strona budowała własny system autoryzacji, z własnymi błędami. Ale z perspektywy filaru 5 — którą tu budujemy — ważne jest co innego: model login-hasło jest modelem bezpośredniej tożsamości. Ty wpisujesz swoje dane, strona je weryfikuje. Nie ma pośrednika. Nie ma trzeciej strony, która o tobie świadczy.
Druga ewolucja — od bezpośredniej tożsamości do federacji
Przełom przyszedł w drugiej połowie lat dwutysięcznych. OpenID, SAML, potem OAuth — protokoły, które pozwoliły jednej stronie świadczyć o twojej tożsamości wobec innych stron. Logujesz się do Google. Inna strona pyta Google „czy to jest X?”. Google odpowiada tak, i druga strona cię wpuszcza, choć nigdy nie widziała twojego hasła. To była rewolucja, która zmieniła sposób, w jaki myślimy o zaufaniu w sieci.
OAuth nie usunął bezpośredniej tożsamości, ale dodał obok niej coś nowego — federację. Pojawił się koncept dostawcy tożsamości, który jest zewnętrznym audytorem tego, kim jest użytkownik. Strona, która cię logowała, już nie musiała trzymać twojego hasła — dostawała token od Google, Facebooka, GitHuba, Microsoftu, i na podstawie tego tokenu wiedziała, że to jesteś ty. Zaufanie stało się pośredniczone.
Z tego wynikła jeszcze jedna rzecz, która okaże się ważna dla filaru 5. OAuth wprowadził koncept delegacji uprawnień. Kiedy logujesz się do jakiejś aplikacji przez Google, nie tylko potwierdzasz swoją tożsamość — dajesz tej aplikacji mandat na wykonywanie pewnych akcji w twoim imieniu. Czytanie twojej skrzynki. Dostęp do kontaktów. Publikowanie w twoim imieniu. Delegacja jest odwracalna — możesz w ustawieniach Google cofnąć każde udzielone uprawnienie, i aplikacja przestaje mieć dostęp.
Ta struktura — trzech aktorów (użytkownik, dostawca tożsamości, aplikacja konsumująca), z delegacją uprawnień o jasnej odwracalności — jest fundamentem dzisiejszego webu. I jest również punktem wyjścia dla trzeciej ewolucji, bo agent jest czwartym aktorem, który w tę strukturę musi się wpisać.
Pisałem o tym wcześniej w istniejącym tekście o tożsamości agentów i problemie zaufania — gdzie pokazywałem, że samo pytanie „kto właściwie stoi za tą akcją” staje się w erze agentów trudniejsze, niż kiedy autorem akcji był zalogowany człowiek. Ten wpis idzie krok dalej — do architektonicznych konsekwencji tego pytania.
Trzecia ewolucja — tożsamość pośrednika
Agent nie pasuje do modelu OAuth, który znamy. W OAuth dostawca tożsamości świadczy o użytkowniku. Aplikacja konsumująca dostaje mandat od użytkownika. Struktura jest dwustronna — użytkownik i aplikacja, z dostawcą tożsamości pośrodku.
Z agentem pojawia się struktura trójstronna, a czasem czterostronna. Jest użytkownik. Jest agent, który działa w imieniu użytkownika. Jest strona, na której agent wykonuje akcje. I często jest jeszcze dostawca agenta — firma, która go zbudowała i utrzymuje (OpenAI, Anthropic, Perplexity, xAI). Do tego dochodzi czasem dostawca tożsamości użytkownika (Google, jeśli użytkownik jest zalogowany przez Google). Pięciu aktorów w jednej transakcji, w modelu, który OAuth nie obsługuje natywnie.
Pytanie, które trzeba wtedy zadać, brzmi: kogo dokładnie weryfikuję, kiedy agent odwiedza moją stronę? Kilka możliwych odpowiedzi, wszystkie niepełne:
Weryfikuję użytkownika — jeśli agent działa w zalogowanej sesji użytkownika (np. jestem zalogowany do sklepu, otwieram Claude w Chrome, proszę Claude o zakup). Wtedy strona widzi sesję użytkownika i ufa, że to on. To jest dzisiejszy model dominujący — i jest to model, który Perplexity właśnie wykorzystało w sporze z Amazonem, argumentując, że agent po prostu działa w sesji zalogowanego użytkownika, więc Amazon nie ma prawa go blokować.
Weryfikuję agenta przez user-agent — co jak pokazałem na początku, jest tylko deklaracją. Agent może się przedstawić jak zechce.
Weryfikuję dostawcę agenta — przez rewersowe DNS, przez listę IP publikowaną przez dostawcę (OpenAI publikuje listę swoich IP dla GPTBot), przez sygnatury. To działa dla dużych graczy, którzy dbają o transparentność, i nie działa dla mniejszych, którzy mogą użyć dowolnej infrastruktury.
Weryfikuję kryptograficznie — czyli żądam, żeby agent podpisał swoje żądanie kluczem kryptograficznym powiązanym z weryfikowalną tożsamością. To jest kierunek, w którym zmierzają najbardziej ambitne propozycje, ale dziś nie jest to produkcyjny standard. Nie ma uzgodnionego protokołu, nie ma powszechnego wdrożenia, nie ma CA dla agentów.
Ta ostatnia droga jest interesująca, bo pokazuje, że architekci zaczynają myśleć o agentach tak, jak kiedyś pomyślano o serwerach WWW — gdzie HTTPS i certyfikaty SSL zbudowały warstwę zaufania opartą na kryptografii i łańcuchu weryfikacji. Agenty mogą pójść w podobnym kierunku, ale kto będzie odpowiednikiem urzędów certyfikacji, jak wyglądać będą rejestry, jak rozwiązać odwoływanie kluczy — to wszystko jest dziś w fazie propozycji i eksperymentów.
Meta w marcu 2026 kupiła Moltbook — platformę, która zaczęła budować rejestr tożsamości agentów i ich powiązań z ludźmi. Według komunikatu Meta, Moltbook „daje agentom sposób na weryfikację swojej tożsamości i łączenie się ze sobą nawzajem w imieniu ich ludzi”. Brzmi to jak pierwszy krok w kierunku właśnie tej kryptograficznej warstwy — rejestru, w którym agent ma weryfikowalną tożsamość osadzoną poza samym user-agentem.
Inne kierunki rozwoju tej warstwy — warto je znać, choć są dziś głównie eksperymentami:
- HTTP Message Signatures (RFC 9421) — standardowy sposób podpisywania żądań HTTP, który pozwoliłby agentom kryptograficznie potwierdzać swoją tożsamość na poziomie każdego żądania. Standard istnieje, ale adopcja dla agentów jest marginalna.
- AP2 (Agent Payments Protocol) — propozycja Google i partnerów płatniczych, w której agent ma kryptograficznie podpisany mandat od użytkownika, ograniczony kwotą, czasem, rodzajem transakcji. Jest w fazie wczesnego wdrożenia.
- OAuth for Agents — różne propozycje rozszerzenia OAuth o czwartego aktora (agenta), z delegacją uprawnień z użytkownika na agenta z możliwością cofnięcia. Różni dostawcy (Google, Microsoft, OpenAI) budują własne wersje.
Wszystkie te ruchy idą w tym samym kierunku: od deklaratywnego modelu tożsamości (user-agent jako string) do weryfikowalnego modelu (podpis kryptograficzny, rejestr, łańcuch zaufania). To jest dokładnie ta sama droga, którą web przeszedł od haseł do federacji — tylko w innym wymiarze.
Dla szerszej perspektywy administracyjnej tego, co agentic tożsamość robi z zarządzaniem dostępem w organizacjach, polecam tekst na CyberFlux.pl o nowej tożsamości uprzywilejowanej — tam ten sam problem opisany jest z perspektywy IAM, czyli klasycznej dyscypliny zarządzania tożsamościami i uprawnieniami. Okazuje się, że agent w korporacji ma uprawnienia użytkownika, ale działa z szybkością i skalą bota — i żadna z istniejących architektur IAM nie została zaprojektowana pod ten profil.
Gdzie jest dziś linia zaufania — i jak budować pod nią architekturę
Z tego wszystkiego płynie pytanie praktyczne: co dziś robić z tożsamością agenta na swojej stronie, skoro standard się jeszcze nie wykrystalizował? Odpowiedź nie jest jednolita, ale można ją rozbić na trzy poziomy decyzji.
Poziom pierwszy — co akceptujesz bez weryfikacji.
Dla części ruchu nie potrzebujesz żadnej warstwy tożsamości. Agent czytający twojego bloga, żeby odpowiedzieć użytkownikowi na pytanie o treść wpisu, nie wymaga weryfikacji. Ryzyko, że agent „udaje kogoś innego”, jest dla tego scenariusza zerowe — nie wykonuje żadnej akcji, nie zostawia śladu, nie ma co nadużyć. Tu możesz polegać na deklaratywnym modelu: user-agent, rewersowe DNS, lista IP dostawcy. Jeśli wygląda jak ClaudeBot i odpowiada z IP w zakresie Anthropica, to prawdopodobnie ClaudeBot.
Poziom drugi — co wymaga weryfikacji użytkownika, ale nie agenta.
Dla akcji o średnim znaczeniu (formularz kontaktowy, zapis na newsletter, dodanie komentarza) dziś standardem jest zaufanie do sesji użytkownika. Jeśli agent działa w zalogowanej sesji, ufasz tej sesji — tak jak ufałbyś człowiekowi logującemu się z tej samej sesji. Dodatkowo warto mieć warstwę potwierdzenia drugim kanałem (email confirmation), która załatwia przypadki, w których agent nie reprezentuje faktycznego właściciela konta.
To jest model, w którym wiesz, że ktoś wykonuje akcję z tego konta, ale nie wiesz czy to zalogowany człowiek, czy agent działający w jego imieniu. I to jest dziś akceptowalne dla większości akcji, o ile masz warstwę odwracalności.
Poziom trzeci — co wymaga weryfikacji agenta.
Dla akcji o wysokim znaczeniu (zakup wysokiej wartości, zmiana danych konta, operacja nieodwracalna) zaufanie do sesji już nie wystarcza. Musisz wiedzieć, czy agent ma mandat od użytkownika na konkretnie tę akcję, nie tylko na dostęp do konta w ogólności. I tu dzisiejsza architektura w większości stron nie ma dobrego rozwiązania.
Co można zrobić w oczekiwaniu na standard:
- Wymóg potwierdzenia drugim kanałem dla akcji o wysokim znaczeniu. Niezależnie czy żądanie przychodzi od człowieka, czy od agenta, wysyłasz email albo SMS z linkiem aktywacyjnym. To przesuwa punkt weryfikacji z sesji na dostęp do zewnętrznego kanału, który agent ma trudniej zdobyć.
- Podpisywanie mandatów na poziomie użytkownika — w panelu użytkownika dodajesz opcję „wystaw mandat dla agenta na zakupy do 500 zł, ważny 24 godziny”. Użytkownik wystawia mandat (podpisany swoim hasłem albo 2FA), agent używa tego mandatu zamiast pełnego logowania. To jest odpowiednik OAuth z ograniczoną delegacją, tylko ręcznie skonstruowany w twojej aplikacji.
- Obserwowanie wzorców — jeśli agent działa inaczej niż typowy użytkownik (wyższa prędkość, nietypowe godziny, nietypowe wzorce zakupów), warto dodać warstwę wykrywania anomalii. To nie jest weryfikacja tożsamości, ale jest sygnałem, że coś może wymagać ręcznego sprawdzenia.
Szersza perspektywa na to, jak protokoły agentic commerce próbują rozwiązać te problemy w warstwie standardów (UCP, ACP, AP2), jest w hubie Universal Commerce Protocol — tam rozkładam konkretne mechanizmy, które te protokoły proponują do zarządzania mandatami i tożsamością agentów w transakcjach.
Co z tego wynika dla agent-readiness
Jeśli pracujesz nad tym, żeby twoja strona była gotowa na agentów, filar piąty ma dwie twarze — krótkoterminową i długoterminową.
Krótkoterminowo (dziś, w roku 2026) — nie inwestuj w egzotyczne rozwiązania kryptograficznej weryfikacji tożsamości agenta, bo jeszcze nie ma standardu, a ryzyko, że postawisz na złego konia, jest wysokie. Zamiast tego zbuduj solidną warstwę pośrednią: potwierdzenia drugim kanałem, mandaty ograniczone w panelu użytkownika, monitoring wzorców. Wszystko to działa z istniejącymi narzędziami i nie zależy od tego, który standard wygra.
Długoterminowo (dwa-trzy lata do przodu) — warto obserwować, który standard tożsamości agentów zaczyna dominować. W tej chwili faworyci to rozszerzenia OAuth, AP2 w kontekście transakcji, rejestry typu Moltbook w kontekście tożsamości cross-platform. Jeśli jeden z nich osiągnie masę krytyczną, wdrożenie go będzie dobrą decyzją. Dopóki to nie nastąpi, inwestycja w egzotykę to inwestycja w ryzyko.
Trzecia ewolucja tożsamości w webie jest w toku, ale jej tempo jest wolniejsze niż tempo wdrażania agentów. To oznacza, że jako właściciel strony jesteś w pozycji dziwnej — mierzysz się z konsekwencjami warstwy, która dopiero powstaje. Najlepsze, co dziś możesz zrobić, to nie udawać, że problem nie istnieje, i nie przeceniać tego, co już mamy. Ta równowaga — między świadomością a cierpliwością — jest tym, co odróżnia dojrzałą architekturę od improwizacji.
Co dalej
Następny wpis w serii SEO/Agent-ready to filar szósty, ostatni — monetyzacja i kontrola. Warstwa, która odpowiada na pytanie: skoro już wpuszczasz agentów (lub nie), skoro weryfikujesz ich tożsamość (lub jej nie weryfikujesz), skoro dałeś im możliwości działania (lub nie dałeś) — jak z tego wszystkiego wyciągasz wartość, a kiedy opłaca się powiedzieć nie. Tam wrócą wątki z pay-per-crawl Cloudflare, z licencjonowania treści, z ekonomii ruchu agentowego. Zamkniemy tym sześciofilarową mapę agent-readiness, potem kilka podsumowujących wpisów spinających całość.
Zasada, która wraca w całej serii, wraca i tu. Tożsamość agenta nie jest nową dyscypliną — zarządzanie tożsamością w webie istnieje od trzech dekad. Różnica polega na tym, że pojawił się nowy typ aktora, którego dzisiejsze wzorce nie przewidują. Web przechodzi trzecią ewolucję zaufania. My jesteśmy na jej początku, nie w środku, i nie na końcu. Jedyna rzecz, której dziś nie warto robić, to udawać, że nic się nie zmieniło.